Skip to main content

Durable execution for AI agents, built on ZenML

Project description

Kitaru

The runtime layer underneath your agent stack.

Kitaru (来る, "to arrive") is a self-hosted, framework-agnostic runtime for autonomous agents — underneath the harness your team already picked. You keep your agent SDK, your prompts, your tools, your model. Kitaru adds durable execution: checkpoints, replay, resume, wait(), versioned deployments, and isolated runtimes, running on your own infrastructure.

PyPI Python License

Docs · Quick Start · Examples · Getting Started Guide · Roadmap · Community


Kitaru Dashboard

🧩 Where Kitaru fits

Agent stacks break cleanly into four layers. Kitaru is exactly one of them.

Layer What it does Examples
Model The LLM itself — a compute unit over a context window OpenAI, Anthropic, Google, open-weights, fine-tuned in-house
Harness The loop around the model — prompts, tools, model loop, framework choice Pydantic AI / Pydantic AI Harness, LangGraph, Claude Agent SDK, OpenAI Agents SDK, raw Python
Runtime (Kitaru) How the agent survives and executes over time — checkpoints, replay, resume, wait(), versioned deployments, isolated runtimes @flow, @checkpoint, flow.deploy(), kitaru.wait(), kitaru.memory
Platform How your org governs — auth, entitlements, interceptors, observability, product UI, policy Your existing stack

Kitaru lives in the middle row. Harnesses define behavior, your stack defines policy, and Kitaru gives you the durable execution layer in between.

If you're buying an agent platform, Kitaru may feel low-level. If you're building one, that's the point.

Platform teams get the durable execution layer they'd otherwise build themselves — run lifecycle, checkpoint boundaries, replay, invocation routing, and self-hosted execution — without mandating which harness application teams use on top.

🎯 Why Kitaru?

Durable execution and memory

  • Durable execution. A crash, pod eviction, or timeout doesn't send the run back to zero. Fix the bug, replay, and the completed checkpoints return cached output instead of re-burning tokens.
  • Pause and resume. kitaru.wait() suspends a flow, releases compute, and resumes minutes, hours, or days later when input lands from a human, another agent, a webhook, or a CLI call.
  • Versioned deployments. flow.deploy() freezes a flow as an immutable snapshot consumers invoke by name. Tag to roll out, re-tag to roll back. Nothing that calls the agent redeploys when a new version ships.
  • Artifact lineage. Every checkpoint output is written to your object store as a typed, versioned artifact. Step through any run, diff artifacts across runs, and trace a bad output back to the step that produced it.
  • Isolated execution. @checkpoint(runtime="isolated") runs a specific step in its own pod or job on Kubernetes, AWS, GCP, or Azure. Heavy or risky steps stay isolated; orchestration stays inline.
  • Durable memory. Scoped, versioned state for long-running agents. Write from Python, read from the CLI or MCP. Agents remember conventions, context, and prior work across runs.

Python-first, no graph DSL

Write normal Python. Use if, for, try/except — whatever your agent needs. Kitaru gives you two decorators (@flow and @checkpoint) and a handful of utility functions. That's all you need.

from kitaru import checkpoint, flow

@checkpoint
def research(topic: str) -> str:
    return do_research(topic)

@checkpoint
def write_draft(research: str) -> str:
    return generate_draft(research)

@flow
def writing_agent(topic: str) -> str:
    data = research(topic)
    return write_draft(data)

result = writing_agent.run("quantum computing").wait()

Deploy on your cloud

A single self-hosted server, your own infra. Flows run on whichever stack you pick — local, Kubernetes, GCP, AWS, or Azure — with artifacts in your own S3/GCS/Azure Blob bucket. No mandatory SaaS control plane.

Built-in UI

Every execution is observable from day one. See your agent runs, inspect checkpoint outputs, and approve human-in-the-loop wait steps, all from a UI that ships with the Kitaru server.

To start the server locally, run kitaru login after installing kitaru[local]. To connect to an existing remote server, run kitaru login <server>.

Works with your agent SDK

Wrap an existing PydanticAI agent with KitaruAgent — no rewrite. For agents built on the OpenAI Agents SDK, Anthropic Agent SDK, or raw Python, use @flow and @checkpoint around your calls. Your model, your tools, your framework — Kitaru wraps them, not the other way around.

from kitaru import flow
from kitaru.adapters.pydantic_ai import KitaruAgent
from pydantic_ai import Agent

researcher = KitaruAgent(
    Agent("openai:gpt-5.4", system_prompt="You summarize research topics.")
)

@flow
def research_flow(topic: str) -> str:
    return researcher.run_sync(topic).output

🚀 Quick Start

Install

pip install kitaru

Or with uv (recommended):

uv pip install kitaru

To wrap a PydanticAI agent, install the adapter extra:

uv pip install "kitaru[pydantic-ai]"

Optional: start a local Kitaru server

Flows run locally by default with the base install. If you also want the local dashboard and REST API, install the local extra and then run bare kitaru login:

uv pip install "kitaru[local]"
kitaru login
kitaru status

Optional: connect to an existing remote Kitaru server

If you already have a deployed Kitaru server, connect to it explicitly:

kitaru login https://my-server.example.com
# add --project <PROJECT> or other remote-login flags if your setup requires them
kitaru status

Initialize your project

kitaru init

Write your first flow

# agent.py
from kitaru import checkpoint, flow

@checkpoint
def fetch_data(url: str) -> str:
    return "some data"

@checkpoint
def process_data(data: str) -> str:
    return data.upper()

@flow
def my_agent(url: str) -> str:
    data = fetch_data(url)
    return process_data(data)

result = my_agent.run("https://example.com").wait()
print(result)  # SOME DATA

Run it

python agent.py

Every checkpoint's output is persisted automatically. You can inspect what happened, replay from any checkpoint, or resume a waiting flow:

kitaru executions list
kitaru executions get <EXECUTION_ID>
kitaru executions logs <EXECUTION_ID>
kitaru executions replay <EXECUTION_ID> --from process_data

Deploy it

When the flow is ready, deploy it as a versioned snapshot and invoke it by name — no redeploy of whatever calls the agent.

# Freeze the current code + dependencies as a versioned snapshot.
# Parameterized flows take representative deployment-time inputs;
# consumers can override them at invocation time.
my_agent.deploy(url="https://example.com")

# Consumers invoke by name — from Python, CLI, MCP, or HTTP.
from kitaru import KitaruClient
KitaruClient().deployments.invoke(
    flow="my_agent",
    inputs={"url": "https://example.com"},
)
# Tag a version into a stage; re-tag to roll back.
kitaru flow tag my_agent latest --stage=prod
kitaru flow tag my_agent v2     --stage=prod   # rollback

📚 Learn more

Resource Description
Getting Started Guide Full setup walkthrough with all examples
Documentation Complete reference and guides
PydanticAI adapter Wrap a PydanticAI agent with KitaruAgent
Memory guide Durable memory concepts, scopes, history, and compaction
Examples Runnable workflows for every feature
Stacks Deploy to Kubernetes, AWS, GCP, or Azure

🌱 Origins

Kitaru is built by the team behind ZenML, drawing on five years of production orchestration experience (JetBrains, Adeo, Brevo). The orchestration primitives (stacks, artifacts, lineage) are purpose-rebuilt here for autonomous agents.

🤝 Contributing

We welcome contributions! See CONTRIBUTING.md for development setup, code style, and how to submit changes. The default branch is develop — all PRs should target it.

💬 Community and support

  • Discussions — ask questions, share ideas
  • Issues — report bugs, request features
  • Roadmap — see what's coming next
  • Docs — guides and reference

📄 License

Apache 2.0

Project details


Download files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

Source Distribution

kitaru-0.6.0.tar.gz (3.9 MB view details)

Uploaded Source

Built Distribution

If you're not sure about the file name format, learn more about wheel file names.

kitaru-0.6.0-py3-none-any.whl (3.0 MB view details)

Uploaded Python 3

File details

Details for the file kitaru-0.6.0.tar.gz.

File metadata

  • Download URL: kitaru-0.6.0.tar.gz
  • Upload date:
  • Size: 3.9 MB
  • Tags: Source
  • Uploaded using Trusted Publishing? Yes
  • Uploaded via: twine/6.1.0 CPython/3.13.13

File hashes

Hashes for kitaru-0.6.0.tar.gz
Algorithm Hash digest
SHA256 56f98e1daa2885b69d93d822eb3231fcb0a9ac7a8a02342ced9ac964697db0b5
MD5 5a870be8e5424f1c19cfb300422d3c10
BLAKE2b-256 e4fc8e0941712f0448411a8f0ba7e008e7e8e058420c56e8cd91bbc8b2eaa875

See more details on using hashes here.

Provenance

The following attestation bundles were made for kitaru-0.6.0.tar.gz:

Publisher: release.yml on zenml-io/kitaru

Attestations: Values shown here reflect the state when the release was signed and may no longer be current.

File details

Details for the file kitaru-0.6.0-py3-none-any.whl.

File metadata

  • Download URL: kitaru-0.6.0-py3-none-any.whl
  • Upload date:
  • Size: 3.0 MB
  • Tags: Python 3
  • Uploaded using Trusted Publishing? Yes
  • Uploaded via: twine/6.1.0 CPython/3.13.13

File hashes

Hashes for kitaru-0.6.0-py3-none-any.whl
Algorithm Hash digest
SHA256 a5904bf8f9e9ff9f04efeff009e6c463ecaf63150498ea19983d2328d7f5fb2d
MD5 e5cd5706d562d354d13c683eeb6ad9ed
BLAKE2b-256 063358df357d4c604f6ece878a4a1c037337527a4d0fec91c5e485395480c062

See more details on using hashes here.

Provenance

The following attestation bundles were made for kitaru-0.6.0-py3-none-any.whl:

Publisher: release.yml on zenml-io/kitaru

Attestations: Values shown here reflect the state when the release was signed and may no longer be current.

Supported by

AWS Cloud computing and Security Sponsor Datadog Monitoring Depot Continuous Integration Fastly CDN Google Download Analytics Pingdom Monitoring Sentry Error logging StatusPage Status page