Engineering note · 3 of 6

One funnel. Refuse insecure start.

Every run admission path — Agent Protocol, stream/wait, cron, agent-to-agent, MCP tools/call — goes through createRunCtx. And runkite serve will not listen at all until the plane can prove a production-safe posture.

createRunCtx is the choke point

Handlers stay thin. The shared funnel does the work that must never diverge across entry points:

alias → load agent → rate limit
admission gates   kill / agents:<id>:run / policy run.create
claim thread       idle → busy (409 if already owned)
A2A depth/breadth · insert run · build assignment (generation=1)
→ return (run, assignment) · caller enqueues
        

• Thread claim is atomic — one active run per thread; two creators cannot both win.
• A2A bounds — child depth and breadth checked only on the internal runner-authenticated path; public clients cannot forge parent_run_id.
• Assignment carries generation=1 — fencing starts at create, not as an afterthought on reclaim.

Fail-closed serve

An earlier default let serve boot on SQLite + in-process + no runner tokens + no client auth — still green on /readyz, so Kubernetes happily sent production traffic. That is gone.

Before listening, admission checks:

• Durable state — POSTGRES_DSN / MYSQL_DSN / MONGO_URI
• Shared transport — REDIS_URL / NATS_URL / KAFKA_URL
• Runner tokens — any RUNNER_TOKEN_*
• Client auth — auth configured in langgraph.json

Any miss → clear error, exit 1, never listen. Escape hatches are explicit: RUNKITE_ALLOW_INSECURE_SERVE=1, RUNKITE_MODE=test, or runkite dev for the zero-dependency laptop path.

Fail-closed ≠ fail-open everywhere

Serve admission and policy Decide deny when unsure (security). Rate limiting fails open on a Redis blip (availability). Same word, different risk preference — do not conflate them.