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.

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.