Build

Migrate existing agents

You already have graphs or crews. Goal: runners speak Runner Protocol; clients keep Agent Protocol; the plane owns governance — without rewriting your whole product.

What it is

Package each workload as a runner process (LangGraph Py/JS first-class; CrewAI / LlamaIndex / AutoGen / LangChain via adapters). Point config at existing entrypoints; register agent_ids; move secrets into connectors where side effects leave the box.

Why it is here

“Rip out the framework” is a non-goal. The plane wraps execution. Migration succeeds when runs are dispatchable, observable, and governable — not when every line of agent code is new.

How to implement

Inventory — list agent entrypoints, checkpoint stores, tools that need secrets, HITL points, cron/triggers.
Pick runner kind — LangGraph stay on LangGraph runners; others use python/adapters/* (see matrix).
Wire config — langgraph.json / adapter config with stable agent_ids matching what clients will call.
Checkpoints — LangGraph: direct Postgres or HTTP opaque proxy. Adapters (CrewAI / LlamaIndex / AutoGen / LangChain): set RUNKITE_HTTP_URL so the generic worker load/saves opaque message transcripts — clients can send only the new turn.
Secrets — stop baking tokens in agent env long-term; move side-effect tools to connectors + grants.
Cutover — run shadow traffic on the plane; compare outputs; switch clients to plane base URL + API keys.

In the product

What to expect

Same client shape — last human message in, AI message out keeps multi-framework fleets manageable.
Concurrency — CrewAI/AutoGen may serialize per graph; do not assume --concurrency N equals N parallel crews.
Honesty — registry publish ≠ deploy; you still wire runners.

Reference: Framework matrix · Checkpoints · docs/runners.md