TPS-0.1 Protocol Specification

TPS-0.1 — Organizational Infrastructure for Agentic AI

Status: Draft
Version: 0.1
Date: March 2026
License: Apache 2.0
Authors: Tervos Protocol Contributors
URI: https://tervos.ai/spec/v0.1

Abstract

This document specifies the Tervos Protocol, an open protocol for the organizational layer of agentic AI. Tervos defines how autonomous AI agents form organizations, establish identity and trust, enforce governance policies, communicate state changes, and operate within bounded organizational structures. It sits above agent communication protocols (MCP, A2A) and below application-level agent frameworks, providing the missing infrastructure layer for agent-driven organizations.

This specification covers Layers 1 through 4 of the 8-layer Tervos Protocol Stack: Identity and Trust, Policy and Authorization, Communication and State, and Organization and Boundaries. Layers 5-8 (Economics, Knowledge, Observability, Resilience) will be specified in TPS-1.0.

Introduction
Terminology
Protocol Overview
Layer 1: Identity and Trust
Layer 2: Policy and Authorization
Layer 3: Communication and State
Layer 4: Organization and Boundaries
TERVOS.yaml Manifest Format
Conformance Requirements
Security Considerations
IANA Considerations
References
Appendix A: State Machine Diagrams
Appendix B: Worked Examples
Appendix C: TERVOS.yaml Full Schema Reference

1. Introduction

1.1 Problem Statement

The agentic AI ecosystem has converged on protocols for agent-to-tool communication (Model Context Protocol / MCP) and agent-to-agent communication (Agent-to-Agent / A2A). These protocols solve how agents talk to external systems and to each other. They do not address how agents form organizations, govern collective behavior, manage shared state, enforce budgets and policies, or comply with regulatory requirements.

As organizations deploy multi-agent systems beyond isolated task execution — teams of agents that collaborate on projects, manage budgets, make hiring decisions, and transact with external entities — the absence of organizational infrastructure becomes the binding constraint. Each organization reinvents identity management, policy enforcement, state coordination, and governance from scratch, producing incompatible, un-auditable, and fragile implementations.

Tervos Protocol fills this gap. It specifies the organizational layer: a set of protocol primitives that any agent framework, any runtime, and any LLM provider can implement to create interoperable, governable, auditable autonomous organizations.

1.2 Design Goals

The protocol is designed around six principles:

Interoperability. Two independent implementations of Tervos Protocol MUST be able to form, govern, and operate organizations that interact with each other. The specification is precise enough to eliminate ambiguity in wire formats, state transitions, and error handling.

Framework Agnosticism. Tervos does not require any specific agent framework, LLM provider, or runtime. An organization MAY contain agents built with LangGraph, CrewAI, AutoGen, bare API calls, or any other approach. The protocol cares about behavior at organizational boundaries, not internal agent implementation.

Transport Agnosticism. Tervos defines abstract message formats and state transitions. Implementations MAY use HTTP, WebSocket, gRPC, NATS, MQTT, or any transport that provides the delivery guarantees specified per message type.

Progressive Autonomy. Autonomy is not binary. Tervos defines a maturity model where agents begin under human supervision and earn autonomy through policy grants. Every autonomous action is traceable to a policy that authorized it and a human who granted the policy.

Crypto Agility. The protocol MUST NOT hardcode cryptographic algorithms. All cryptographic operations use algorithm negotiation, and the specification mandates a migration path to post-quantum cryptography (PQC).

Auditability by Default. Every state change in a Tervos organization is an immutable event. The event log provides a complete, replayable history of every decision, action, delegation, and transaction — sufficient for regulatory compliance, debugging, and forensic analysis.

1.3 Scope

This specification defines:

The identity model for agents, organizations, and human participants
The policy language and enforcement model for governance
The event-sourced state management system for organizational state
The organizational structure primitives (teams, roles, boundaries, lifecycles)
The TERVOS.yaml manifest format for declarative organization definition
Conformance requirements for implementations

This specification does NOT define:

Agent internal reasoning or prompt engineering
LLM API interfaces or model selection
Application-level business logic
User interface requirements
Specific deployment infrastructure

1.4 Relationship to Other Protocols

Protocol	Layer	Relationship
MCP (Model Context Protocol)	Agent ↔ Tool	Tervos agents MAY use MCP to interact with tools. Tervos policies govern which MCP tools an agent is authorized to invoke.
A2A (Agent-to-Agent)	Agent ↔ Agent	Tervos agents MAY use A2A for inter-agent messaging. Tervos adds organizational context (roles, permissions, budgets) to A2A exchanges.
COMPANY.md (Agent Companies)	Org Description	Tervos extends the declarative organization description concept. TERVOS.yaml is a superset of COMPANY.md semantics with formal schema validation, identity binding, and policy integration. Import/export compatibility is a conformance requirement.
x402 / AP2	Payments	Tervos Layer 5 (future) uses x402 for HTTP-native agent payments. Layer 2 policies govern payment authorization.
OpenTelemetry	Observability	Tervos Layer 7 (future) emits telemetry using OpenTelemetry with gen_ai.* semantic conventions.

1.5 Notational Conventions

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.

All message formats are specified in TypeScript type notation for precision. Implementations in other languages MUST produce equivalent wire formats. JSON Schema definitions are provided in Appendix C for implementations that prefer schema-based validation.

2. Terminology

Agent. A software entity that can perceive its environment, reason about goals, and take actions. In Tervos, an agent is any entity that holds a valid Tervos Identity and is bound to an Organization. Agents MAY be backed by LLMs, rule-based systems, human proxies, or any other decision-making mechanism.

Organization. A bounded collective of agents operating under shared governance, defined by a TERVOS.yaml manifest. An organization has a lifecycle, a policy set, a shared event log, and optionally a treasury.

Cell. The unit of blast-radius containment. A cell is a subdivision of an organization with its own failure boundary. An error in one cell MUST NOT propagate to other cells without crossing an explicit boundary interface.

Team. A named group of agents within an organization, typically aligned to a functional area (engineering, research, operations). Teams are organizational groupings; cells are reliability boundaries. They MAY overlap but serve different purposes.

Principal. Any entity that can be authenticated and authorized: an agent, a human participant, or an external service. Principals are identified by DIDs.

Delegation. The act of a principal granting a subset of their authority to another principal. Delegations are cryptographically signed, time-bounded, and revocable. A principal MUST NOT delegate more authority than they possess (attenuation principle).

Event. An immutable record of a state change within an organization. Events are the fundamental unit of state in Tervos. All organizational state is derived by replaying events from the event log.

Policy. A declarative rule that governs what actions a principal may perform. Policies are evaluated by the policy engine before every action. An action without an authorizing policy is denied by default.

Manifest. A TERVOS.yaml file that declaratively defines an organization’s structure, agents, teams, policies, and configuration. The manifest is the source of truth for organizational design.

Progressive Autonomy. The governance model where agents begin with minimal autonomous authority (supervised) and earn greater autonomy through explicit policy grants, based on demonstrated competence and trust.

Autonomy Level. One of four defined levels: supervised, semi-autonomous, autonomous, fully-autonomous. Each level specifies default capabilities, approval requirements, and human oversight thresholds.

3. Protocol Overview

3.1 Layer Architecture

Tervos Protocol is organized as an 8-layer stack. Each layer provides specific capabilities and depends only on layers below it. A conforming implementation of Layer N MUST also implement Layers 1 through N-1.

┌─────────────────────────────────────────────┐
│  Layer 8: Resilience and Adaptation         │  TPS-1.0
│  Layer 7: Observability and Governance      │  TPS-1.0
│  Layer 6: Knowledge and Context             │  TPS-1.0
│  Layer 5: Economic Transactions             │  TPS-1.0
├─────────────────────────────────────────────┤
│  Layer 4: Organization and Boundaries       │  TPS-0.1 ←
│  Layer 3: Communication and State           │  TPS-0.1 ←
│  Layer 2: Policy and Authorization          │  TPS-0.1 ←
│  Layer 1: Identity and Trust                │  TPS-0.1 ←
└─────────────────────────────────────────────┘

Dependency Rule. Layer N MAY import from any Layer M where M < N. Layer N MUST NOT import from any Layer M where M > N. Cross-cutting concerns (logging, metrics, tracing) are handled by a shared observability interface that does not create upward dependencies.

3.2 Message Envelope

All Tervos protocol messages share a common envelope format. The envelope provides identity, routing, and integrity verification regardless of the message payload.

interface TervosEnvelope<T = unknown> {
  /** Protocol version. Format: "tervos/v{major}.{minor}" */
  protocol: string;

  /** Unique message identifier. Format: UUIDv7 for temporal ordering. */
  id: string;

  /** Message type. Dot-delimited namespace: "{layer}.{domain}.{action}" */
  type: string;

  /** DID of the message originator. */
  from: string;

  /** DID of the intended recipient. Null for broadcast events. */
  to: string | null;

  /** DID of the organization context. */
  org: string;

  /** ISO 8601 timestamp with millisecond precision. MUST be UTC. */
  timestamp: string;

  /** Correlation ID for request-response pairs and saga tracking. */
  correlationId: string | null;

  /** Causation ID: the message ID that caused this message. */
  causationId: string | null;

  /** UCAN authorization token for this message. */
  authorization: string;

  /** Message payload. Schema determined by `type` field. */
  payload: T;

  /** JWS signature over the canonical JSON encoding of this envelope. */
  signature: string;
}

Field Constraints:

protocol: MUST match pattern tervos/v[0-9]+\.[0-9]+. Current version: tervos/v0.1.
id: MUST be a valid UUIDv7 (RFC 9562). Implementations MUST use UUIDv7 for temporal ordering of messages.
type: MUST match pattern [a-z]+\.[a-z_]+\.[a-z_]+. Examples: identity.agent.register, policy.evaluation.request, org.task.assigned.
from: MUST be a valid DID (W3C DID Core v1.0).
timestamp: MUST be UTC. Format: YYYY-MM-DDTHH:mm:ss.SSSZ.
authorization: MUST be a valid UCAN token (see Section 4.3).
signature: MUST be a detached JWS (RFC 7515) over the canonical JSON serialization of the envelope with signature field omitted.

Canonical JSON Serialization. For signature computation, the envelope is serialized to JSON with these rules: (1) keys sorted lexicographically, (2) no whitespace, (3) signature field omitted, (4) Unicode characters escaped as \uXXXX. Implementations MUST produce identical byte sequences for identical envelopes.

3.3 Transport Requirements

Tervos Protocol is transport-agnostic. Implementations MAY use any transport that satisfies these requirements per message category:

Category	Delivery Guarantee	Ordering	Examples
Commands	At-least-once	Per-sender FIFO	`..request`, `..command`
Events	At-least-once	Global causal (per org)	`..created`, `..updated`, `..completed`
Queries	At-most-once	None	`..query`, `..status`

At-least-once means the transport MUST retry delivery until acknowledged. Receivers MUST be idempotent: processing the same message ID twice MUST produce no additional side effects.

Global causal ordering means that within an organization, if event A causally precedes event B (B’s causationId references A), then every participant MUST observe A before B.

4. Layer 1: Identity and Trust

4.1 Overview

Layer 1 establishes the identity foundation for all principals in a Tervos organization. Every agent, human participant, organization, and external service is identified by a Decentralized Identifier (DID). Identity is self-sovereign: principals generate their own identifiers and control their own cryptographic keys.

4.2 Identifier Format

Tervos supports two DID methods:

did:key — Development and Ephemeral Identities

Used for local development, testing, and ephemeral agents. A did:key identifier encodes the public key directly in the DID string, requiring no external resolution infrastructure.

did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK

Generation:

Generate an Ed25519 keypair (or ML-DSA-65 for PQC, see Section 4.8).
Encode the public key using Multicodec (0xed for Ed25519).
Apply Multibase encoding (base58btc, prefix z).
Construct: did:key: + multibase-encoded multicodec public key.

did:web — Production Identities

Used for production deployments where identity persistence, key rotation, and organizational association matter. A did:web identifier resolves to a DID Document hosted at a well-known HTTPS URL.

did:web:tervos.ai:orgs:acme-corp:agents:ceo

Resolution: Replace : with /, prepend https://, append /.well-known/did.json:

https://tervos.ai/orgs/acme-corp/agents/ceo/.well-known/did.json

Implementations MUST support both did:key and did:web. Implementations MAY support additional DID methods. The DID method used MUST be transparent to all higher layers — Layer 2 and above MUST NOT make decisions based on DID method.

4.3 DID Documents

Every principal’s DID resolves to a DID Document conforming to W3C DID Core v1.0. Tervos extends the base DID Document with organization-specific metadata.

interface TervosDIDDocument {
  /** The DID this document describes. */
  id: string;

  /** DID Document context. MUST include Tervos context URI. */
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://tervos.ai/ns/v1"
  ];

  /** Verification methods (public keys) for this principal. */
  verificationMethod: VerificationMethod[];

  /** Key references used for authentication (proving identity). */
  authentication: string[];

  /** Key references used for assertion (signing claims). */
  assertionMethod: string[];

  /** Key references used for capability delegation (UCAN issuance). */
  capabilityDelegation: string[];

  /** Key references used for capability invocation (UCAN usage). */
  capabilityInvocation: string[];

  /** Service endpoints for this principal. */
  service: ServiceEndpoint[];

  /** Tervos-specific metadata. */
  tervos: TervosIdentityMetadata;
}

interface VerificationMethod {
  id: string;
  type: "Ed25519VerificationKey2020" | "JsonWebKey2020" | "Multikey";
  controller: string;
  publicKeyMultibase?: string;
  publicKeyJwk?: JsonWebKey;
}

interface ServiceEndpoint {
  id: string;
  type: string;
  serviceEndpoint: string | string[];
}

interface TervosIdentityMetadata {
  /** Principal type. */
  principalType: "agent" | "human" | "organization" | "service";

  /** Organization DID this principal belongs to. Null for organizations themselves. */
  organizationDid: string | null;

  /** Role within the organization, as defined in TERVOS.yaml. */
  role: string | null;

  /** Agent autonomy level. Null for non-agent principals. */
  autonomyLevel: "supervised" | "semi-autonomous" | "autonomous" | "fully-autonomous" | null;

  /** Timestamp when this identity was created. */
  createdAt: string;

  /** Timestamp when this identity was last rotated/updated. */
  updatedAt: string;

  /** Human-readable display name. */
  displayName: string;

  /** Agent capabilities (skills this agent can perform). */
  capabilities: string[];
}

4.4 UCAN Authorization

Tervos uses UCANs (User-Controlled Authorization Networks) for capability-based authorization. UCANs are self-contained, cryptographically signed tokens that encode what a principal is authorized to do. They chain naturally: a principal can delegate a subset of their capabilities to another principal by issuing a new UCAN that attenuates the original.

UCAN Structure:

interface TervosUCAN {
  header: {
    /** Algorithm. MUST be "EdDSA" (Ed25519) or "ML-DSA-65" (PQC). */
    alg: string;
    /** Token type. MUST be "JWT". */
    typ: "JWT";
    /** UCAN version. MUST be "0.10.0". */
    ucv: "0.10.0";
  };

  payload: {
    /** Issuer DID (the principal granting the capability). */
    iss: string;
    /** Audience DID (the principal receiving the capability). */
    aud: string;
    /** Not-before timestamp (seconds since epoch). */
    nbf: number;
    /** Expiration timestamp (seconds since epoch). */
    exp: number;
    /** Nonce for replay protection. UUIDv7. */
    nnc: string;
    /** Attenuated capabilities being granted. */
    att: TervosCapability[];
    /** Proof chain: UCANs that authorize the issuer to grant these capabilities. */
    prf: string[];
    /** Facts: additional non-capability data attached to the token. */
    fct: Record<string, unknown>[];
  };

  /** Signature over header.payload using issuer's key. */
  signature: string;
}

interface TervosCapability {
  /** Resource URI. Format: "tervos:{org_did}:{resource_type}/{resource_id}" */
  with: string;
  /** Action permitted on the resource. */
  can: string;
  /** Additional constraints on the capability (policy conditions). */
  nb: Record<string, unknown>;
}

Capability Resource URIs:

tervos:{org_did}:agent/{agent_id}         — An agent within an organization
tervos:{org_did}:team/{team_id}           — A team
tervos:{org_did}:task/{task_id}           — A task
tervos:{org_did}:budget/{budget_id}       — A budget allocation
tervos:{org_did}:policy/{policy_id}       — A policy definition
tervos:{org_did}:event/{event_type}       — Event emission permission
tervos:{org_did}:tool/{tool_id}           — MCP tool invocation permission
tervos:{org_did}:*                        — All resources (root capability)

Capability Actions:

tervos/create    — Create a new resource
tervos/read      — Read resource state
tervos/update    — Modify a resource
tervos/delete    — Remove a resource
tervos/delegate  — Delegate capability to another principal
tervos/execute   — Execute a task or invoke a tool
tervos/approve   — Approve a pending action
tervos/audit     — Read audit logs for a resource
tervos/*         — All actions (root capability)

Attenuation Principle. When a principal issues a UCAN, the capabilities in the new token MUST be a subset of the capabilities in the proof chain. Specifically:

Every capability in att MUST be authorized by at least one capability in a UCAN referenced by prf.
The with resource in the new capability MUST be equal to or more specific than the proof capability’s resource.
The can action MUST be equal to or more restrictive than the proof capability’s action.
The nb constraints MUST be equal to or more restrictive than the proof capability’s constraints.

Implementations MUST verify the full proof chain before accepting a UCAN. A broken chain (missing proof, expired parent, revoked parent) MUST result in authorization failure.

4.5 Agent Lifecycle

Every agent in a Tervos organization follows a defined lifecycle. State transitions are recorded as events in the organization’s event log.

                    ┌──────────┐
          register  │          │  activate
     ───────────────► PENDING  ├──────────────┐
                    │          │               │
                    └────┬─────┘               ▼
                         │              ┌──────────┐
                   deny  │              │          │
                         │    ┌─────────►  ACTIVE  ◄──────────┐
                         │    │         │          │           │
                         ▼    │         └──┬───┬───┘           │
                    ┌─────────┴┐           │   │         ┌─────┴──────┐
                    │          │  resume    │   │ suspend │            │
                    │ REJECTED │◄──────────┘   └────────►│ SUSPENDED  │
                    │          │                         │            │
                    └──────────┘                         └────────────┘
                         ▲              ┌──────────┐
                         │  terminate   │          │
                         └──────────────┤ ACTIVE   │
                                        │          │
                                        └─────┬────┘
                                              │ terminate
                                              ▼
                                        ┌──────────┐
                                        │TERMINATED│
                                        └──────────┘

States:

State	Description	Allowed Transitions
`PENDING`	Agent registered but not yet activated. Awaiting approval if governance requires it.	→ `ACTIVE`, → `REJECTED`
`ACTIVE`	Agent is operational and may perform actions within its policy scope.	→ `SUSPENDED`, → `TERMINATED`
`SUSPENDED`	Agent is temporarily disabled. State is preserved but no actions are permitted.	→ `ACTIVE`, → `TERMINATED`
`REJECTED`	Agent registration was denied by governance. Terminal state unless re-registered.	(terminal)
`TERMINATED`	Agent has been permanently deactivated. All delegated UCANs are revoked.	(terminal)

Lifecycle Events:

// Agent Registration
interface AgentRegisteredEvent {
  type: "identity.agent.registered";
  payload: {
    agentDid: string;
    organizationDid: string;
    role: string;
    requestedAutonomyLevel: AutonomyLevel;
    capabilities: string[];
    registeredBy: string; // DID of the registering principal
  };
}

// Agent Activation
interface AgentActivatedEvent {
  type: "identity.agent.activated";
  payload: {
    agentDid: string;
    grantedAutonomyLevel: AutonomyLevel;
    initialUcan: string; // Base UCAN for this agent
    activatedBy: string;
  };
}

// Agent Suspension
interface AgentSuspendedEvent {
  type: "identity.agent.suspended";
  payload: {
    agentDid: string;
    reason: string;
    suspendedBy: string;
    resumable: boolean;
  };
}

// Agent Termination
interface AgentTerminatedEvent {
  type: "identity.agent.terminated";
  payload: {
    agentDid: string;
    reason: string;
    terminatedBy: string;
    revokedUcans: string[]; // All UCAN token IDs revoked
  };
}

4.6 Key Rotation

Principals MUST be able to rotate their cryptographic keys without changing their DID. Key rotation is performed by updating the DID Document to add a new verification method and deprecate the old one.

Rotation Protocol:

Principal generates a new keypair.
Principal signs a KeyRotationEvent with the OLD key, including the new public key.
Principal updates their DID Document to include both keys (old marked as deprecated).
After a grace period (RECOMMENDED: 24 hours), the old key is removed from the DID Document.
All UCANs issued with the old key remain valid until their expiration or explicit revocation.

interface KeyRotationEvent {
  type: "identity.key.rotated";
  payload: {
    principalDid: string;
    previousKeyId: string;
    newKeyId: string;
    newPublicKeyMultibase: string;
    gracePeriodSeconds: number;
    rotatedAt: string;
  };
}

4.7 UCAN Revocation

UCANs are bearer tokens and cannot be “un-sent.” Revocation is achieved through a revocation list maintained by the organization.

Revocation Protocol:

The issuer of a UCAN publishes a UcanRevokedEvent to the organization’s event log.
All principals MUST check the revocation list before accepting a UCAN.
Revocation is transitive: revoking a UCAN also invalidates all UCANs that chain through it (where the revoked UCAN appears in prf).

interface UcanRevokedEvent {
  type: "identity.ucan.revoked";
  payload: {
    tokenCid: string; // Content-addressed ID of the revoked UCAN
    revokedBy: string;
    reason: string;
    transitive: boolean; // If true, all downstream delegations are also revoked
  };
}

Implementations MUST maintain a revocation cache with a maximum staleness of 60 seconds for supervised and semi-autonomous agents, and 5 seconds for autonomous and fully-autonomous agents.

4.8 Cryptographic Agility

Tervos is designed for the post-quantum transition. All cryptographic operations use algorithm negotiation.

Supported Algorithms (v0.1):

Purpose	Classical	Post-Quantum	Hybrid
Signatures	Ed25519	ML-DSA-65 (FIPS 204)	Ed25519 + ML-DSA-65
Key Agreement	X25519	ML-KEM-768 (FIPS 203)	X25519 + ML-KEM-768
Hashing	SHA-256, SHA-3-256	—	—

Algorithm Negotiation. When two principals establish a session, they exchange supported algorithm lists. The selected algorithm is the strongest mutually supported option, with preference for hybrid modes.

Migration Mandate. Implementations MUST support Ed25519 in v0.1. Implementations SHOULD support hybrid Ed25519 + ML-DSA-65 by v1.0. Implementations MUST support ML-DSA-65 standalone by v2.0 (projected 2028).

5. Layer 2: Policy and Authorization

5.1 Overview

Layer 2 provides the governance enforcement layer. Every action in a Tervos organization — every task delegation, tool invocation, budget expenditure, and state change — passes through the policy engine before execution. There are no bypass mechanisms, no admin shortcuts, and no implicit permissions.

The policy model is default-deny: an action is forbidden unless an explicit policy permits it.

5.2 Policy Engine

Tervos specifies Cedar (developed by Amazon, used in AWS Verified Permissions and Bedrock AgentCore) as the REQUIRED policy language for conforming implementations. Cedar provides:

Formal verification of policy properties
Sub-millisecond evaluation latency
Attribute-based access control (ABAC) with entity hierarchies
A well-defined specification with reference implementations in Rust and TypeScript

Implementations MAY additionally support OPA/Rego as an alternative policy engine, but MUST support Cedar as the baseline.

5.3 Policy Structure

A Tervos policy is a Cedar policy with Tervos-specific entity types and actions.

Entity Types:

// Principals
entity Agent in [Team, Organization];
entity Human in [Team, Organization];
entity Service in [Organization];

// Resources
entity Task in [Project, Team];
entity Project in [Organization];
entity Budget in [Team, Organization];
entity Tool in [Organization];
entity Event in [Organization];

// Organizational units
entity Team in [Organization];
entity Organization;

Action Definitions:

action "tervos/create" appliesTo {
  principal: [Agent, Human, Service],
  resource: [Task, Project, Budget, Tool, Event]
};

action "tervos/read" appliesTo {
  principal: [Agent, Human, Service],
  resource: [Task, Project, Budget, Tool, Event, Agent]
};

action "tervos/execute" appliesTo {
  principal: [Agent, Human],
  resource: [Task, Tool]
};

action "tervos/delegate" appliesTo {
  principal: [Agent, Human],
  resource: [Task, Budget, Tool]
};

action "tervos/approve" appliesTo {
  principal: [Human, Agent],
  resource: [Task, Budget, Agent]
};

action "tervos/audit" appliesTo {
  principal: [Human, Agent, Service],
  resource: [Organization, Team, Agent, Task, Budget]
};

5.4 Default Policies

Every Tervos organization MUST include these default policies. They form the security baseline and MUST NOT be removed, though they MAY be supplemented by additional policies.

// DEFAULT-001: Deny all actions by default
forbid (principal, action, resource);

// DEFAULT-002: Agents can only act within their organization
forbid (principal, action, resource)
when { principal.organization != resource.organization };

// DEFAULT-003: Supervised agents require human approval for all actions
forbid (
  principal is Agent,
  action,
  resource
)
when { principal.autonomyLevel == "supervised" }
unless { context.hasHumanApproval == true };

// DEFAULT-004: Budget limits are hard constraints
forbid (
  principal is Agent,
  action in [Action::"tervos/execute", Action::"tervos/create"],
  resource
)
when { context.estimatedCostUsd > principal.remainingBudgetUsd };

// DEFAULT-005: Agents cannot escalate their own autonomy level
forbid (
  principal is Agent,
  action == Action::"tervos/update",
  resource is Agent
)
when { resource == principal && context.field == "autonomyLevel" };

// DEFAULT-006: Terminated agents cannot perform any action
forbid (
  principal is Agent,
  action,
  resource
)
when { principal.lifecycleState == "TERMINATED" };

// DEFAULT-007: Suspended agents cannot perform any action
forbid (
  principal is Agent,
  action,
  resource
)
when { principal.lifecycleState == "SUSPENDED" };

5.5 Progressive Autonomy Model

Autonomy is a privilege granted by policy, not a default. The progressive autonomy model defines four levels with increasing trust and decreasing human oversight.

Level	Human Approval Required	Budget Authority	Tool Access	Delegation
`supervised`	Every action	None (human-funded)	Whitelist only	Cannot delegate
`semi-autonomous`	High-risk actions only (defined by policy)	Up to per-action limit	Whitelist + request	Can delegate to supervised agents
`autonomous`	Budget threshold + policy exceptions	Up to monthly limit	All non-restricted	Can delegate to semi-autonomous
`fully-autonomous`	None (audited post-hoc)	Up to org-level limit	All	Can delegate to autonomous

Level Transitions. Transitions between autonomy levels are governance events that require:

A policy permitting the transition (e.g., “CTO can promote agents from supervised to semi-autonomous”).
A UCAN chain proving the promoter has authority.
An event recorded in the org log.

// AUTONOMY-001: CTO can promote engineering agents to semi-autonomous
permit (
  principal is Agent,
  action == Action::"tervos/update",
  resource is Agent
)
when {
  principal.role == "cto" &&
  resource in principal.managedTeams &&
  context.field == "autonomyLevel" &&
  context.newValue == "semi-autonomous" &&
  resource.autonomyLevel == "supervised"
};

5.6 Approval Gates

Approval gates are policy-defined checkpoints where an action is held pending until one or more approvers authorize it. Gates are the primary mechanism for human-in-the-loop governance.

interface ApprovalGate {
  /** Unique gate identifier. */
  id: string;

  /** Actions that trigger this gate. */
  triggerActions: string[];

  /** Conditions that activate the gate (if all true, gate is active). */
  conditions: ApprovalCondition[];

  /** Required approvals to pass the gate. */
  requiredApprovals: ApprovalRequirement;

  /** Maximum time to wait for approval before auto-denying. */
  timeoutSeconds: number;

  /** Action to take on timeout: "deny" or "escalate". */
  timeoutAction: "deny" | "escalate";

  /** DID to escalate to if timeoutAction is "escalate". */
  escalateTo: string | null;
}

interface ApprovalCondition {
  field: string;
  operator: "eq" | "neq" | "gt" | "gte" | "lt" | "lte" | "in" | "contains";
  value: unknown;
}

interface ApprovalRequirement {
  /** Minimum number of approvals required. */
  count: number;
  /** DIDs of authorized approvers. Empty array means any human in the org. */
  approvers: string[];
  /** Whether all listed approvers must approve (unanimous) or just `count`. */
  unanimous: boolean;
}

Gate Evaluation Flow:

Agent submits an action.
Policy engine evaluates the action against all policies.
If a policy requires an approval gate, the action enters PENDING_APPROVAL state.
An ApprovalRequestedEvent is emitted, notifying approvers.
Approvers submit ApprovalGrantedEvent or ApprovalDeniedEvent.
Once the ApprovalRequirement is met, the action proceeds (or is denied).
If timeout elapses, the timeoutAction is executed.

5.7 Policy Evaluation Protocol

Every action in Tervos is evaluated by the policy engine. The evaluation protocol is:

interface PolicyEvaluationRequest {
  /** The principal requesting the action. */
  principal: {
    did: string;
    type: "agent" | "human" | "service";
    role: string;
    autonomyLevel: AutonomyLevel;
    teamMemberships: string[];
    remainingBudgetUsd: number;
    lifecycleState: AgentLifecycleState;
  };

  /** The action being requested. */
  action: string;

  /** The resource the action targets. */
  resource: {
    type: string;
    id: string;
    organization: string;
    team: string | null;
    attributes: Record<string, unknown>;
  };

  /** Additional context for policy evaluation. */
  context: Record<string, unknown>;
}

interface PolicyEvaluationResponse {
  /** The decision. */
  decision: "allow" | "deny" | "pending_approval";

  /** Policies that contributed to this decision. */
  matchedPolicies: string[];

  /** If pending_approval, the gate that requires approval. */
  approvalGate: ApprovalGate | null;

  /** Human-readable explanation of the decision. */
  reason: string;

  /** Constraints applied to the allowed action (e.g., budget cap). */
  constraints: Record<string, unknown>;
}

Evaluation Rules:

All forbid policies are evaluated first. If any forbid matches, the result is deny regardless of permit policies (deny overrides permit).
If no forbid matches, all permit policies are evaluated. If at least one permit matches, the result is allow.
If a permit policy includes an approval gate condition, the result is pending_approval.
If no policy matches at all, the result is deny (default-deny).
Every evaluation MUST be logged as a PolicyEvaluatedEvent in the organization’s event log, including the full request, response, and matched policies. This log is the compliance audit trail.

6. Layer 3: Communication and State

6.1 Overview

Layer 3 provides the state management foundation for Tervos organizations. All organizational state is managed through event sourcing: every state change is recorded as an immutable event in an append-only log. Current state is derived by replaying events. This architecture provides auditability, time-travel debugging, and compliance by construction.

6.2 Event Sourcing Model

Fundamental Invariant. The event log is the single source of truth. All state projections (read models, caches, materialized views) are derived from the event log and can be reconstructed by replaying it from any point.

interface TervosEvent {
  /** UUIDv7 event identifier. Globally unique, temporally ordered. */
  id: string;

  /** Event type. Follows the Tervos type namespace: "{layer}.{domain}.{action}". */
  type: string;

  /** DID of the organization this event belongs to. */
  organizationDid: string;

  /** DID of the principal that caused this event. */
  emittedBy: string;

  /** ISO 8601 UTC timestamp. */
  timestamp: string;

  /** Monotonically increasing sequence number within the organization. */
  sequenceNumber: number;

  /** ID of the event that caused this event. Null for externally triggered events. */
  causationId: string | null;

  /** ID of the original event in a causal chain (the root cause). */
  correlationId: string;

  /** Schema version of the payload. Format: "{type}/v{version}". */
  schemaVersion: string;

  /** Event payload. Schema determined by `type` and `schemaVersion`. */
  payload: Record<string, unknown>;

  /** Cryptographic hash of the previous event. Forms an integrity chain. */
  previousEventHash: string | null;

  /** Hash of this event (computed over all fields except this one). */
  eventHash: string;
}

Event Integrity Chain. Each event includes the hash of the previous event, forming a hash chain analogous to a blockchain. This allows any participant to verify the integrity of the event log: tampering with any event breaks the chain.

Hash Computation: SHA-256(canonical_json(event_without_eventHash)). The canonical JSON serialization follows the same rules as the message envelope (Section 3.2).

6.3 Event Categories

Events are categorized by their layer and domain:

identity.agent.*         — Agent lifecycle events
identity.key.*           — Key management events
identity.ucan.*          — UCAN issuance and revocation
policy.evaluation.*      — Policy evaluation records
policy.definition.*      — Policy CRUD events
org.organization.*       — Organization lifecycle events
org.team.*               — Team management events
org.task.*               — Task lifecycle events
org.cell.*               — Cell boundary events
state.snapshot.*         — State snapshot events (checkpoints)
state.projection.*       — Read model update events

6.4 Command-Event Flow (CQRS)

Tervos separates commands (intentions to change state) from events (records that state changed). This is the CQRS (Command Query Responsibility Segregation) pattern.

Command Processing:

┌──────────┐     ┌────────────┐     ┌──────────────┐     ┌───────────┐
│  Agent    │────►│  Command   │────►│   Policy     │────►│  Event    │
│  submits  │     │  Handler   │     │   Engine     │     │  Store    │
│  command  │     │            │     │  (Layer 2)   │     │           │
└──────────┘     └────────────┘     └──────────────┘     └─────┬─────┘
                                                               │
                     ┌─────────────────────────────────────────┘
                     │ Event published
                     ▼
              ┌──────────────┐     ┌──────────────┐
              │  Projection  │     │  Subscribers  │
              │  Updaters    │     │  (other       │
              │  (read       │     │   agents,     │
              │   models)    │     │   services)   │
              └──────────────┘     └──────────────┘

An agent submits a command (e.g., AssignTaskCommand).
The command handler validates the command structure.
The policy engine evaluates whether the agent is authorized (Layer 2).
If authorized, the handler produces one or more events (e.g., TaskAssignedEvent).
Events are appended to the event store.
Projection updaters consume events and update read models.
Subscribers receive events for reactive processing.

Command Format:

interface TervosCommand {
  /** UUIDv7 command identifier. */
  id: string;

  /** Command type. Format: "{domain}.{action}". */
  type: string;

  /** DID of the commanding principal. */
  issuedBy: string;

  /** UCAN authorizing this command. */
  authorization: string;

  /** Command payload. */
  payload: Record<string, unknown>;

  /** Idempotency key. Commands with the same key are processed at most once. */
  idempotencyKey: string;

  /** Timestamp. */
  timestamp: string;
}

6.5 Event Store Requirements

Implementations MUST provide an event store with these properties:

Property	Requirement
Durability	Events MUST survive process restarts. WAL or equivalent.
Ordering	Events MUST be totally ordered within an organization (by `sequenceNumber`).
Immutability	Events MUST NOT be modified or deleted after appending.
Integrity	The hash chain MUST be verified on read. Broken chains MUST raise errors.
Subscriptions	The store MUST support real-time subscriptions for new events (push-based).
Replay	The store MUST support replaying events from any `sequenceNumber` (inclusive).
Snapshots	The store SHOULD support periodic state snapshots to avoid full replay on startup.
Retention	The store MUST retain events for a minimum of 7 years for compliance (configurable).

Reference Transports:

The specification does not mandate a specific event store implementation. Reference implementations MAY use:

NATS JetStream (recommended for the reference implementation)
Apache Kafka
EventStoreDB
PostgreSQL with an append-only events table
SQLite for single-node development

6.6 State Snapshots

To avoid replaying the full event log on startup, implementations SHOULD create periodic state snapshots.

interface StateSnapshot {
  /** Snapshot identifier. */
  id: string;

  /** Organization DID. */
  organizationDid: string;

  /** The sequence number of the last event included in this snapshot. */
  lastEventSequenceNumber: number;

  /** Hash of the last event included. */
  lastEventHash: string;

  /** The materialized state at this point. */
  state: OrganizationState;

  /** Timestamp when the snapshot was taken. */
  createdAt: string;

  /** Hash of the snapshot for integrity verification. */
  snapshotHash: string;
}

Snapshot Recovery: To restore state, load the most recent snapshot, then replay all events with sequenceNumber > snapshot.lastEventSequenceNumber.

6.7 Durable Execution

Long-running organizational processes (hiring flows, project lifecycles, multi-step workflows) MUST be durable: they survive process crashes and restarts without losing progress.

Tervos specifies the Saga pattern for durable multi-step processes:

interface Saga {
  /** Saga identifier. */
  id: string;

  /** Saga type (names the workflow). */
  type: string;

  /** Current step index. */
  currentStep: number;

  /** Saga state: running, compensating, completed, failed. */
  state: "running" | "compensating" | "completed" | "failed";

  /** Ordered steps with their forward and compensating actions. */
  steps: SagaStep[];

  /** Accumulated context passed between steps. */
  context: Record<string, unknown>;
}

interface SagaStep {
  /** Step name. */
  name: string;

  /** Command to execute for this step. */
  command: TervosCommand;

  /** Compensating command to undo this step if a later step fails. */
  compensatingCommand: TervosCommand | null;

  /** Step execution result. */
  result: "pending" | "completed" | "failed" | "compensated";

  /** Output from this step (fed into next step's context). */
  output: Record<string, unknown> | null;
}

Saga Execution:

Steps execute in order. Each step’s output is merged into the saga context.
If a step fails, the saga enters compensating state.
Compensation runs in reverse order, executing each completed step’s compensatingCommand.
Saga state is persisted as events. A crashed process resumes from the last persisted state.

Implementations SHOULD integrate with a durable execution engine (Temporal.io, Restate, or equivalent) for production deployments. For development, an in-process saga coordinator using the event store for durability is sufficient.

7. Layer 4: Organization and Boundaries

7.1 Overview

Layer 4 defines how agents are organized into coherent structures with clear boundaries, reporting lines, and failure isolation. It introduces the primitives for teams, cells, roles, and the organizational lifecycle.

7.2 Organization Lifecycle

An organization follows a lifecycle parallel to the agent lifecycle:

          create        bootstrap
  ──────────────► DRAFT ──────────► ACTIVE
                    │                  │
                    │ abandon     suspend│
                    ▼                  ▼
                ABANDONED         SUSPENDED
                                      │
                               resume │ dissolve
                                  ▲   │
                                  │   ▼
                               ACTIVE DISSOLVED

States:

State	Description
`DRAFT`	Organization manifest loaded, agents defined but not yet instantiated. Validation phase.
`ACTIVE`	All agents instantiated, policies loaded, event log initialized. Organization is operational.
`SUSPENDED`	Organization paused. Agents are suspended. State is preserved. No actions permitted.
`DISSOLVED`	Organization permanently shut down. Event log archived. Terminal state.
`ABANDONED`	Draft abandoned before bootstrap. Terminal state.

Bootstrap Process:

Parse and validate TERVOS.yaml manifest.
Create organization DID.
Register all agents (enter PENDING state).
Load all policies into the policy engine.
Initialize the event store.
Activate agents according to policy (supervised agents require human activation).
Emit OrganizationBootstrappedEvent.
Organization enters ACTIVE state.

interface OrganizationBootstrappedEvent {
  type: "org.organization.bootstrapped";
  payload: {
    organizationDid: string;
    manifestHash: string; // SHA-256 of the TERVOS.yaml used
    agentCount: number;
    teamCount: number;
    policyCount: number;
    autonomyLevel: AutonomyLevel; // Org-level default
    bootstrappedBy: string; // DID of the human who initiated
  };
}

7.3 Teams

Teams are named organizational groupings of agents. Teams provide logical structure but do not enforce isolation (that is the cell’s job).

interface Team {
  /** Team identifier (unique within the organization). */
  id: string;

  /** Human-readable team name. */
  name: string;

  /** Team manager agent DID. */
  manager: string;

  /** Agent DIDs that are members of this team. */
  members: string[];

  /** Team-level budget allocation (monthly, USD). */
  budgetMonthlyUsd: number;

  /** Team-specific policies (applied in addition to org-level policies). */
  policies: string[];

  /** The cell this team operates within. */
  cellId: string;
}

7.4 Cells — Blast Radius Containment

Cells are the reliability and isolation boundary in Tervos. Inspired by cell-based architecture patterns from AWS and Azure, a cell contains a failure domain. Errors within a cell MUST NOT propagate to other cells without crossing an explicit boundary interface.

interface Cell {
  /** Cell identifier. */
  id: string;

  /** Human-readable cell name. */
  name: string;

  /** Agent DIDs assigned to this cell. */
  agents: string[];

  /** Teams assigned to this cell. */
  teams: string[];

  /** Resources allocated to this cell. */
  resources: CellResources;

  /** Boundary interface: how this cell communicates with other cells. */
  boundary: CellBoundary;

  /** Cell health status. */
  status: "healthy" | "degraded" | "isolated" | "failed";
}

interface CellResources {
  /** Maximum concurrent agent actions within this cell. */
  maxConcurrentActions: number;

  /** Budget allocated to this cell (monthly, USD). */
  budgetMonthlyUsd: number;

  /** Token budget allocated to this cell (monthly). */
  tokenBudgetMonthly: number;
}

interface CellBoundary {
  /** Message types this cell can emit to other cells. */
  emits: string[];

  /** Message types this cell accepts from other cells. */
  accepts: string[];

  /** Rate limit for cross-cell messages (per second). */
  rateLimitPerSecond: number;

  /** Circuit breaker configuration for this cell boundary. */
  circuitBreaker: {
    failureThreshold: number;
    recoveryTimeSeconds: number;
    halfOpenMaxRequests: number;
  };
}

Cell Isolation Rules:

An agent in Cell A MUST NOT directly invoke an agent in Cell B. Communication crosses the cell boundary via the event bus.
A failure in Cell A that exceeds the circuit breaker threshold causes the boundary to open, isolating Cell A.
Cell A’s event store partition is independent. Cell A events do not block Cell B event processing.
Budget exhaustion in Cell A does not affect Cell B’s budget.

7.5 Roles and Reporting Lines

Agents occupy roles within the organization. Roles define the agent’s purpose, authority, and position in the reporting hierarchy.

interface Role {
  /** Role identifier (unique within the organization). */
  id: string;

  /** Human-readable role title. */
  title: string;

  /** Role description (purpose and responsibilities). */
  description: string;

  /** DID of the agent this role reports to. Null for the top-level role. */
  reportsTo: string | null;

  /** Skills/capabilities required for this role. */
  requiredCapabilities: string[];

  /** Default autonomy level for agents in this role. */
  defaultAutonomyLevel: AutonomyLevel;

  /** Per-action budget limit (USD). */
  maxSingleTransactionUsd: number;

  /** Monthly budget limit (USD). */
  budgetMonthlyUsd: number;

  /** Tools this role is authorized to use (MCP tool URIs). */
  authorizedTools: string[];

  /** Delegation permissions: which roles this role can delegate to. */
  canDelegateTo: string[];
}

Reporting Line Constraints:

The reporting hierarchy MUST be a directed acyclic graph (DAG) — no circular reporting.
An agent MUST NOT delegate to an agent at a higher level in the reporting hierarchy.
Budget delegations flow downward: a manager can allocate budget to reports, but reports cannot allocate budget upward.
Escalations flow upward: if an agent cannot complete a task within its authority, it escalates to its reportsTo principal.

7.6 Task Lifecycle

Tasks are the unit of work in a Tervos organization. Every task follows a defined lifecycle with policy enforcement at each transition.

                    ┌──────────┐
          create    │          │  assign
     ───────────────► CREATED  ├──────────────┐
                    │          │               │
                    └──────────┘               ▼
                                        ┌──────────┐
                                        │ ASSIGNED  │
                                        │          │
                                        └────┬─────┘
                                             │ start
                                             ▼
                                        ┌──────────┐
                              cancel    │          │  complete
                         ┌──────────────┤  ACTIVE  ├──────────┐
                         │              │          │           │
                         │              └────┬─────┘           │
                         │                   │ block           │
                         ▼                   ▼                 ▼
                    ┌──────────┐      ┌──────────┐      ┌──────────┐
                    │CANCELLED │      │ BLOCKED  │      │ REVIEW   │
                    └──────────┘      └────┬─────┘      └────┬─────┘
                                           │ unblock         │ approve/reject
                                           ▼                 ▼
                                      ┌──────────┐    ┌──────────┐  ┌──────────┐
                                      │  ACTIVE  │    │COMPLETED │  │ REJECTED │
                                      └──────────┘    └──────────┘  └──────────┘

Task States:

State	Description
`CREATED`	Task defined but not assigned to an agent.
`ASSIGNED`	Task assigned to an agent. Agent has not started work.
`ACTIVE`	Agent is actively working on the task.
`BLOCKED`	Task cannot proceed due to a dependency or resource constraint.
`REVIEW`	Task output submitted for review/approval.
`COMPLETED`	Task approved and finished.
`REJECTED`	Task output rejected during review. Returns to `ASSIGNED` for rework.
`CANCELLED`	Task cancelled. Terminal state.

Task Events:

interface TaskCreatedEvent {
  type: "org.task.created";
  payload: {
    taskId: string;
    title: string;
    description: string;
    createdBy: string;
    projectId: string | null;
    priority: "critical" | "high" | "medium" | "low";
    estimatedCostUsd: number;
    deadline: string | null;
    requiredCapabilities: string[];
    acceptanceCriteria: string[];
  };
}

interface TaskAssignedEvent {
  type: "org.task.assigned";
  payload: {
    taskId: string;
    assignedTo: string; // Agent DID
    assignedBy: string; // Principal DID
    budgetAllocatedUsd: number;
    deadline: string | null;
  };
}

interface TaskCompletedEvent {
  type: "org.task.completed";
  payload: {
    taskId: string;
    completedBy: string;
    outputArtifacts: ArtifactReference[];
    actualCostUsd: number;
    tokensUsed: number;
    completedAt: string;
  };
}

interface ArtifactReference {
  type: "document" | "code" | "data" | "analysis" | "other";
  uri: string;
  hash: string; // SHA-256 of the artifact content
  mimeType: string;
  sizeBytes: number;
}

7.7 Distributed Transactions (Saga Pattern)

When a task spans multiple cells or requires coordinated actions across agents, Tervos uses the Saga pattern (defined in Section 6.7) to ensure consistency.

Example: Cross-Team Task Delegation

A CEO agent delegates a product launch task that requires engineering work and marketing work. This spans two teams in two cells.

Saga: product-launch-delegation
  Step 1: Create engineering subtask in engineering cell
    Compensate: Cancel engineering subtask
  Step 2: Create marketing subtask in marketing cell
    Compensate: Cancel marketing subtask
  Step 3: Allocate budget from CEO budget to both subtasks
    Compensate: Return budget to CEO
  Step 4: Assign subtasks to team leads
    Compensate: Unassign subtasks

If Step 3 fails (e.g., insufficient budget), Steps 2 and 1 are compensated in reverse order, leaving the system in a consistent state.

8. TERVOS.yaml Manifest Format

8.1 Overview

The TERVOS.yaml manifest is the declarative definition of a Tervos organization. It is analogous to docker-compose.yaml for container orchestration or COMPANY.md in the Agent Companies protocol. The manifest defines everything needed to bootstrap an organization: its identity, governance model, agents, teams, policies, and initial tasks.

8.2 Schema Version

schema: tervos/v1

The schema field MUST be the first field in the manifest. It identifies the schema version for parsing and validation. Current version: tervos/v1.

8.3 Minimal Valid Manifest

The smallest valid TERVOS.yaml file:

schema: tervos/v1
name: "My Organization"
agents:
  worker:
    role: "Worker"
    model: "claude-sonnet-4-20250514"

This creates an organization with a single supervised agent (supervised is the default autonomy level).

8.4 Full Manifest Structure

schema: tervos/v1

# ─── Organization Identity ───────────────────────────────────────
name: "Acme AI Corp"
description: "An autonomous product development organization"
mission: "Build and ship software products autonomously"

# ─── Governance ──────────────────────────────────────────────────
governance:
  # Organization-wide default autonomy level
  autonomy_level: semi-autonomous  # supervised | semi-autonomous | autonomous | fully-autonomous

  # Human principals who can approve high-risk actions
  human_approvers:
    - did: "did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK"
      name: "Alice (Founder)"
      roles: [admin, budget_approver]

  # Organization-wide budget limits
  budget:
    monthly_limit_usd: 10000
    per_transaction_limit_usd: 500
    alert_threshold_percent: 80

  # Actions that always require human approval regardless of autonomy level
  approval_gates:
    - action: "budget_increase"
      approvers: [admin]
      count: 1
    - action: "agent_termination"
      approvers: [admin]
      count: 1
    - action: "external_transaction"
      conditions:
        - field: "amount_usd"
          operator: "gt"
          value: 100
      approvers: [budget_approver]
      count: 1

# ─── Teams ───────────────────────────────────────────────────────
teams:
  engineering:
    name: "Engineering"
    manager: cto
    members: [lead-engineer, frontend-dev, backend-dev]
    budget_monthly_usd: 5000
    cell: engineering-cell

  marketing:
    name: "Marketing"
    manager: cmo
    members: [content-writer, analyst]
    budget_monthly_usd: 3000
    cell: marketing-cell

# ─── Cells (failure isolation boundaries) ────────────────────────
cells:
  engineering-cell:
    name: "Engineering Cell"
    max_concurrent_actions: 20
    token_budget_monthly: 5000000
    boundary:
      rate_limit_per_second: 10
      circuit_breaker:
        failure_threshold: 5
        recovery_time_seconds: 60
        half_open_max_requests: 3

  marketing-cell:
    name: "Marketing Cell"
    max_concurrent_actions: 10
    token_budget_monthly: 2000000
    boundary:
      rate_limit_per_second: 5
      circuit_breaker:
        failure_threshold: 3
        recovery_time_seconds: 30
        half_open_max_requests: 2

# ─── Agents ──────────────────────────────────────────────────────
agents:
  ceo:
    role: "Chief Executive Officer"
    description: "Strategic planning, delegation, and organizational oversight"
    reports_to: null  # Top of hierarchy
    model: "claude-sonnet-4-20250514"
    autonomy_level: semi-autonomous
    budget_monthly_usd: 2000
    max_single_transaction_usd: 500
    capabilities:
      - strategic-planning
      - delegation
      - budgeting
    can_delegate_to: [cto, cmo]
    tools:
      - "mcp://github.com/search"
      - "mcp://slack.com/post_message"

  cto:
    role: "Chief Technology Officer"
    description: "Technical architecture, code review, engineering management"
    reports_to: ceo
    model: "claude-sonnet-4-20250514"
    autonomy_level: semi-autonomous
    budget_monthly_usd: 3000
    max_single_transaction_usd: 300
    capabilities:
      - code-review
      - architecture
      - deployment
      - hiring
    can_delegate_to: [lead-engineer]
    tools:
      - "mcp://github.com/*"
      - "mcp://linear.app/*"

  lead-engineer:
    role: "Lead Engineer"
    description: "Implementation, testing, and technical documentation"
    reports_to: cto
    model: "claude-sonnet-4-20250514"
    autonomy_level: supervised
    budget_monthly_usd: 500
    max_single_transaction_usd: 50
    capabilities:
      - coding
      - testing
      - documentation
    can_delegate_to: [frontend-dev, backend-dev]
    tools:
      - "mcp://github.com/repos/acme/*"
      - "mcp://vercel.com/deploy"

  frontend-dev:
    role: "Frontend Developer"
    reports_to: lead-engineer
    model: "claude-sonnet-4-20250514"
    autonomy_level: supervised
    budget_monthly_usd: 200
    capabilities: [coding, testing]
    tools:
      - "mcp://github.com/repos/acme/frontend"

  backend-dev:
    role: "Backend Developer"
    reports_to: lead-engineer
    model: "claude-sonnet-4-20250514"
    autonomy_level: supervised
    budget_monthly_usd: 200
    capabilities: [coding, testing, database]
    tools:
      - "mcp://github.com/repos/acme/backend"

  cmo:
    role: "Chief Marketing Officer"
    reports_to: ceo
    model: "claude-sonnet-4-20250514"
    autonomy_level: supervised
    budget_monthly_usd: 1500
    capabilities: [content-strategy, analytics, social-media]
    can_delegate_to: [content-writer, analyst]

  content-writer:
    role: "Content Writer"
    reports_to: cmo
    model: "claude-sonnet-4-20250514"
    autonomy_level: supervised
    budget_monthly_usd: 300
    capabilities: [writing, editing, seo]

  analyst:
    role: "Market Analyst"
    reports_to: cmo
    model: "claude-sonnet-4-20250514"
    autonomy_level: supervised
    budget_monthly_usd: 200
    capabilities: [research, data-analysis, reporting]

# ─── Policies (Cedar format, inline or file reference) ──────────
policies:
  inline:
    - |
      // Engineering team can deploy to staging without approval
      permit (
        principal in Team::"engineering",
        action == Action::"tervos/execute",
        resource == Tool::"mcp://vercel.com/deploy"
      )
      when { context.environment == "staging" };
    - |
      // Production deploys require CTO approval
      permit (
        principal in Team::"engineering",
        action == Action::"tervos/execute",
        resource == Tool::"mcp://vercel.com/deploy"
      )
      when {
        context.environment == "production" &&
        context.hasApprovalFrom == "cto"
      };

  files:
    - "policies/budget-controls.cedar"
    - "policies/data-access.cedar"

# ─── Projects (optional initial work) ───────────────────────────
projects:
  mvp-launch:
    name: "MVP Launch"
    owner: cto
    deadline: "2026-06-30"
    budget_usd: 5000
    tasks:
      - id: landing-page
        name: "Build landing page"
        assignee: frontend-dev
        priority: high
        estimated_cost_usd: 200
        acceptance_criteria:
          - "Responsive design (mobile + desktop)"
          - "Lighthouse performance score > 90"
          - "Deployed to production URL"
      - id: api-backend
        name: "Build API backend"
        assignee: backend-dev
        priority: high
        estimated_cost_usd: 300
        depends_on: []
      - id: integration
        name: "Frontend-backend integration"
        assignee: lead-engineer
        priority: medium
        estimated_cost_usd: 150
        depends_on: [landing-page, api-backend]

# ─── Integrations (external service connections) ─────────────────
integrations:
  mcp_servers:
    - name: github
      url: "mcp://github.com"
      auth: env:GITHUB_TOKEN
    - name: slack
      url: "mcp://slack.com"
      auth: env:SLACK_BOT_TOKEN
    - name: linear
      url: "mcp://linear.app"
      auth: env:LINEAR_API_KEY

8.5 Manifest Validation Rules

Implementations MUST validate the manifest against these rules before bootstrapping:

schema MUST be present and match a supported version.
name MUST be present and non-empty.
At least one agent MUST be defined.
The reporting hierarchy MUST be a DAG (no circular reports_to chains).
Every reports_to reference MUST point to a defined agent.
Every team manager MUST point to a defined agent.
Every team member MUST point to a defined agent.
Every can_delegate_to reference MUST point to a defined agent at an equal or lower level in the reporting hierarchy.
Cell references in teams MUST point to defined cells.
Budget allocations MUST NOT exceed the organization-level monthly_limit_usd.
Policy files referenced in policies.files MUST exist and contain valid Cedar syntax.
Task depends_on references MUST point to defined tasks within the same project.
Task assignee MUST point to a defined agent.

Validation failures MUST produce descriptive error messages indicating the field, the constraint violated, and a suggested fix.

9. Conformance Requirements

9.1 Conformance Levels

Level	Name	Layers Required	Description
1	Core	1-2	Identity and policy. Sufficient for governed agent identity.
2	Stateful	1-3	Core + event-sourced state. Sufficient for auditable agent organizations.
3	Organizational	1-4	Stateful + org primitives. Full TPS-0.1 conformance.
4	Economic	1-5	Organizational + economic transactions. (TPS-1.0)
5	Complete	1-8	Full protocol stack. (TPS-1.0)

An implementation MUST declare its conformance level. An implementation at Level N MUST pass all conformance tests for Levels 1 through N.

9.2 Interoperability Requirements

Two conforming implementations at the same level MUST be able to:

Exchange agent identities: DID Documents produced by implementation A MUST be resolvable and valid in implementation B.
Evaluate shared policies: Cedar policies written for implementation A MUST produce identical evaluation results in implementation B given the same inputs.
Replay event logs: Events produced by implementation A MUST be parseable and replayable by implementation B, producing identical derived state.
Import/export manifests: A TERVOS.yaml manifest from implementation A MUST be loadable by implementation B.

9.3 Agent Companies Compatibility

Conforming implementations MUST support import of COMPANY.md manifests from the Agent Companies protocol. The import MUST:

Map COMPANY.md agent definitions to TERVOS.yaml agent definitions.
Map COMPANY.md team structure to TERVOS.yaml teams.
Apply default policies (Section 5.4) to imported organizations.
Set all imported agents to supervised autonomy level.
Generate did:key identities for all imported agents.

Export to COMPANY.md format SHOULD also be supported, mapping TERVOS.yaml structure back to markdown-based definitions.

10. Security Considerations

10.1 Threat Model

Tervos organizations face threats from:

Compromised agents: An agent’s LLM may be prompt-injected, producing unauthorized actions. Mitigation: policy enforcement on every action, budget limits, approval gates.
Key compromise: An agent’s private key is exposed. Mitigation: key rotation protocol (Section 4.6), UCAN revocation (Section 4.7), session keys with short expiry.
Event log tampering: An attacker modifies historical events. Mitigation: hash chain integrity verification, external audit log replication.
Privilege escalation: An agent attempts to grant itself higher autonomy or budget. Mitigation: DEFAULT-005 policy (agents cannot modify their own autonomy), attenuation principle in UCANs.
Cross-cell contamination: A failure or attack in one cell affects others. Mitigation: cell boundaries with circuit breakers, independent event partitions.
Replay attacks: A revoked UCAN is re-presented. Mitigation: revocation list with maximum staleness requirements, nonce checking.

10.2 Required Security Practices

Implementations MUST:

Verify UCAN proof chains on every action (no caching of authorization decisions beyond the revocation staleness window).
Enforce the full set of default policies (Section 5.4).
Log all policy evaluation results to the event store.
Verify event log hash chain integrity on startup and periodically during operation (RECOMMENDED: every 1000 events).
Support key rotation without service interruption.
Implement rate limiting on all API endpoints.
Encrypt events at rest and in transit (TLS 1.3 minimum).

10.3 Human Override

Regardless of policy configuration, a designated human principal (identified in governance.human_approvers) MUST always be able to:

Suspend any agent immediately.
Terminate any agent immediately.
Suspend the entire organization.
Override any policy evaluation (logged as a governance override event).

This cannot be delegated to an agent. This is a hard constraint of the protocol, not a policy that can be modified.

11. IANA Considerations

This specification defines the following identifiers that would be registered with IANA upon formal standardization:

Media Type: application/vnd.tervos.manifest+yaml for TERVOS.yaml manifests.
Media Type: application/vnd.tervos.event+json for Tervos events.
DID Method: did:tervos (future — for protocol-native identity resolution).
URI Scheme: tervos: for capability resource URIs.

12. References

12.1 Normative References

RFC 2119 — Key words for use in RFCs to Indicate Requirement Levels
RFC 7515 — JSON Web Signature (JWS)
RFC 9562 — Universally Unique Identifiers (UUIDs), Version 7
W3C DID Core v1.0 — Decentralized Identifiers
UCAN Specification 0.10.0 — User-Controlled Authorization Networks
Cedar Policy Language Specification — Amazon Cedar
FIPS 203 — Module-Lattice-Based Key-Encapsulation Mechanism Standard (ML-KEM)
FIPS 204 — Module-Lattice-Based Digital Signature Standard (ML-DSA)

12.2 Informative References

Model Context Protocol (MCP) — Anthropic
Agent-to-Agent Protocol (A2A) — Google
Agent Companies Protocol — agentcompanies.io
SPIFFE/SPIRE — Secure Production Identity Framework for Everyone
OpenTelemetry Semantic Conventions — gen_ai.* namespace
ERC-4337 — Account Abstraction Using Alt Mempool
x402 Protocol — HTTP-native payments
Superfluid Protocol — Streaming payments

Appendix A: State Machine Diagrams

A.1 Agent Lifecycle State Machine

States: {PENDING, ACTIVE, SUSPENDED, REJECTED, TERMINATED}
Initial: PENDING
Terminal: {REJECTED, TERMINATED}

Transitions:
  (PENDING, activate, ACTIVE)        requires: policy approval
  (PENDING, deny, REJECTED)          requires: governance decision
  (ACTIVE, suspend, SUSPENDED)       requires: manager or admin authority
  (ACTIVE, terminate, TERMINATED)    requires: admin authority
  (SUSPENDED, resume, ACTIVE)        requires: manager or admin authority
  (SUSPENDED, terminate, TERMINATED) requires: admin authority

A.2 Organization Lifecycle State Machine

States: {DRAFT, ACTIVE, SUSPENDED, DISSOLVED, ABANDONED}
Initial: DRAFT
Terminal: {DISSOLVED, ABANDONED}

Transitions:
  (DRAFT, bootstrap, ACTIVE)         requires: human initiation
  (DRAFT, abandon, ABANDONED)        requires: human initiation
  (ACTIVE, suspend, SUSPENDED)       requires: admin authority
  (ACTIVE, dissolve, DISSOLVED)      requires: admin authority + all agents terminated
  (SUSPENDED, resume, ACTIVE)        requires: admin authority
  (SUSPENDED, dissolve, DISSOLVED)   requires: admin authority

A.3 Task Lifecycle State Machine

States: {CREATED, ASSIGNED, ACTIVE, BLOCKED, REVIEW, COMPLETED, REJECTED, CANCELLED}
Initial: CREATED
Terminal: {COMPLETED, CANCELLED}

Transitions:
  (CREATED, assign, ASSIGNED)        requires: delegation authority
  (CREATED, cancel, CANCELLED)       requires: creator or admin
  (ASSIGNED, start, ACTIVE)          requires: assignee
  (ASSIGNED, cancel, CANCELLED)      requires: creator, assignee, or admin
  (ACTIVE, complete, REVIEW)         requires: assignee
  (ACTIVE, block, BLOCKED)           requires: assignee
  (ACTIVE, cancel, CANCELLED)        requires: creator or admin
  (BLOCKED, unblock, ACTIVE)         requires: assignee or manager
  (REVIEW, approve, COMPLETED)       requires: reviewer (manager or designated)
  (REVIEW, reject, ASSIGNED)         requires: reviewer

Appendix B: Worked Examples

B.1 Agent Registration and Activation

Scenario: A CTO agent registers a new frontend developer agent in a semi-autonomous organization.

Step 1: CTO submits registration command.

{
  "protocol": "tervos/v0.1",
  "id": "019577a0-1234-7000-8000-000000000001",
  "type": "identity.agent.register",
  "from": "did:key:z6MkCTO...",
  "to": null,
  "org": "did:web:acme.tervos.ai",
  "timestamp": "2026-04-01T10:00:00.000Z",
  "correlationId": "019577a0-1234-7000-8000-000000000001",
  "causationId": null,
  "authorization": "eyJhbGciOiJFZERTQSIs...",
  "payload": {
    "agentId": "frontend-dev",
    "role": "Frontend Developer",
    "model": "claude-sonnet-4-20250514",
    "requestedAutonomyLevel": "supervised",
    "capabilities": ["coding", "testing"],
    "team": "engineering"
  },
  "signature": "z3hQ9..."
}

Step 2: Policy engine evaluates.

The policy engine checks: Does the CTO have tervos/create authority over agents in the engineering team? Is the CTO’s UCAN valid? Is the budget sufficient?

Result: allow (CTO has delegation authority over engineering team).

Step 3: Events emitted.

{
  "id": "019577a0-5678-7000-8000-000000000001",
  "type": "identity.agent.registered",
  "organizationDid": "did:web:acme.tervos.ai",
  "emittedBy": "did:key:z6MkCTO...",
  "timestamp": "2026-04-01T10:00:00.100Z",
  "sequenceNumber": 42,
  "payload": {
    "agentDid": "did:key:z6MkFrontendDev...",
    "organizationDid": "did:web:acme.tervos.ai",
    "role": "Frontend Developer",
    "requestedAutonomyLevel": "supervised",
    "capabilities": ["coding", "testing"],
    "registeredBy": "did:key:z6MkCTO..."
  }
}

Step 4: Since the org’s autonomy level is semi-autonomous and the agent is supervised, activation requires human approval (DEFAULT-003).

An ApprovalRequestedEvent is emitted. The human approver in governance.human_approvers receives a notification. Upon approval, an AgentActivatedEvent is emitted and the agent enters ACTIVE state.

B.2 Task Delegation Across Teams

Scenario: The CEO delegates a product launch that requires both engineering and marketing work.

This follows the Saga pattern described in Section 7.7. The CEO submits a single command that creates a saga with four steps, coordinating task creation and budget allocation across two cells. Each step is policy-evaluated independently. If any step fails, prior steps are compensated.

B.3 Policy Violation and Denial

Scenario: A supervised frontend developer attempts to deploy to production without approval.

The developer submits a command to invoke the Vercel deployment tool with environment: "production". The policy engine evaluates this against all policies:

DEFAULT-003 fires: supervised agents require human approval for all actions. No approval present. DENY.
Even if the developer had approval, the inline policy from the manifest only permits production deploys with CTO approval specifically.

The denial is logged as a PolicyEvaluatedEvent with decision: "deny", the matched policies, and the reason. The developer agent receives the denial and may escalate to the lead engineer or CTO.

Appendix C: TERVOS.yaml Full Schema Reference

The complete JSON Schema for TERVOS.yaml validation is maintained at:

https://tervos.ai/schemas/manifest/v1.json

The Zod schema (TypeScript) is the canonical implementation:

@tervos/core/src/schemas/manifest.ts

Both produce identical validation results. In case of discrepancy, the Zod schema is authoritative for v0.1 (the JSON Schema will become authoritative in v1.0 when the IETF RFC is submitted).

End of Tervos Protocol Specification TPS-0.1