1 · The big picture

Air-traffic control for agents — not another agent framework.

What problem does Runkite solve?

You want to run AI agents in production across frameworks (LangGraph, CrewAI, LlamaIndex, AutoGen, …). Each framework has its own runtime, state, and conversation habits. If you run them as loose scripts, you have no shared control: no single place to see work, enforce policy, kill a runaway, require human approval before a dangerous tool call, or mint credentials without copying secrets into every process.

Runkite sits in the middle as a control plane — one Go binary that coordinates. Agents still do the flying (LLM calls, tools); the plane decides who may fly, with which fuel (credentials), under which rules, with an audit trail.

What Runkite is not

It does not import LangGraph or CrewAI. It does not call OpenAI or Anthropic. It does not claim to solve prompt injection or PII redaction as a product. Those are different jobs. The plane coordinates: accept client requests, dispatch to runners, stream results, vend connectors, enforce policy, keep audit. Execution lives in separate runner processes that do import frameworks and call LLMs.

One sentence

Runkite is a self-hosted control plane between your application and your agent workers — dispatch, streaming, multi-tenancy, auth, policy, credentials, and observability — regardless of which agent framework the workers use.

Where the pieces live (public tree)

• Control plane — Go binary + embedded Admin UI
• Runners — Python and TypeScript packages speaking Runner Protocol
• Clients — any Agent Protocol HTTP/SSE/WebSocket client

Next: three processes · why Agent Protocol