helenapankov

Hi HN, I’m the author of A11, an Apache 2.0 toolkit for building streaming, multimodal, and agentic applications.

I started A11 to make some particular, hands-on things easy about building an agent or an API for generative AI, e.g.: how to avoid verbose manual serialisation "hops", how to make client code similar to server code, how to make tools easy to test or reuse, etc.

I started the project while working at DeepMind, and that was before MCP, before many agentic frameworks and tooling, yet as that tooling came out, I noticed that any tool made to make agentic development simple instead tended to become an obstacle to work around itself: with some, you suddenly need your code to be in a specific class (so logic tends to become gated behind a dependency), with others you always need to keep in mind their graph executor or complex runtime details. When harnesses started to come by, many of them only offer features from inside the harness, as opposed to neat, isolated code.

So the central idea I explored in A11 in reaction to that was: "what if instead of a sticky, package offering, an agentic toolkit was well layered, and you could make good use of these layers AND make use of your other tools, keeping your own architecture?"

The layering in A11 starts with nodes (representing typed streams closely to an async queue or a Go channel), and actions, which are just pieces of named pieces of executable code with a description and declared input and output nodes (so named streams that you can use to transport text output, thoughts, progress metadata etc. separately without parsing a big envelope). That already is useful to coordinate asynchronous execution locally.

The same action can be a local helper, or a model tool, or a served RPC, or a job definition for a worker pool, without being rewritten completely.

From there, there are enough layers to build agents or complete harnesses: for tool use, remote execution, pluggable storage, existing LLM provider integrations, etc. You may, but don't _have to_ use those layers, and can use exactly as much as you need. I miss that in other frameworks, and have found that building with A11 feels much more versatile and much less cognitively heavy.

The project is evolving, but it has reached a stage where I want people to try it and gather feedback:

* does the idea of several named streams per action/tool sound as an improvement over current de facto standards like event streams, content blocks, and others?

* does the optional layering feel refreshing, or just as more things to understand?

* what’s one boring agentic infrastructure problem you wish you could delegate?

* do you also feel like most popular tools and frameworks lock you into too much specifics for not enough benefit?

Yeah, this is true—insufficient engineering experience to even recognise these issues is part of the problem. +1 to "fine-tuning" specifically the language or a workflow, too. I did it in the article and many people around are doing the same, apparently.

But still, in my experience, even in places with good engineering expertise and culture, there is also pressure to ship really fast, so systematic approaches to these things get overlooked, and gradual slopification happens. No perfect answer as to what to do with this, but I think it's important to name the problem and offer at least some easy solutions.

Thanks! That's good feedback—you're not too far in guessing the "100 conversations" background, and you're right it doesn't have to define the presentation.

I think all of it makes sense—I've been putting off writing the steadier, more easy going walkthroughs, but they should really make a difference.

Note: I am the core author, would be grateful for feedback and happy to answer questions. The landing page at the main URL has a detailed motivation for the project.

It's not something currently backed broadly, but a flexible, quick-feedback way to navigate the landscape of AI infrastructure demands—an experiment from me and early internal supporters at Google DeepMind.

Current frameworks solidified around abstractions that are growing increasingly inadequate for the new demands of multimodal, streaming, stateful, long-running applications. Action Engine aims to be a common building block for these new kinds of applications, without imposing rigid abstractions or heavy dependencies, adapting to applications.