Cordum
AI Agent Governance Platform
Deploy autonomous agents with built-in safety, observability, and control.
The Problem
AI agents are powerful. They're also unpredictable.
Teams deploying agents in production face the Trust Gap: the distance between what an agent can do and what you're confident letting it do unsupervised.
Without governance, you're flying blind:
- No visibility into what agents are doing
- No safety rails before dangerous actions
- No audit trail when things go wrong
- No way to require human approval for sensitive operations
The Solution
Cordum is a control plane for AI agents that closes the Trust Gap.
┌─────────────────────────────────────────────────────────────────┐
│ Cordum │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────────┐ │
│ │ API │──▶│ Scheduler│──▶│ Safety │──▶│ Worker Pools │ │
│ │ Gateway │ │ │ │ Kernel │ │ │ │
│ └──────────┘ └──────────┘ └──────────┘ └──────────────┘ │
│ │ │ │ │ │
│ ▼ ▼ ▼ ▼ │
│ [Dashboard] [Workflows] [Policies] [Your Agents] │
└─────────────────────────────────────────────────────────────────┘
What Cordum does:
- Safety Kernel — Policy checks (allow/deny/throttle/human-approve) before any job runs
- Workflow Engine — Orchestrate multi-step agent workflows with retries, approvals, and timeouts
- Job Routing — Distribute work across agent pools with capability-based routing
- Observability — Full audit trail, traces, and real-time dashboard
- Human-in-the-Loop — Require approval for sensitive operations
Quickstart
Prerequisites: Docker, Docker Compose
# Clone the repo git clone https://github.com/cordum-io/cordum.git cd cordum # Start everything docker compose up -d # Open dashboard open http://localhost:8082
Run the smoke test:
./tools/scripts/platform_smoke.sh
That's it. You have a running Cordum instance with API, scheduler, safety kernel, and dashboard.
How It Works
Cordum uses CAP (Cordum Agent Protocol) for all agent communication:
- Submit — Client submits a job via API
- Safety Check — Scheduler asks Safety Kernel: allow, deny, throttle, or require approval?
- Dispatch — Approved jobs route to the right worker pool via NATS
- Execute — Your agent runs the job (using MCP, LangChain, whatever)
- Result — Agent returns result; Cordum updates state and notifies client
Client ──▶ API ──▶ Scheduler ──▶ Safety Kernel ──▶ NATS ──▶ Agent Pool
│ │
▼ ▼
[Redis State] [Your Agents]
Key design choices:
- Payloads stay off the bus —
context_ptrandresult_ptrreference Redis/S3, keeping the message bus lean - Protocol-first — CAP is an independent spec; Cordum is the reference implementation
- Workers are external — Cordum is the control plane; your agents run wherever you want
Key Features
| Feature | Description |
|---|---|
| Safety Policies | Define rules for what agents can/can't do. Enforce before execution. |
| Human Approval | Flag sensitive jobs for manual review before they run. |
| Workflows | Multi-step DAGs with fan-out, retries, delays, and conditions. |
| Pool Routing | Route jobs by capability, region, or custom tags. |
| Heartbeats | Know which agents are alive, their capacity, and load. |
| Audit Trail | Every job, decision, and result logged and queryable. |
| Dashboard | Real-time UI for workflows, jobs, approvals, and policies. |
| Multi-tenant | API keys with RBAC for teams and environments. |
Architecture
cordum/
├── cmd/ # Service entrypoints + CLI
│ ├── cordum-api-gateway/ # API gateway (HTTP/WS + gRPC)
│ ├── cordum-scheduler/ # Scheduler + safety gating
│ ├── cordum-safety-kernel/ # Policy evaluation
│ ├── cordum-workflow-engine/ # Workflow orchestration
│ ├── cordum-context-engine/ # Optional context/memory service
│ └── cordumctl/ # CLI
├── core/ # Core libraries
│ ├── controlplane/ # Gateway, scheduler, safety kernel
│ ├── context/ # Context engine implementation
│ ├── infra/ # Config, storage, bus, metrics
│ ├── protocol/ # API protos + CAP aliases
│ └── workflow/ # Workflow engine
├── dashboard/ # React UI
├── sdk/ # SDK + worker runtime
├── cordum-helm/ # Helm chart
├── deploy/k8s/ # Kubernetes manifests
└── docs/ # Documentation
Documentation
| Doc | Description |
|---|---|
| System Overview | Architecture and data flow |
| Core Reference | Deep technical details |
| Docker Guide | Running with Compose |
| Agent Protocol | CAP bus + pointer semantics |
| Pack Format | How to package agent capabilities |
| Local E2E | Full local walkthrough |
Protocol: CAP
Cordum implements CAP (Cordum Agent Protocol) — an open protocol for distributed AI agent orchestration.
CAP vs MCP:
- MCP = tool-calling protocol for a single model
- CAP = job protocol for distributed agent clusters
They're complementary. Use CAP for orchestration, MCP inside your agents for tools.
Read more: MCP vs CAP: Why Your AI Agents Need Both Protocols
SDK
The Go SDK makes it easy to build CAP-compatible workers:
import ( "log" "github.com/cordum/cordum/sdk/runtime" ) type Input struct { Prompt string `json:"prompt"` } type Output struct { Summary string `json:"summary"` } func main() { agent := &runtime.Agent{Retries: 2} runtime.Register(agent, "job.summarize", func(ctx runtime.Context, input Input) (Output, error) { // Your agent logic here return Output{Summary: input.Prompt}, nil }) if err := agent.Start(); err != nil { log.Fatal(err) } select {} }
SDKs: Go (stable) | Python (coming soon) | Node (coming soon)
Community
- Discord: Join the conversation
- GitHub Discussions: Ask questions
- Twitter/X: @coraboratedai
- Email: admin@cordum.io
Enterprise
Cordum Enterprise adds:
- SSO/SAML integration
- Advanced RBAC
- SIEM export
- Priority support
Contact us for pricing.
Contributing
We welcome contributions! See CONTRIBUTING.md for guidelines.
License
Licensed under Business Source License 1.1 (BUSL-1.1).
Free for self-hosted and internal use. Not permitted for competing hosted/managed offerings. See LICENSE for details and Change Date.
Ready to govern your AI agents?
cordum.io · CAP Protocol · Discord
⭐ Star this repo if Cordum helps you deploy agents safely

