AgentKit by Inngest: Deterministic Multi-Agent Routing in TypeScript

The routing problem AgentKit was built to solve

Most agent frameworks let the model decide what happens next. One agent finishes a turn, the LLM picks a tool or another agent, and the control flow lives inside a prompt. That works until it doesn't: a prompt change silently reroutes traffic, a model upgrade alters which branch gets taken, and debugging means reading transcripts rather than code. AgentKit takes the opposite position. The README describes it as offering "more deterministic and flexible routing", and the core concepts list puts Routers front and centre, described as "where the autonomy lives, from code-based to LLM-based (ex: ReAct) orchestration".

The audience is TypeScript developers building multi-step AI workflows: coding assistants, research pipelines, support agents that hand off between specialists. The repository ships nineteen examples covering exactly those shapes, from examples/quick-start and examples/agentkit-starter through examples/code-assistant-agentic, examples/deep-research and examples/support-agent-human-in-the-loop. If you are writing Python or want a visual builder, this is not aimed at you.

State, routers and the read/write contract between them

The mechanism is a shared key-value store called State, held by the network and readable or writable from four places. The README's diagram marks the difference explicitly: the system prompt has read-only access, while tools, lifecycle callbacks and the router all get read/write access. That asymmetry is the whole design. An agent's tool writes a result into State, and the router reads it to decide the next agent.

The MCP example in the README shows the pattern in about ten lines. A tool named done stores the final answer with network?.state.kv.set("answer", answer), and the router checks for it:

router: ({ network }) => {
  if (!network?.state.kv.get("answer")) {
    return neonAgent;
  }
  return;
},

Returning an agent means run it again; returning nothing ends the network. There is no hidden LLM call in that decision. The README also shows the prompt side of the contract, where a system prompt is a function that reads State to build its text: system: ({ network }) => { const suggestions = network?.state.kv.get("suggestions") || []; ... }. State is typed, so the shape of what tools write is the shape routers read. The cost is that you own that schema, and a tool that writes the wrong key will leave the router looping until you notice.

Installing AgentKit and running a first MCP agent

Installation is two packages, not one. Since v0.9.0 the README requires inngest as a separate dependency so that multiple packages depending on different Inngest versions do not conflict at runtime:

npm i @inngest/agent-kit inngest

A minimal agent needs a model provider, a tool, and an MCP server entry. The README's Neon example imports anthropic, createAgent, createNetwork and createTool from @inngest/agent-kit, createServer from @inngest/agent-kit/server, createSmitheryUrl from @smithery/sdk/config.js, and z from zod. The agent is created with a name, a system prompt, a tools array and an mcpServers array whose transport is typed as streamable-http with a url field. The network then wraps the agent with a defaultModel and a router.

Starting the server is a plain Node listen call, and the README prints a message on port 3010:

const server = createServer({
  networks: [neonAgentNetwork],
});

server.listen(3010, () =>
  console.log("Support Agent demo server is running on port 3010")
);

The README points to examples/mcp-neon-agent for a runnable version of this, and to the Inngest Dev Server for local tracing. Expect to supply your own API keys for the model provider and for any hosted MCP endpoint; the Smithery URL in the README carries placeholder credentials that will not work as written.

Where the deterministic model gets in your way

Deterministic routing is a constraint, not a free upgrade. If your task genuinely needs open-ended planning, where the model should decide how many steps to take and in what order, a code-based router forces you to encode that decision tree yourself. The README acknowledges the spectrum and recommends starting code-based, but it does not document an automatic fallback when a router returns nothing unexpectedly: returning undefined ends the network, which is the correct behaviour for the done-tool pattern and a silent failure for a typo in a state key.

The dependency split is the other sharp edge. Requiring a matching inngest package alongside @inngest/agent-kit means version drift between the two is a runtime concern rather than a type error, and the README frames the split as existing precisely because mismatched versions caused conflicts. Nothing in the README describes rollback behaviour for a deployed network, so teams running agents in production should not assume a failed run can be resumed from the middle. Finally, the last push to the repository was on 2026-04-29, and the most recent release listed is @inngest/[email protected] from 2025-11-13. The version numbers are still pre-1.0, which is the honest signal about API stability.

AgentKit compared with n8n and general-purpose agent SDKs

The comparison people search for is agent kit vs n8n, and the difference is not cosmetic. n8n is a workflow automation tool with a visual editor and hundreds of prebuilt integrations; you assemble a flow by connecting nodes, and the orchestration logic lives in the graph you drew. AgentKit has no visual editor. Orchestration lives in a TypeScript router function, and the unit of work is an agent with a system prompt, tools and optional MCP servers. If your integration needs are mostly SaaS APIs and your team is not writing TypeScript, n8n covers more ground with less code.

Against general-purpose agent SDKs, the distinguishing choice is the shared State object. Many SDKs pass conversation history between agents and let the model infer what to do next. AgentKit keeps a typed key-value store that tools write to and routers read from, which means the routing decision can be a plain if statement. That is a smaller surface to reason about and a larger amount of code you write yourself. The MCP support is also worth separating out: mcpServers is a first-class field on createAgent, so an agent can borrow tools from any MCP server rather than requiring a bespoke tool wrapper per integration.

Licence, package layout and what upgrades cost

The repository is Apache-2.0, with the licence text at LICENSE.md. That permits commercial use and modification and includes an explicit patent grant, which matters if you are shipping agent infrastructure inside a product. It is not a copyleft licence, so it does not force you to publish your own network code. This is a description of the licence identifier, not legal advice; check the terms against your distribution model.

The monorepo is a pnpm workspace, with pnpm-workspace.yaml at the root and packages under packages/. The root package.json builds with pnpm -r --filter './packages/*' --if-present run build and releases through Changesets, so version bumps are per-package rather than whole-repo. Upgrading means tracking @inngest/agent-kit and inngest together, plus any MCP client packages your agents import. Because the published version is still 0.x, minor releases can carry breaking changes under semver conventions; the README's note about the v0.9.0 dependency split is a concrete example of that happening. Budget for reading release notes before each bump rather than relying on a caret range.

Editorial conclusion

Adopt AgentKit if your agents need explicit, reviewable routing and you are already comfortable in TypeScript and the Inngest execution model. Skip it if you want a no-code builder or a Python stack. Before committing, verify that the pinned inngest peer dependency resolves cleanly in your lockfile, that your chosen model provider is one of the supported ones, and that the Apache-2.0 licence terms fit your distribution plan.

Frequently asked questions

Official sources

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