A truly flexible API and agent builder's kit, with smooth devX for streaming, multimodality and integrations

Helena Pankov — Mon, 27 Oct 2025 15:54:41 +0000

Hi everyone!

I have been working on a toolkit/framework to build APIs and agents easily, in a way friendly to developers that does not hide complexity behind abstractions, but also be is in step with modern requirements and capabilities: stateful, async execution, streaming, multimodality, persistence, etc.

I thought sharing would be a perfect opportunity to get feedback, and also that the library itself is genuinely useful, so feedback is very welcome! Quick link: https://actionengine.dev/.

Why another framework?

I don't really like the word, but it's hard to find anything better and still have people understand what the project is about. The problem of “agentic frameworks” is that they give excessively rigid abstractions. The novel challenge is not to define “agents”. They are just chains of calls in some distributed context.

The actual novel challenge is to cultivate a common language to express highly dynamic, highly experimental interactions performantly (and safely!) in very different kinds of applications and environments—and build tools to do so. In other words, the challenge is to acknowledge and enable the diversity of applications and contexts code runs from.

That means that the framework itself should allow experimentation and adapt to applications, not have applications adapt to it.

I work at Google DeepMind (hence releasing Action Engine under the org), and the intention for me, co-authors and internal supporters is to validate some shifts we think the agent landscape is experiencing, and have a quick-feedback way to navigate that, including checking very non-mainstream approaches. Some examples for me are:

developers don't seem to really need “loop runner” type frameworks with tight abstractions, but rather a set of thin layers they can combine to:
- relieve “daily”, “boring” issues (e.g. serialisation of custom types, chaining tasks),
- have consistent, similar ways to store and transmit state and express agentic behaviour across backend peers, browser clients, model servers etc. (maybe edge devices even),
- “productionise”: serve, scale, authorise, discover,
it is important to design such tools and frameworks at the full stack to enable builders of all types of apps: web/native, client orchestration or a worker group in a cluster, etc.,
data representation, storage and transport matter much more than the runtime/execution context.

I'm strongly convinced that such a framework should be absolutely flexible to runtimes, and should accommodate different “wire” protocols and different storage backends to be useful for the general public. Therefore interactions with those layers are extensible:

for “wire” connections, there are websockets and WebRTC (and Stubby internally at Google), and this can be extended,
for “store”, there is an in-memory implementation and one over Redis streams (also can be extended!)

What the library is, exactly

Action Engine is built as a kit of optional components, for different needs of different applications. That makes it stand out from other frameworks: they lock you in the whole set of abstractions, which you might not need.

The core concepts are action and async node. “Action” is simple: it's just executable code with a name and i/o schema assigned, and some well-defined behaviour to prepare and clean up. Async node is a logical “stream” of data: a channel-like interface that one party (or parties!) can write into, and another can read with a “block with timeout” semantic.

These core concepts are easy to understand. Unlike with loaded terms like “agent”, “context” or “graph executor”, you won't make any huge mistake thinking about actions as about functions, and about async nodes as about channels or queues that go as inputs and outputs to those functions.

The rest of the library simply cares about building context to run or call actions, and lets you do that yourself—there are implementations:

for particular-backend wire streams,
for sessions that share a data context between action runs,
for services that hold multiple sessions and route wire connections into them,
for servers that listen to connections / do access control / etc.

...but it's not a package offering. No layer is obligatory, and in your particular project, you may end up having a nicer integration and less complexity than if you used ADK, for example.

Flexibility to integrate any use case, model or API, and flexibility to run in different infrastructure are first-class concerns here, and so is avoiding large cognitive footprint.

Anyway, I'd be grateful for feedback! Have a look, try it out—the project is WIP and the level of documentation is definitely less than needed, but I'll be happy to answer any questions!

Links

Landing page with a few nice demos: https://actionengine.dev/

Code examples in Python, TypeScript, C++: https://github.com/google-deepmind/actionengine/tree/main/examples

To get an overall grasp, check out the stateful ollama chat sessions example: demo, backend handlers, server, chat page frontend code.

DEV Community: Helena Pankov

A truly flexible API and agent builder's kit, with smooth devX for streaming, multimodality and integrations

Why another framework?

What the library is, exactly

Links