Skip to content
Documentation

The Cordum Agent Protocol (CAP)

CAP is the canonical protobuf contract in thecap repository. It defines the envelope, message types, job metadata, heartbeats, cancellations, safety requests, and SDK surface used by the Cordum control plane and external workers.

BusPacket envelope

Every CAP message is wrapped in a single protobuf envelope with tracing, sender identity, timestamps, protocol version, and a oneof payload.

proto/cordum/agent/v1/buspacket.proto
message BusPacket {
  string trace_id = 1;
  string sender_id = 2;
  google.protobuf.Timestamp created_at = 3;
  int32 protocol_version = 4;

  oneof payload {
    JobRequest job_request = 10;
    JobResult job_result = 11;
    Heartbeat heartbeat = 12;
    SystemAlert alert = 13;
    JobProgress job_progress = 15;
    JobCancel job_cancel = 16;
    Handshake handshake = 17;
  }

  bytes signature = 14;
}

Message types in the current proto

  • JobRequest
  • JobResult
  • Heartbeat
  • SystemAlert
  • JobProgress
  • JobCancel
  • Handshake

Job and result payloads

JobRequest

Includes job identifiers, topic, priority, context_ptr, workflow lineage, labels, structured metadata, and optional compensation details for rollback-aware workflows.

JobResult

Carries job_id, JobStatus, result_ptr, worker_id, execution_ms, error fields, structured ErrorCode, and artifact pointers emitted during execution.

Selected JobMetadata fields
- tenant_id / actor_id / actor_type
- idempotency_key
- capability
- risk_tags[]
- requires[]
- pack_id
- labels{}

Safety and lifecycle semantics

proto/cordum/agent/v1/safety.proto
service SafetyKernel {
  rpc Check(PolicyCheckRequest) returns (PolicyCheckResponse);
  rpc Evaluate(PolicyCheckRequest) returns (PolicyCheckResponse);
  rpc Explain(PolicyCheckRequest) returns (PolicyCheckResponse);
  rpc Simulate(PolicyCheckRequest) returns (PolicyCheckResponse);
  rpc ListSnapshots(ListSnapshotsRequest) returns (ListSnapshotsResponse);
}

enum DecisionType {
  DECISION_TYPE_ALLOW = 1;
  DECISION_TYPE_DENY = 2;
  DECISION_TYPE_REQUIRE_HUMAN = 3;
  DECISION_TYPE_THROTTLE = 4;
  DECISION_TYPE_ALLOW_WITH_CONSTRAINTS = 5;
}

Lifecycle notes

  • CAP job statuses include pending, scheduled, dispatched, running, succeeded, failed, cancelled, denied, and timeout.
  • FAILED_RETRYABLE andFAILED_FATAL are part of the JobStatus enum.
  • Heartbeats report worker load, pool, max_parallel_jobs, memory_load, progress_pct, and last_memo.
  • Handshakes let components advertise capabilities during connection setup.

SDK layout

The CAP repository currently includes SDK folders for multiple languages. Cordum itself imports the generated Go types and runtime helpers, while examples demonstrate integration patterns for other languages.

sdk/go
sdk/node
sdk/python
sdk/java
sdk/cpp
sdk/dotnet
sdk/php
sdk/ruby
sdk/rust

Frequently Asked Questions

What is CAP?
CAP is the canonical protobuf wire contract used by Cordum components and external workers. It standardizes envelopes, lifecycle messages, worker heartbeats, safety checks, and job metadata.
Does Cordum use CAP or local duplicate types?
Cordum uses CAP v2 types from the separate cap repository as the canonical bus and safety contract. The control-plane repo imports those generated types instead of maintaining local duplicates.
How is CAP related to MCP?
MCP is a tool-and-resource protocol for model sessions. CAP is the distributed job, worker, and safety protocol used across the Cordum control plane. They are complementary, not interchangeable.
What transports does CAP assume?
CAP is transport-agnostic at the protocol level. Cordum uses NATS subjects for the control plane, but the protobuf contract is not limited to a single transport implementation.