AgentKit: deterministic routing for TypeScript multi-agent networks, built on Inngest

The problem: agent frameworks hide the control flow you need to debug

Most agent frameworks put a model in charge of deciding what happens next. That is convenient until a run does something unexpected, at which point the reason is buried in a prompt and a sampled token. AgentKit takes the opposite position. The README states it offers "more deterministic and flexible routing", and the mechanism for that is a router function you write, which receives the network and returns the next agent to run, or nothing to stop. The audience is TypeScript developers building multi-step LLM workflows who want the orchestration expressed in code they can read, test and step through. The README frames this explicitly: it recommends starting with code-based routing because it "provides complete control over your network execution flow" and is "the most deterministic" pattern. If your workflow has a known shape (analyze, then document, then summarize, then stop), AgentKit lets you write that shape down rather than hope the model rediscovers it on every run.

State is the routing substrate, and it is readable and writable from four places

The core of AgentKit is a key-value state shared by every agent in a network. The README's diagram shows the arrows: state flows one way into the system prompt, and bidirectionally to tools, lifecycle callbacks and the router. That asymmetry matters. Prompts read state; tools, callbacks and the router read and write it. The routing decision is therefore a function of data that agents themselves produced. In the MCP example, a tool named done writes the model's answer into network.state.kv under the key "answer", and the router is a three-line function: if network.state.kv.get("answer") is empty, return the agent; otherwise return undefined and the network halts. In the code-review example, a shared save_suggestions tool appends to an array in state, and a summarization agent builds its system prompt from that array at call time. This is the design worth evaluating. Routing is not a separate planning layer bolted on top; it is a read of the same store the tools write to. The cost is that you own the state schema and the invariants. Nothing in the material suggests AgentKit validates what your tools put into the kv store, so a tool that writes the wrong key or the wrong shape will silently change routing behaviour rather than raise an error.

Getting it running: two packages, a router, and a local dev server

Installation is one command from the README: npm i @inngest/agent-kit inngest. The second package is not optional. The README notes that starting with AgentKit v0.9.0 you must install inngest as a separate dependency alongside @inngest/agent-kit, to avoid conflicts when multiple packages depend on different Inngest versions. A minimal network needs four imports (anthropic, createAgent, createNetwork, createTool) plus createServer from @inngest/agent-kit/server. You define agents with createAgent, passing a name, a system prompt that may be a string or a function of the network, and a tools array. Tools are built with createTool and a zod schema for parameters. The network is created with createNetwork, taking name, agents, a defaultModel, and the router. The README's server example calls createServer({ networks: [neonAgentNetwork] }) and then server.listen(3010, ...). For local work the README points at the Inngest Dev Server, and the tracing page is linked under getting-started/local-development. Note the model string in the example, claude-3-5-sonnet-20240620: that identifier is old, and you should expect to substitute a current one rather than copy it.

MCP servers are configured per agent, not per network

Tooling beyond hand-written functions comes in through the Model Context Protocol. In the README example, mcpServers is a field on the agent, an array of objects with a name and a transport. The transport shown is { type: "streamable-http", url: ... }, and the URL is built by createSmitheryUrl from @smithery/sdk/config.js against a Smithery-hosted Neon server. Two things follow from that shape. First, MCP configuration is scoped to an agent, so two agents in the same network can reach different tool servers, which is useful when one agent should not see a database. Second, the README's own example puts an api_key directly in the URL string, which is fine for a local demo and wrong for anything committed. The material does not describe how AgentKit handles MCP authentication beyond passing the URL through, so treat credential handling as your problem. The material also does not enumerate which transport types are supported; only streamable-http appears, so confirm others against the docs for your version before assuming stdio works.

The Inngest dependency is the real architectural commitment

AgentKit is not a standalone library. The README states that combining it with the Inngest Dev Server locally and "its orchestration engine" makes agents fault-tolerant when deployed to the cloud. That is the trade: you get durability and tracing for long-running agent steps, and in exchange your deployment story runs through Inngest. For a team already on Inngest this is close to free. For a team that is not, adopting AgentKit means adopting a second platform, its deployment model, and its operational surface, in addition to the npm package. The README does not spell out what happens to a network run outside that engine, and I cannot confirm from the supplied material whether a network executes correctly in a plain Node process without Inngest present. That is the first thing to test in a scratch project before you design around it. The separate inngest peer dependency, required since v0.9.0, is a symptom of the same coupling: version alignment between the two packages is something you now manage.

Where this is the wrong tool

AgentKit assumes a network of named agents and a router that picks among them. If your task is one model call with a few tools and a loop until the model stops requesting tools, the network abstraction adds a state store, a router and a server you do not need. The README's own MCP example is close to that boundary: one agent, one custom tool to signal completion, and a router that checks a single key. That pattern is honest but it is also something a plain loop expresses in fewer moving parts. The second case is a workflow whose branching is genuinely unknown ahead of time and changes shape run to run. AgentKit supports LLM-based routing (the README names ReAct as an example of where "the autonomy lives"), but if you take that path you have given up the determinism that is the project's stated advantage, and you are paying the state and network machinery for a benefit you are not using. The third case is a team without TypeScript. Everything here, from createAgent to the zod parameter schemas, is TypeScript-first, and the README frames the project as supporting "the unstoppable and growing community of TypeScript AI developers". There is no Python story in this material.

Versus writing the loop yourself, or using a graph-based orchestrator

The most direct alternative is not another framework but the absence of one: a function that calls a model, runs the tools it asks for, appends to a messages array, and repeats until a stop condition. The difference is where the control flow lives. In a hand-rolled loop it lives in your code and nowhere else, which is maximally transparent and gives you no tracing, no durable step execution and no shared state abstraction beyond the variables you declare. AgentKit's difference is that the same control flow is expressed as a router over a typed state that tools also write to, and that the run is executed by Inngest's engine rather than by your process. You are trading a small amount of indirection for durability and a tracing view. Graph-based orchestrators make a different trade: they ask you to declare nodes and edges as data, which is easier to visualize and harder to express conditional logic in, since branching becomes a graph construct rather than an if statement. AgentKit's router is a function, so arbitrary branching is a return statement. If your branching is simple, the graph is clearer; if it depends on accumulated state, the function wins. The material does not include a comparison with any named competitor, so treat this as a design distinction rather than a benchmark.

Versioning, maintenance and the Apache-2.0 terms

The release list shows @inngest/agent-kit at 0.13.2 in November 2025, preceded by 0.13.1 in October, with a sibling package @inngest/use-agent at 0.4.0. The leading zero is the signal: this is pre-1.0, so minor versions can carry breaking changes, and the v0.9.0 note about splitting out the inngest dependency is exactly that kind of change arriving in a minor bump. Budget for reading release notes on every upgrade and pinning exact versions in package.json rather than using a caret range. The repository is not archived, and the last push date in the metadata is 2026-04-29, which indicates ongoing work rather than a dormant project. On licensing: the project is Apache-2.0, which permits commercial use and modification and includes an express patent grant; it also requires that you retain copyright and licence notices and state significant changes if you redistribute modified source. That is a description of the licence text, not legal advice. If you fork AgentKit and ship it inside a product, have counsel confirm your notice obligations, and check whether the Inngest runtime you deploy against carries its own separate commercial terms, since that is a different agreement from the npm package's licence.

Editorial conclusion

Adopt AgentKit if your agents already speak TypeScript, your routing logic is something you can express as a function over a shared state, and you are willing to run the Inngest Dev Server locally and the Inngest orchestration engine in production. Do not adopt it if you want a framework that owns the loop for you, if you cannot take a dependency on the Inngest runtime, or if your agent graph is small enough that a single while loop over tool calls would do. Before committing, verify three things against the version you pin: that the inngest package is installed as a separate dependency (required since v0.9.0), that the router signature in your installed version matches the ({ network }) => agent | undefined shape shown in the README, and that your MCP transport type is one the version supports, since the example uses streamable-http. The version stream in the release list (0.13.2 in November 2025, 0.13.1 in October, and @inngest/use-agent 0.4.0) shows a pre-1.0 package, so pin the exact version and read the release notes before upgrading.

Official sources

1. inngest/agent-kit on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases