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?
helenapankov•41m ago
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?