Agents are easy to build. Swarms are not.¶

Status — early-stage pre-release

Yutha is at v0.1.0-alpha.4 — solid enough to play with end-to-end, intentionally pre-1.0. This release adds the preview-rule-changes tools: shadow mode, replay, diff, and simulation. The shape of the project is settled; wire formats and API surfaces may shift before 1.0. Pin tightly if you build on it, and open an issue if you hit something.

Yutha — from the Sanskrit यूथ (yūtha) meaning a herd, troop, or band moving together — is open-source infrastructure for groups of AI agents. Two friends running hobby agents in a Discord, a marketing team coordinating a half-dozen agents inside one company, a regulated workflow with hundreds of agents across departments, or thousands of agents collaborating across organizations: same primitives, same audit log, same enforcement, same Yutha.

You can stand up a single agent in an afternoon. Coordinating a handful — or a hundred — of them, in a way you'd trust for a customer interaction, an internal workflow, or a cross-company integration, is a different problem entirely. Almost every team rebuilds the same scaffolding from scratch: who an agent is, what it's allowed to do, what it actually did, and which norms govern the swarm it lives in. Each agent framework solves a fragment and stops.

Yutha is that scaffolding, built once, framework-agnostic. It runs in front of agents you've already built — in LangGraph, CrewAI, OpenAI Agents, Microsoft Agent Framework, or anything else you'd like to write an adapter for — and gives them passports, signed receipts, attenuated capabilities, declarative constitutions with four-stage enforcement, and an optional cryptographic verification layer for when a third party needs to audit what happened.

flowchart TB
    Op(["Operator"])

    subgraph YA["Your agents · any framework"]
        direction LR
        A1["LangGraph agent"]
        A2["CrewAI agent"]
        A3["OpenAI Agents agent"]
        A4["MAF agent"]
        A5["Any other framework"]
    end

    Attest["Workload identity<br/>SPIFFE / OIDC"]

    SDK["Yutha SDK<br/>+ framework adapter"]

    subgraph CP["Yutha control plane · self-hosted"]
        direction LR
        Reg["Agent registry<br/>and topology<br/>(passports)"]
        Cap["Capability store"]
        Const["Cedar+ constitution<br/>+ four-stage enforcement"]
        Rec["Append-only<br/>receipt log"]
    end

    KMS["KMS key custody<br/>Vault / GCP KMS / Azure HSM"]
    Audit["Audit and monitoring"]
    Sui["Sui anchoring<br/>(verifiable to third parties)"]

    YA --> SDK
    YA -.->|"opt-in"| Attest
    Attest -.->|"opt-in"| Reg
    SDK <-->|gRPC| CP
    Op -->|"constitution, capabilities, topology"| CP
    Reg -.->|"opt-in"| KMS
    Rec --> Audit
    Rec -.->|"opt-in"| Sui

How it fits together: your agents talk to the self-hosted control plane through the Yutha SDK. The control plane gates every consequential action against capabilities and the active constitution, and writes a signed receipt for each one. Audit and monitoring follow from the receipt log. Three opt-in layers extend the substrate further: workload identity (agents fetch a SPIFFE SVID or OIDC ID-token from your existing identity system, the control plane verifies it at admission); KMS key custody (the control plane signs receipts and passports through Vault, GCP KMS, or Azure Managed HSM instead of in-process keys); and Sui anchoring for when a third party needs to verify the trail without trusting the operator.

Run an agent through it in 15 minutes

Bring an existing LangGraph, CrewAI, OpenAI Agents, or Microsoft Agent Framework agent. Wrap it with the Python SDK. Join an existing swarm. Get a passport, a capability, and a signed audit trail.

Developer quickstart
Stand up your own swarm in 30 minutes

A control plane, a constitution, and a topology of your choosing — closed, open, or hybrid — on infrastructure you own.

Operator quickstart

The problem Yutha solves¶

A multi-agent system makes a lot of small decisions every minute. Each one is consequential in the way that database writes are consequential — it touches a customer, spends a budget, ends a session, escalates to a human. When something goes wrong:

You can't tell which agent did it. Identity is implicit or per-framework.
You can't prove what was authorized. Capability checks live in code, not as artifacts.
You can't reconstruct what happened. Logs are best-effort, mutable, often missing the why.
You can't enforce norms uniformly. Each framework's "guardrails" are written differently and trust each other transitively.
You can't prove any of the above to a third party. Internal logs don't survive an audit.

These are not framework problems. They're substrate problems. They show up no matter which framework you build the agents in, and trying to solve them inside the framework leaks them across systems the moment you compose two different frameworks together. Yutha is the layer underneath the frameworks, so the substrate looks the same regardless of how the agents above were built.

What Yutha gives you¶

Identity that's portable. Every agent carries an Ed25519-backed passport: a verifiable identity that doesn't depend on which framework or runtime built the agent. Passports are issued by an operator, revocable, and traceable.

Typed messaging with audit. Agents talk through envelopes — structured messages with a sender, a recipient (or role, or swarm-wide broadcast), a typed action, and a payload. Every consequential send produces an append-only receipt: signed, content-addressed, deterministic. Receipts are the source of truth.

Capabilities, not permissions. Authority is granted as bounded, attenuable capabilities — first-class tokens that say who may do what for how long on which targets. Capabilities can be narrowed (never widened) when delegated, revoked atomically, and cascaded across delegation chains. Cap checks happen at the control plane, not in each agent's code.

Constitutions, declaratively. The rules governing a swarm are written in a small policy language called Cedar+ (a superset of AWS's Cedar that adds soft scoring and procedural state machines). The control plane evaluates every consequential action against the active rule set. Violations progress through a four-stage response — detect, coach, quarantine, evict — never as a single all-or-nothing decision.

Preview rule changes before promoting them. Four built-in preview tools let you check what a candidate rule change will do before turning it on: shadow mode (evaluate the candidate alongside the active rule set on live traffic), replay (run the candidate against a past time window), diff (structural comparison of two rule sets, with an optional behaviour delta), and simulation (synthetic adversarial traffic you script).

Optional cryptographic verification. When the operator needs to prove the audit trail to a third party — a regulator, a customer, a downstream system — Yutha can publish receipt batches to a public blockchain (Sui today) in a way that lets anyone independently verify the trail wasn't tampered with. The operator doesn't have to be trusted; the math is the audit.

Pluggable backends. Receipt storage in Postgres for production or in-memory for development, optional anchoring on Sui, optional enterprise identity (HashiCorp Vault / GCP KMS / Azure Managed HSM for key custody; SPIFFE/SPIRE or OIDC for workload attestation) — same APIs, swap the implementation behind the spec.

Who it's for¶

Operators

Stand up the control plane, set the topology (closed / open / hybrid), author and activate constitutions, manage operator credentials, monitor receipts, anchor for verifiability. You own the swarm.

Operator guide
Developers

Build agents in the framework you already like — LangGraph, CrewAI, OpenAI Agents, Microsoft Agent Framework, or anything else with a Python toolchain — and bring them to a Yutha-governed swarm. Adapters handle the passport, the cap-checking, the receipt emission.

Developer guide

What people build with it¶

Each card below maps to a walkthrough under Examples. All six are runnable end-to-end demos you can stand up against a local control plane in an afternoon.

Customer support swarms

Router + specialists + supervisor escalation. Per-agent identity, capability-gated dispatch, live cap-revoke, and operator-driven eviction — the substrate primitives the other examples layer policy on top of. The audit log shows exactly which agent did what.

Walkthrough
Code review crews

Reviewer + auto-fix agents on every PR. Constitution forbids patch_applied + security_sensitive envelopes; two bypass attempts walk the four-stage enforcement loop end-to-end (detect → coach → quarantine → evict). Every change leaves a signed receipt.

Walkthrough
AP & invoice processing

Classifier, auto-approver, supervisor, treasury. Constitution caps single payments and gates over-cap authorizations on a supervisor_approved tag; the approver's bypass attempts trip the same enforcement chain. SOX-grade audit trail by default.

Walkthrough
Research crew with citation enforcement

Researcher, fact-checker, editor connected by OpenAI Agents' handoff primitive. Constitution forbids claim_published envelopes that lack verified_citations; every handoff produces a Yutha audit envelope so the full collaboration chain is reconstructable from the receipt log.

Walkthrough
DevOps incident-response with SRE countersign

Incident commander, diagnoser, schema specialist, SRE, remediation executor — a Microsoft Agent Framework swarm walking a runbook. Constitution forbids production schema_change actions unless an sre_countersigned tag is present; bypass attempts trip the four-stage enforcement chain.

Walkthrough
Procurement platform with vendor isolation

Buyer-side LangGraph intake + three CrewAI vendor agents on one swarm. Bounded capabilities pin each vendor to the RFPs it was invited to; the constitution forbids cross-vendor data leakage; a bad-acting vendor walks the four-stage enforcement loop. The first runnable demo of a heterogeneous-framework swarm — and a clean upgrade path to cross-organisation federation when that work lands.

Walkthrough

What Yutha is not¶

Yutha is intentionally not a lot of things. Drawing the boundary explicitly is part of how it stays focused.

Not a platform for building or hosting agents. You build the agents in your framework of choice. Yutha never owns the agent's reasoning loop, prompt, or model. It governs how agents interact, not what they think.

Not a model service. No model hosting, no inference layer, no opinion on which LLM you use. Bring your own.

Not a chat product or assistant. Yutha is infrastructure. Humans interact with the swarm through whatever UI the operator builds on top.

Not a managed service. There's no Yutha cloud to sign up for and no service to pay a subscription to. The reference implementation runs on infrastructure you already operate — Postgres, object storage, the cloud (or laptop) of your choice. The optional verifiability backend is opt-in and self-hosted.

Not framework-opinionated. LangGraph, CrewAI, OpenAI Agents, and Microsoft Agent Framework adapters ship today. Anyone can write an adapter for a new framework against the spec; no permission required. Adapters in other languages (TypeScript, Go) are welcomed when the demand shows up.

Not a reputation engine. Yutha tracks a reputation scalar per agent, but it is never the sole basis for a permission decision. Reputation informs; capabilities and the constitution decide.

Where the project is¶

Yutha is open-source, Apache 2.0, stewarded by a single maintainer right now. The reference implementation runs end-to-end across the Rust control plane and Python SDK; four framework adapters (LangGraph, CrewAI, OpenAI Agents, Microsoft Agent Framework) are functional with a runnable end-to-end example each; the conformance suite covers the receipt log, send-path enforcement, operator revocation, constitution evaluation, the four-stage enforcement loop, and the verifiability anchor.

A handful of directions have been thought through but aren't built yet — cross-swarm federation primitives, an OpenTelemetry exporter for receipts, adapters in non-Python languages. They live as design notes in the RFC archive. Whether and when they ship depends on what the community ends up needing. The GitHub repo is the place to follow along or propose something.