Introducing Chimera: a multi-agent orchestration framework for regulated industries

Background

Chimera was built over 24 hours at a hackathon focused on AI agent frameworks. The core challenge: most multi-agent systems require tight coupling between orchestrator and agent. Any protocol change requires coordinated updates across the entire fleet.

We’d run into this failure mode before: a financial services client had a pipeline that required three teams to coordinate deploys whenever the routing logic changed. The fleet was effectively frozen, and the hackathon gave us a forcing function to try something different.

What we built

Chimera inverts the standard model. The orchestrator exposes a capability registry, agents advertise what they can do, and routing happens based on declared capabilities rather than hard-coded agent types. Agents stay fully autonomous, and the fleet is hot-pluggable.

Capability manifest

Each agent ships a manifest: a small JSON document declaring what it can do, what inputs it accepts, and what guarantees it provides. The orchestrator reads manifests at registration time and updates its routing table. No code changes on either side.

Task delegation envelope

Every task travels inside a typed envelope: intent, payload, provenance, and constraints. The orchestrator stamps the envelope before forwarding. Agents read the constraints (things like “must complete in under 200ms” or “output must be auditable”) and either accept or reject the task. No guessing, no implicit contracts.

{
"id": "text-extraction-agent-v2",
"version": "2.1.0",
"capabilities": [
  {
    "name": "extract_entities",
    "description": "Extract named entities from unstructured text",
    "input":  { "type": "text", "max_length": 100000 },
    "output": { "type": "entity_list", "schema": "chimera/entity/v1" }
  },
  {
    "name": "classify_document",
    "description": "Classify document into a predefined taxonomy",
    "input":  { "type": "text", "max_length": 50000 },
    "output": { "type": "classification", "schema": "chimera/label/v1" }
  }
],
"constraints": {
  "max_latency_ms": 800,
  "throughput_rps": 40,
  "compliance": ["gdpr", "hipaa"],
  "auditable": true
}
}

A minimal capability manifest: the only document an agent needs to ship to join the registry.

Before and after

The protocol surface

The core of Chimera is deliberately minimal: a capability manifest format, a registration handshake, and a task delegation envelope. Everything else is implementation detail, left to the agent.

What we’d do differently

The hackathon constraint was a gift: 24 hours forced us to throw out everything that wasn’t essential. The manifest stayed small. The envelope stayed typed. The registration handshake stayed stateless.

What we’d change: the current manifest schema has no versioning primitive. That’s fine at hackathon scale. It becomes a problem the moment two agents on different manifest versions need to coexist in the same registry.

Version negotiation

The orchestrator needs a version field on the manifest and a negotiation step during registration: if the agent ships manifest v2 but the orchestrator only understands v1, they should be able to agree on a common subset rather than failing hard.

Constraint inheritance

Today, constraints in the envelope are set by the originating caller. In multi-hop chains, those constraints need to be inherited and tightened, not replaced. We have a working sketch of a merge algorithm; it just didn’t make the 24-hour cut.