CrewAI and Kitaru solve different problems at different layers. CrewAI is an agent harness: model your agents as a crew of roles, give each one a task, and let crew.kickoff() coordinate the work. AMP wraps the whole thing in a managed platform on top. If your problem is shaped like teamwork and role-based delegation, CrewAI is built for that.
Kitaru is a replay-based eval layer: it records every run as a session, and a session re-executes — unchanged for a faithful baseline, or forked with one thing changed. There’s no first-class CrewAI adapter yet, so the honest path in is to import the traces you already collect (Langfuse, LangSmith, Braintrust, or OTel) — an imported session replays and evaluates exactly like a recorded one. If you want native recording, the fastest path is a project-local adapter built with the kitaru-adapter-builder agent skill; it lives in your repo, not ours.
Use Kitaru if you are
- Running a CrewAI crew (or any agent) in production and want to test a change against real history instead of a vibe check
- Already tracing crew runs to Langfuse, LangSmith, or Braintrust and want those traces runnable, not just readable
- Turning the sessions that caught a failure into a cohort that gates every future change
- Comparing a model or prompt swap on the same frozen population before you ship it
- Self-hosting eval infrastructure so traces and credentials stay in your own systems
Use CrewAI if you are
- Modeling agent teams where roles, goals, and task delegation are the main abstraction
- Standardizing your whole stack inside CrewAI's model and AMP
- Wanting a packaged managed platform with visual building, automations, and tracing
CrewAI designs how the crew collaborates. Kitaru proves whether a change to it actually helped.
Different questions, different layers
CrewAI is asking: how do I model a team of agents that collaborate on a task? Kitaru is asking: once that crew ships, which of its runs can I re-run? Import its traces, replay them, and see what a change actually did.
- Kitaru doesn’t compete for the harness layer. It has no opinion on roles, tasks, or delegation — that’s CrewAI’s job.
- A CrewAI rollout looks like modeling agents as a crew. A Kitaru rollout looks like importing the traces the crew already produces, or building a small project-local adapter against the recording API.
- The kickoff result — and the trace behind it — becomes a session you can replay with tool calls answered from the recording, or fork with one variable changed.
No adapter? Three honest ways in.
There’s no first-class CrewAI adapter today, and Kitaru would rather say that plainly than fake one. Three paths in, in order of cost: import the traces you already collect (Langfuse, LangSmith, Braintrust, or OTel) — the cheapest, and an imported session replays and evaluates exactly like a recorded one. Build a project-local adapter against the recording API if you want native capture — the kitaru-adapter-builder skill generates the smallest one that works and tells you what it can and can’t see. Or, if the crew runs somewhere you can’t wrap, register it as a function and let Kitaru call your system instead.
kitaru session import sessions.jsonl --importer kitaru/langfuse@latest --agent crew@latest --wait, then replay and evaluate like a native recording.- Import.
kitaru session import crew-trace.jsonl --importer kitaru/langfuse@latest --agent crew@latest --wait— no code change, no adapter, sessions land exactly like a native recording. - Project-local adapter. Ordinary code that calls the recording API and lives in your repo. Wrap the public
crew.kickoff()entrypoint, change nothing else — a recording that changes behavior isn’t a recording. - Function agent. When the crew runs somewhere you don’t control, register it as a function; Kitaru calls it, and the session adopts once you import the result.
Self-hosted, on your own cloud
CrewAI AMP is a managed agent platform with a hosted control plane. If you want the platform handled for you, that’s a real value proposition. Kitaru takes the opposite trade: one self-hosted FastAPI + Postgres server, workers that execute replays and evaluations inside your environment, and sessions that never have to leave your systems.
- Self-hosted, Apache 2.0. One server, run it however you run services today.
- Workers in your environment. Replays, imports, and evaluations execute where you deploy them — your traces and credentials don’t leave your systems.
- Beside your observability, not instead of it. Langfuse, LangSmith, and Braintrust remain where you watch production; Kitaru is where you re-run it.
Bring-your-own harness vs CrewAI abstractions
CrewAI asks engineers to model their agents inside its building blocks. Kitaru asks for a trace. The harness underneath a session can be CrewAI, Pydantic AI, the OpenAI Agents SDK, or hand-written Python — Kitaru mostly cares whether it can see a recording, not how you produced it.
from crewai import Agent, Task, Crew researcher = Agent(role="Researcher", ...) writer = Agent(role="Writer", ...) research = Task(agent=researcher, ...) draft = Task(agent=writer, ...) crew = Crew(agents=[researcher, writer], tasks=[research, draft]) crew.kickoff(inputs={"topic": "agents"})
# No CrewAI adapter yet — import the trace kitaru session import crew-trace.jsonl \ --importer kitaru/langfuse@latest --agent crew@latest # A Pydantic AI agent — native adapter, one wrapper from kitaru_pydantic_ai import KitaruAgent support = KitaruAgent(agent, agent_id=AGENT_ID) support.run_sync(text)
- Native or imported. Pydantic AI, the OpenAI Agents SDK, LangGraph, Mastra, and the Vercel AI SDK have a first-class adapter. CrewAI doesn’t yet — import its traces, or build a project-local adapter against the recording API.
- No graph DSL. Whatever the harness decides — task delegation, tool calls, conditional branches — Kitaru records the result rather than re-implementing the decision logic.
- Different harnesses, one eval layer. When different teams pick different harnesses, one place to record and replay is a smaller ask than one harness across the org.
What makes Kitaru unique
| Feature | Kitaru | CrewAI |
|---|---|---|
| Multi-agent abstractions (Agents, Tasks, Crews, Flows) with role-based delegation | Not supported | Yes |
| Tools, knowledge/RAG, MCP servers, and an integrations marketplace | Not supported | Yes |
| Visual no-code agent builder and AI copilot (AMP) | Not supported | Yes |
| Built-in unified Memory system for agents | Not supported | Yes |
| Record production runs as replayable sessions | Yes | Not supported |
| First-class adapter (no CrewAI adapter yet — import a trace or build a project-local one) | PartialPartial support | Not supported |
| Replay with tool calls answered from the recording — nothing touches real systems | Yes | Not supported |
| Cohorts: frozen, immutable session sets | Yes | Not supported |
| Experiments: same cohort, one variable moved, compared | Yes | Not supported |
| Deterministic and model-graded evaluators | Yes | Not supported |
| Self-hosted eval server with no mandatory hosted control plane in the data path | Yes | Not supported |
| Framework portability (record or import CrewAI, Pydantic AI, OpenAI Agents, LangGraph, or raw Python runs) | Yes | Not supported |
How the two surfaces map
| Concept | CrewAI | Kitaru |
|---|---|---|
| Layer | Agent harness (how the crew collaborates) | Replay-based evals (how you test what it did) |
| Core unit | Crew run (kickoff) | Session — recorded model and tool calls, re-executable |
| Composition | Standalone framework, AMP on top | Imported trace, or a project-local adapter |
| Tool calls in tests | Hit real systems, or you mock them by hand | Answered from the recording per tool policy |
| “Did my change help?” | Read the trace or AMP dashboard, compare by eye | Two runs over the same cohort, diffed |
| Getting a session | No adapter yet — import the trace you already collect | First-class for Pydantic AI, OpenAI Agents SDK, LangGraph, Mastra, Vercel AI SDK |
| Where it runs | Your process, or AMP’s hosted control plane | Self-hosted server; workers replay in your environment |
Code comparison
# CrewAI has no first-class Kitaru adapter yet.
# Import the trace you already collect instead:
#
# kitaru session import crew-trace.jsonl \
# --importer kitaru/langfuse@latest \
# --agent crew@latest --wait
#
# The imported session replays and evaluates
# exactly like a recorded one.
import kitaru
client = kitaru.KitaruClient()
cohort = client.cohorts.create("hard-crews", sessions=session_ids)
experiment = client.experiments.create("cheap-model", model="gpt-5-mini")
before = experiment.run(cohort=cohort, version="v1")
after = experiment.run(cohort=cohort, version="pr-311")
client.compare(before, after)from crewai import Agent, Task, Crew, Process
researcher = Agent(
role="Researcher",
goal="Produce a brief on {topic}",
backstory="Senior research analyst.",
llm="openai/gpt-4o-mini",
)
writer = Agent(
role="Writer",
goal="Write a draft from the brief",
backstory="Editor with a sharp ear.",
llm="openai/gpt-4o-mini",
)
research = Task(
description="Research: {topic}. Return a brief.",
expected_output="A short research brief.",
agent=researcher,
)
draft = Task(
description="Write a draft from the brief.",
expected_output="A short blog draft.",
agent=writer,
)
crew = Crew(
agents=[researcher, writer],
tasks=[research, draft],
process=Process.sequential,
)
# This kickoff produces a trace Kitaru can import.
result = crew.kickoff(inputs={"topic": "Q3 roadmap"})Put replay-based evals under your CrewAI crew
If your problem is designing how a team of agents collaborates, CrewAI is built for that and worth adopting. If your problem is proving that a change to the crew actually helped, Kitaru sits one layer underneath — import the traces you already collect today, or build a small project-local adapter when you want native recording.
uv add "kitaru[cli,worker]" kitaru-pydantic-ai