2 · Three processes

Client, control plane, runner — understanding each boundary is the foundation.

1 · Client (your application)

Speaks Agent Protocol over HTTP, SSE, or WebSocket: create threads, start runs, stream tokens, cancel, resume. The client never sees which runner executed the work, gRPC internals, reclaim generations, or queue keys. Vocabulary is threads, runs, agents, events, store.

2 · Control plane (Runkite)

The Go binary (runkite serve / local dev). It authenticates, stores metadata on your configured state backend, enqueues work, fans events back to clients, mints connector sessions, enforces policy, serves Admin, and exposes Runner Protocol to workers.

It does not import agent frameworks, call LLMs, or execute your Python / TypeScript agent code. Framework-agnostic by construction.

3 · Runner (worker)

Python or TypeScript process that connects over gRPC, pulls jobs, runs framework code, calls LLMs, streams events, heartbeats, and watches cancels. It does not serve end-user HTTP, decide tenancy policy, or own durable run metadata — that stays on the plane.

Relay (simplified)

Multi-replica detail (which CP holds the SSE vs which enqueued the job) lives in the longer notes; the mental model stays: clients never talk to runners directly.

Next: two protocols · why fail-closed serve