Embabel Agent Framework

You will like how little is new here. Agents are ordinary components in the application framework your team already knows, wired the way everything else is wired, and that familiarity is the deciding daily trait, because the cost of an agent library is mostly the cost of learning a second set of conventions in a codebase that already has one.

Pick it if your estate runs on this stack and the agent must live inside it. Pick Koog when you want the same language with a lighter footprint and no application framework underneath.

Derived control flow is the trade this framework asks you to accept. When the sequence of actions is the output of a search rather than a sequence you authored, a production incident begins with working out what it decided to do and why, which is a harder question than reading a chain. Search spaces also grow quietly as actions are added, so the tenth action changes the behaviour of the first nine.

What it does right: actions and goals are declared against typed domain objects, so the search operates over things the compiler has already checked.

1. The architecture is planning in the older sense: a goal, a set of actions with declared effects, and a search for a route between them, which is a well-studied family of algorithms rather than an invented one. That heritage is why it will survive model changes better than a design where the model chooses the next step. 2. Verification is whatever the actions themselves assert, so correctness is pushed to the code rather than the prompt.

No benchmark is published. The observation: this is one of the few frameworks here whose core idea predates the models it uses.

Growth this fast in a conservative ecosystem is a real signal, and the ecosystem itself is the whole moat: enterprises on this platform move slowly, buy from vendors they recognise and stay for a decade, which makes distribution here durable and slow. What is missing is any mechanism for turning that into revenue, and a hub site with no pricing page usually means the plan is still being written.

Likely acquirer: an enterprise platform vendor that already sells into this ecosystem. Position: watch it, and expect a hosted or supported tier within the year.

One sentence on the demo: it reached the goal by a route nobody specified. Commercially this is the easiest kind of adoption, because it enters through the same dependency declaration as every other library we use, with no new vendor and no new agreement. The starter for a major cloud vendor's inference matters more than it sounds, since that contract already exists and the data terms are already reviewed. Nothing here runs unattended on its own.

Onboarding is three days for a platform engineer. Approved with conditions: one service, existing inference contract.

Local inference is a dependency line and an environment variable, which is the correct amount of ceremony. Nothing about the design privileges a hosted provider, so my own hardware is a first-class target and my key never leaves the machine when I do not want it to.

The protocol support goes both directions: it consumes tool servers, including a catalogue I already have installed, and it can be published as one, so an agent I build here becomes something my other tools can call. Permissive licence over readable source on a platform with a thirty-year toolchain. A fork here would still compile in a decade.