For the complete documentation index, see llms.txt. This page is also available as Markdown.

Choose an Adapter

Pick the Kitaru integration path for your existing agent harness

Kitaru does not require one agent framework. Pick the boundary that matches the code you already have.

Decision table

You have...
Use this
Replay boundary
First page

Plain Python functions

@flow + @checkpoint

Your function boundaries

PydanticAI agent

KitaruAgent

model/tool/MCP calls by default, or one turn checkpoint

OpenAI Agents SDK agent

KitaruRunner

per-call checkpoints or one runner-call checkpoint

Claude Agent SDK invocation

KitaruClaudeRunner

one completed Claude invocation

LangGraph graph

KitaruGraphRunner

one graph call, or middleware-wrapped model/tool calls

Pick by goal

Strategy notes

Strategy
Best for
Trade-off

Coarse checkpoint

Fast migration, easy .wait() return value, low adapter complexity

Replay reruns the whole agent turn if it fails inside the turn

Granular checkpoints

Expensive LLM/tool chains where partial replay matters

More checkpoint rows and stricter rules around waits/nesting

Explicit raw checkpoints

Maximum control and framework independence

You decide every durable boundary yourself

Human-in-the-loop rule

kitaru.wait() belongs at flow scope, not inside a normal checkpoint body. If your harness adapter creates granular tool checkpoints, configure wait-bearing tools so the adapter keeps that wait outside the synthetic checkpoint wrapper.

Start with:

Next

Run a small adapter example from Examples before porting a production agent. The fastest useful proof is one completed execution where you can see the expected checkpoint shape.

Last updated

Was this helpful?