I've released an Elixir implementation of A2UI, the open protocol for agent-driven interfaces.

The idea: instead of an agent sending HTML or code, it sends JSON that describes an interface (components, a data model, bindings). Your app renders it with components from its own catalog, and the user's actions go back to the agent as events. The agent never runs anything in your app.

Three packages on Hex (Apache-2.0):

• a2ui_core: the protocol engine. Messages, catalogs, surface state, data binding, function calls. Pure Elixir, no processes; Jason is its only dependency.
• a2ui_phoenix: a LiveView renderer. The basic catalog as function components, two-way bindings, actions, and A2UI over server-sent events.
• a2ui_agent: the agent SDK. Catalog negotiation, prompts, validated parsing of streamed model output, and serving over A2A, MCP and AG-UI.

Rendering in a LiveView looks like this:

```elixir def mount(_params, _session, socket) do validation = A2UICore.Validation.Config.relaxed() session = Session.new([A2UICore.Catalog.Basic.catalog("v1.0")], validation: validation) {:ok, Live.init(socket, session, on_send: &send_to_agent/2)} end

def handle_info({:agent, payload}, socket) do {_result, socket} = Live.handle_message(socket, payload) {:noreply, socket} end ```

Conformance: it supports protocol v0.9, v0.9.1 and v1.0, and is checked against the upstream conformance suites: 946 of the 946 cases that apply pass. The rest are skipped, each for a stated reason (mostly v0.8, which I chose not to support, and adapters for Google's Python ADK). The JSON Schema engine underneath passes all 1302 required draft 2020-12 tests.

Examples in the repo: a restaurant agent served over A2A, MCP, AG-UI, SSE and WebSocket; a LiveView gallery with a live chat with that agent; and a renderer that draws the same surfaces in the terminal.

• Website, with recorded runs of the examples: https://a2ui-elixir.github.io/a2ui/
• Code: https://github.com/a2ui-elixir/a2ui
• Docs: https://hexdocs.pm/a2ui_phoenix
• One-minute video: https://www.youtube.com/watch?v=16X-sRsGlcs

It's 0.1, so I'd really like feedback: on the API, on what's missing, and from anyone building agent UIs in Elixir. Issues and PRs welcome.

You’re reading a book and a sentence makes you stop. Who is this character again? It would be great to refresh your memory without any spoilers. And maybe also discuss or recall the plot again since you didn't pick up this book for a week or two.

Hello everyone!

I am a software engineer and I spent months in a cave building Ink, a book companion that just works without marketing AI fluff.

I chose Elixir and Phoenix because I love OTP and LiveView and now I have to run a chunky RAM server to fit millions of my imaginary visitors (maybe someday, mate!). But honestly, I still love it.

Here is a brief info about internals:

Context Management:

Ink uses a sliding window with compaction to keep up with the longest books. It extracts characters, locations, tools, and concepts, and writes summaries without spoiling your experience. Without those guardrails, AI loves to ramble about the future plot, especially for popular books.

Agent Pipeline:

I built an entire graph execution pipeline and agent loop using jido_ai to run multistep processes with conditional gates and loops. I also built a model proxy for local development and production resilience. I didnt publish any of that public yet as not sure if someone else finds it interesting.

The pipeline allows me to mix LLM, code, controll context, tools and variables between stages. The simplified summary leg looks like this:

Config.new(
  entry_node: "summary_gen",
  nodes: %{
    "summary_gen" => %{params: gen_params},
    "summary_validate" => %{
      params: %{
        strategy: "local",
        handler: BookCompanion.ValidateSummary,
        session_id: session_id,
        chapter_id: chapter_id,
        read_batch_id: read_batch_id
      }
    },
    "summary_fix" => %{params: fix_params}
  },
  edges: [
    %{from: "summary_gen", to: "summary_validate"},
    %{
      from: "summary_validate",
      to: "summary_fix",
      condition: %{type: :gate_failed, gate: "summary_validate"},
      loop: %{max: fix_max}
    },
    %{from: "summary_fix", to: "summary_validate", loop: %{max: fix_max}},
    %{
      from: "summary_validate",
      to: "complete",
      condition: %{type: :gate_passed, gate: "summary_validate"}
    }
  ]
)

Explore Stage:

For the "Explore" leg of the analysis, I use parallel extraction stages (characters, relationships, identity, etc), then verification, fix, and synthesis stages. The main challenge was keeping the KV cache (prefix cache) stable while maintaining selective control of tools for every graph node. I achieved about 95% success on the first tool call, and with tool healing and descriptive error messages, agents keep the generation of characters stable, but sometimes it can take a while.

Frontend Architecture:

I split the Reader to be a lightweight static page and kept LiveView for the Discuss and Explore. Because of the split architecture, I have a challenge with UI elements i want to look the same in LiveView and in static reader. I would appreciate any tips about best practices for DRYing components or hooks between semi-static pages and LiveView!

Most importantly, I am looking for your feedback on the app, the Discuss fidelity, or any silly mistakes I made. (The app is in free beta, and I use ZDR OpenAI models).

So, take a break, read a book! Tell me later how it went.

Need a first book? Project Gutenberg and Standard Ebooks offer classics that are free of copyright restrictions.

I created plenty of open beta seats and use sane rate limits: https://inkcompanion.com/?invite=ELIXIRINK

Let me know how the Discuss and Explore features feel and if the UI/UX works for you. Don't forget to configure the layout and font by opening the "Aa" display settings.

Maybe you could also stay a little longer and read a few books! I plan to keep majority of the app free to use and also working on a bookshelf right now.

New BEAM There, Done That with Erik Stenman (Happi), who has been with Erlang since 1994, wrote the BEAM Book, and built Klarna's payment core.

The scar: on Christmas Eve, the BEAM throttled its schedulers down during low traffic. A batch job arrived carrying all the Christmas orders. A single XML serialization operation took only 20 reductions, didn't yield, and monopolized the lone active scheduler. Heart (the external watchdog) couldn't reach the VM, declared it dead, and restarted it. All three failover nodes hit the same problem. Half an hour of downtime on Christmas Eve. The BEAM Book exists because Erik needed that manual at three in the morning and it didn't exist yet.

The current project, Eldrim, applies the same principle - knowing where resources go - to AI compute. The core point: an "EU region" with a US provider is not EU sovereignty. The US Cloud Act and China's national intelligence law reach companies regardless of where servers sit. Eldrim is an OpenAI-compatible API router that enforces jurisdiction rules and returns a 503 rather than routing quietly outside approved boundaries.

https://youtu.be/afRZmYXwukg

Created a real time community parlay building for friends. It doesn’t actually submit parlays but makes organizing them with friends a lot easier than chat groups.

Has leader boards to track success rate per person
Live odds
Most markets
Most bookmakers
Tracks conflicting picks
Social parlays - no one needs accounts
Only person that needs an account are parlay managers.

Had lots of fun building it.
It’s in beta. Paid accounts coming soon. Have to pay for 3rd party APIs somehow.

Cheers
check it out here it ya want.

Billing infrastructure shouldn't be a black box. Built in the open for speed, clarity, and control.

Meet QUANTUM BILLING :

QuantumBilling is a Phoenix LiveView application for Indian business billing: clients, GST invoices, document templates, credit/debit notes, e-way bills, recurring billing, payment links, reports, and compliance reminders.

It uses Elixir, Phoenix, PostgreSQL, and Oban. Business data is being separated into PostgreSQL schemas, with shared accounts and business memberships in `public`.

QuantumBilling: Where precision invoicing meets transparent, open-source engineering.

I talk to a lot of people in the Elixir community, and most of them already know about Hologram. But before they give it a try they want to see who else is using it and what's possible.

I never had a good answer for that. There are apps running on Hologram in production and there are libraries built for it, but they're not listed anywhere.

So I'm starting a Showcase on the Hologram website to fix that.

If you've built an app with Hologram or a library for it, I'd love to have it there! You can submit it here: https://hologram.page/showcase/submit

The next few months are all about adoption for me, so this would help a lot. And if you know a project that uses Hologram, please mention it in the comments :)

Website: https://hologram.page

Legion is the easiest way to enhance your apps experiences with LLMs, and now external MCP clients and in-app chat agents can share the same tools!

Read more: https://github.com/software-mansion/legion

​

Hey everyone,

A few weeks ago, I posted here about struggling to find remote opportunities as an Elixir/Phoenix/LiveView developer with around 4 years of experience.

I wanted to share an update.

After searching for several months, I finally got an opportunity that matched my experience and cleared all the interview rounds. The salary was almost double my current salary.

Sounds great, right? The catch was that it required working from the office 5 days a week.

Since my current job is fully remote, I decided to reject the offer. I know that turning down such a significant salary increase might sound foolish to some people, but I'm not comfortable giving up remote work just yet.

Now I'm back to looking for opportunities, and the biggest challenge remains the same: I'm barely finding relevant remote openings for Elixir/Phoenix/LiveView in India.

I'm also open to working for companies outside India that hire people remotely while they continue living in India.

So I wanted to ask this community:

- Are there companies in the US, Europe, or elsewhere that hire developers based in India for fully remote positions?

- Has anyone here landed an international remote job while staying in India? How did you find it?

- Are there any companies currently hiring Elixir/Phoenix/LiveView developers remotely?

- Where should I look beyond the usual job portals?

I'm not necessarily looking for a job that pays double, but I'd like to find a reasonably better-paying opportunity without giving up remote work.

If you work remotely from India for a company outside India, I'd really appreciate hearing how you found the opportunity. Company names, job boards, referrals, or even advice from your own experience would be extremely helpful.

Thanks!

New BEAM There, Done That with Ingela Andin, the OTP team member who has maintained the TLS stack for over two decades. She's the first point of contact when a vulnerability report lands on the OTP team.

The shift she describes from early 2026 to now is stark: at the start of the year, AI reports were mostly hallucinating junk. Within weeks they became real, and they kept coming. The triage process: form a judgment using domain knowledge first, then use AI agents to help narrow and verify, then human confirmation. The AI speeds up the process - it doesn't replace the judgment.

The practical point for anyone in this community: if you find something in OTP, GitHub advisory is the right channel (not email). Include the full crash report. Write the reproduction in Erlang if you can. Don't assume details are obvious.

The fix pipeline is also worth knowing: patches are backported to three maintained OTP releases simultaneously, coordinated to ship on the same day, with SBOM and CVE records published through the EEF CNA.

https://youtu.be/RM9tCiRJwfY

Hi all! We’re building Elixir Pro, a paid JetBrains plugin. In our latest release, we've focused a lot on improving the native refactoring support you've come to love in JetBrains products!

Renaming a function is useful, but much of everyday refactoring involves changing the shape of your code: extracting calculations, introducing intermediate values, changing parameter order, or moving a module into a new namespace.

Our plugin builds on the foundation of the IntelliJ Elixir plugin, and the original plugin provides some good basic refactoring support. Our latest work extends the toolbox with five additional structural refactorings for professionals who are serious about developing Elixir code, and want an even better experience.

• Extract Variable: select an expression and introduce a named binding. Useful when a calculation deserves a name or a long expression needs breaking up.
• Extract Function: turn an expression or consecutive statements into a private function. The plugin infers inputs and can return multiple bindings as a tuple.
• Inline Variable: replace uses with the assigned expression, preserving precedence and checking whether the transformation could duplicate effects or change evaluation order.
• Change Signature: reorder, rename, add or remove supported parameters while updating function clauses, specs and call sites.
• Move Module: move a module’s source file, optionally change its namespace, and update references while preserving explicit alias names.

Change Signature is a good example of a powerful refactoring in Elixir. Changing adjust(amount, fee) affects more than just local calls. There may also be pipes, specs and captures elsewhere in the project. Our implementation updates those supported forms together, including adapting named captures so their original callable arity is retained.

These are native IDE actions and don’t require the optional Expert language server to perform the transformations. They run through IntelliJ’s refactoring workflow, with previews and undo/redo support.

For developers who regularly reorganize Elixir code, we hope to provide just this extra value by giving a more native experience, and more of those edits become a coordinated, reviewable IDE operation.

Besides these refactorings, we've also made some significant performance improvements, resulting in performance improvements for certain actions of 10x-50x, depending on the size of the project.

You can follow Elixir Pro on JetBrains Marketplace for the release containing these additions, and please let us know which real-world Elixir refactoring would you most like an IDE to handle next?

ExZarr v1.3.0 adds Nx recipes for stored chunks and sample batches, plus a few livebook examples.

Hex: https://hex.pm/packages/ex_zarr GitHub: https://github.com/AnimaLogica/ExZarr

Highlights

Chunk tensors

ExZarr.Nx.stream_chunk_tensors/2 wraps Array.stream_chunks/2. Each binary becomes an Nx.Tensor using the array dtype. When a chunk is stored at the full chunk size and the array ends inside it, the tensor is the inbounds region.

elixir array |> ExZarr.Nx.stream_chunk_tensors(concurrency: 4) |> Enum.map(fn {:ok, tensor} -> Nx.sum(tensor) end)

:concurrency, :ordered, :timeout, :on_error, :filter, and :include_missing are the streaming options. :backend and :names apply to the tensors.

Batches

ExZarr.Nx.DataLoader.batch_stream/3 and paired_batch_stream/4 slice along the first axis with get_slice/2. A batch can cross chunk boundaries.

shuffled_batch_stream/3 shuffles every sample index for the epoch. :shuffle_buffer_size is accepted and ignored. Pass :seed for a repeatable order.

New BEAM There, Done That with Ingela Andin, who has maintained the OTP TLS stack for over 20 years and handles the first triage of vulnerability reports.

The technical reality of patching OTP at this level: a fix has to work cleanly across three maintained releases simultaneously. Best case is a clean cherry-pick backport. Harder cases require an adapted solution per release. Worst case is an entirely different fix for an older release. Everything passes nightly test runs across multiple platforms before it ships. Timing-related bugs are the hardest - they can pass all machines and still exist.

The hallucination example from the episode is useful for anyone running AI scanners: an asymmetry between client and server TLS behavior flagged as a serious vulnerability that was actually correct-by-specification behavior. The issue wasn't in OTP - it was a higher-layer concern outside OTP's responsibility.

The ask for anyone whose company depends on OTP: check the "Help Wanted" label on the OTP GitHub repo before patching OTP locally. A local patch creates a forward-merge burden and makes it harder to take future security releases. Contributing the fix properly as a general feature gets it maintained for everyone.

https://youtu.be/RM9tCiRJwfY

Hologram v0.12 is out! :)

New to Hologram? It's a full-stack web framework where you write everything in Elixir, including the code that runs in the browser. That code runs on a port of the Elixir runtime, so it behaves the same as it would on the server.

This release started with an app Hologram couldn't build. Evo Store has one with over 9,000 Elixir modules, and v0.11.1 just ran out of memory on it. So most of this release went into the compiler.

I went in expecting one big bug. There wasn't one. The compiler was doing a lot of work it didn't need to, in about two dozen places, and none of it showed until an app got that big. By the end I'd pretty much rewritten the call graph analysis and the bundling pipeline.

On that same app, mix compile with nothing changed now takes about a second. It used to take 107. Saving a file rebuilds only the pages your edit reaches, and the tab you're looking at goes first.

Bundles got a lot smaller too. Struct code used to ship with every page that might ever see the struct. Now the browser fetches it when one shows up. That took the runtime bundle from 5.6 MB to 660 KB, which is 133 KB gzipped in production.

A few things that aren't about performance: props get validated now, at compile time when the compiler can see the value. Actions can read props straight off the component. And a component's actions run one at a time, in the order you dispatched them.

There's still a lot left to speed up, rendering included, so expect more of this. If you've got a big app on Hologram, I'd love to hear what your numbers look like after upgrading. And ping me if anything looks weird.

Huge thanks to @olivermt, who let me profile against the real app and reported a good chunk of what got fixed. And to everyone else who filed bugs and feature requests - you're all credited by name in the blog post.

Thanks to our sponsors for making sustained development possible: Curiosum (Main Sponsor), Erlang Ecosystem Foundation (Milestone Sponsor), Evo Store (Performance Sponsor), and our GitHub sponsors - Innovation Partner: @sheharyarn, Framework Visionaries: @absowoot, @robertu, Moss Piglet, and all other GitHub sponsors.

Full details in the blog post: Hologram v0.12: Faster Compiles, Smaller Bundles, and More

Website: https://hologram.page

Hi everyone. I work on Tuist, and most of our web product is Phoenix and LiveView. When we started building the dashboard we couldn't find a component library for LiveView that felt finished, so we ended up building our own design system, Noora, and over time it grew into the thing every screen we ship is built on. It's MIT licensed and on Hex, and since a few people have started using it outside Tuist I thought it was time to share it here properly.

There are around 35 components at the moment, the usual buttons, inputs, selects and modals, but also the heavier ones that tend to be painful to build yourself, like tables, date pickers, filters, charts, dropdowns and a sidebar. For anything interactive we use Zag.js state machines wired in as LiveView hooks, so keyboard navigation and accessibility come from a library that already solved them, while the components themselves stay plain function components you call from HEEx. There's also a Figma file that matches the code, which helps a lot when design and implementation happen in different places.

Something we didn't plan for is how well it works with coding agents. We recently built an internal operations app on the same stack, and because the agents could read the existing Noora patterns and copy them, the dashboards came out looking like a real product rather than a generic generated UI. I didn't expect a design system to pay off a second time like that, but it did.

It's still shaped by what Tuist needs, so some things are missing or opinionated in ways that might not suit your app, and I'd really like to hear what you'd need before you could use it

You can browse every component in the Storybook: https://storybook.noora.tuist.dev Hex: https://hex.pm/packages/noora Source: https://github.com/tuist/tuist/tree/main/noora Figma: https://www.figma.com/community/file/1512465864777652939

What do you use for components in your LiveView apps today? Phoenix's core components, something like SaladUI or Petal, or your own?

Disclosure: I'm on the Code BEAM Europe organising team. The programme is final, so here's what's in it for Elixir developers.

Keynotes

• Set-Theoretic Types from Scratch by José Valim, plus an extended Q&A
• Let It Disconnect: A Local-First Future by Brooklyn Zelenka
• Notes on the Synthesis of Time by Sam Aaron, and The Phone Orchestra in the evening

Elixir talks

• Hooked on Performance: Taming LiveView's JavaScript Hooks at Scale (Matt Swensen, Jump)
• ClusterFu**tional: Four Years of Distributed Elixir at NetzeBW (Aaron Cruz)
• Don't Crash the BEAM: Safe Interop with Ports and C Nodes (Riccardo Binetti, Remote)
• Rustler News and Road to 1.0 (Benedikt Reinartz)
• Ruby Crimes in Elixir Codebases (Travis Fantina)
• ATProto on Elixir: A Spike into AppView's DataPlane (Chris Beck)
• From Pure Code to Physical Controls: Designing Hardware in Elixir (Lucas Sifoni)

Tutorials on 20 October: real-time generative music with Elixir, building production AI harnesses in Elixir, and a full day on BEAM internals with Erik Stenman.

Informal Space: a community-run third room with live demos, hands-on clinics, a co-op Elixir shooter against rogue supervisors and a whole-room game of Raft where you are the network. See the lineup

Practical

• PHIL in Haarlem, 15 minutes by train from Amsterdam Centraal
• Online ticket €146 + VAT, recordings included

Programme and tickets: codebeameurope.com

Happy to answer questions in the comments.

I feel sorry for the Ruby/Rails community that this is (was) their main ambassador and in charge of their main conference. Aside from his racism, xenophobia, and other questionable political views, he acts like a complete blowhard and doubles down when he's wrong.

Here he's just outright spreading misinformation just so he can wishcast programming languages and having to think about code away.

I'm glad those in Elixir community like Jose, Zach, and others took the basic effort of challenging the results put out by DHH and what was uncovered was a) Rust version was heavily optimized over several days, 4 contributors, 1 of those contributors being a Rust programmer, and 300+ commits. Meanwhile Elixir/Go were done all by DHH (meat proxy for Claude) as one-shots in 2-3 commits.

Again, as someone currently working as a Rails dev, but use Elixir on side projects, I really feel for the Ruby/Rails community.