Back to Documentation
AdvancedUpdated 2026-04-02

Multi-Agent Orchestration

Council system with 4 validators, orchestrator pattern, intent-to-decision-to-execution flow, and how multiple agents coordinate under governance.

Multi-Agent Orchestration

When a single agent cannot handle an action alone -- because it lacks sufficient trust, needs domain expertise, or faces a critical-risk decision -- Vorion coordinates multiple agents through structured governance patterns.

This page covers the Council voting system, the orchestrator pattern, and how intent flows through a multi-agent decision pipeline.

The Council System

The Council is Vorion's multi-agent governance mechanism. When an action is escalated (by ENFORCE or by an agent), the Council convenes a set of specialized validators to vote on the request.

Four Validators

type ValidatorId = 'guardian' | 'arbiter' | 'scholar' | 'advocate';

| Validator | Domain | Role | |-----------|--------|------| | Guardian | Safety and security | Evaluates risk, blocks unsafe actions | | Arbiter | Rules and compliance | Checks policy alignment, regulatory constraints | | Scholar | Knowledge and context | Assesses factual basis, domain accuracy | | Advocate | Agent interests | Argues for the agent's intent when justified |

Each validator has a system prompt defining its perspective and evaluation criteria. Validators vote independently and in parallel.

Vote Structure

interface ValidatorVote {
  validatorId: ValidatorId;
  decision: 'approve' | 'deny' | 'abstain';
  reasoning: string;
  confidence: number;  // 0-1
  votedAt: string;
}

Validators vote at temperature 0 (deterministic) for governance consistency. On error, a validator abstains with confidence 0 rather than blocking the decision pipeline.

Decision Logic

The required number of validators and approval threshold scales with risk:

| Risk Level | Validators Required | Approval Rule | |------------|-------------------|---------------| | Low (0-1) | None | Auto-approve (logged) | | Medium (2) | Guardian only | Single validator approval | | High (3) | All 4 validators | Majority: 3 of 4 (75%) | | Critical (4)| All 4 validators | Unanimous + human confirmation |

graph TD
    REQ[Upchain Request] --> RISK{Risk Level?}

    RISK -->|Low 0-1| AUTO[Auto-Approve<br/>Logged]
    RISK -->|Medium 2| SINGLE[Guardian Vote]
    RISK -->|High 3| FULL[All 4 Validators]
    RISK -->|Critical 4| FULL

    SINGLE -->|approve| APPROVE[APPROVED]
    SINGLE -->|deny| DENY[DENIED]
    SINGLE -->|abstain| ESC1[ESCALATED<br/>to human]

    FULL --> TALLY{Tally Votes}
    TALLY -->|>= 75% approve<br/>risk=3| APPROVE
    TALLY -->|any deny<br/>risk=4| DENY
    TALLY -->|unanimous<br/>risk=4| ESC2[ESCALATED<br/>human confirmation]
    TALLY -->|no majority| ESC3[ESCALATED<br/>no consensus]

Council Decision

interface CouncilDecision {
  id: string;
  requestId: string;
  agentId: string;
  votes: ValidatorVote[];
  outcome: 'approved' | 'denied' | 'escalated' | 'pending';
  finalReasoning: string;
  createsPrecedent: boolean;
  precedentId?: string;
  decidedAt: string;
  expiresAt: string;           // Stale decisions must be re-evaluated
  recordedOnTruthChain: boolean;
}

Council decisions have a 15-minute TTL (COUNCIL_DECISION_TTL_MS). After expiration, the decision cannot be used to authorize execution -- the agent must request a new evaluation.

import { isDecisionValid } from '@/lib/council/types';

if (!isDecisionValid(decision)) {
  // Decision expired -- re-evaluate
  const freshDecision = await evaluateRequest(request);
}

Upchain Request Flow

An "upchain" request is when an agent asks the Council to evaluate an action it cannot perform autonomously.

interface UpchainRequest {
  id: string;
  agentId: string;
  actionType: string;
  actionDetails: string;
  context: Record<string, any>;
  justification: string;
  riskLevel: RiskLevel;
  requestedAt: string;
}

Full Flow

sequenceDiagram
    participant Agent as Worker Agent (T2)
    participant ORC as Orchestrator
    participant Council as Council (4 validators)
    participant TC as Truth Chain
    participant ENG as Trust Engine

    Agent->>ORC: I need to delete staging records
    ORC->>ORC: Classify risk: HIGH (3)
    ORC->>Council: UpchainRequest (risk=3)

    par Parallel Voting
        Council->>Council: Guardian evaluates
        Council->>Council: Arbiter evaluates
        Council->>Council: Scholar evaluates
        Council->>Council: Advocate evaluates
    end

    Council->>Council: Tally: 3 approve, 1 abstain
    Council-->>ORC: APPROVED (majority)
    ORC->>TC: Record decision on truth chain
    ORC->>Agent: Execute within governance
    Agent->>ENG: Proof recorded

Precedent System

Significant decisions (risk >= 3, outcome approved or denied) create precedents. Future requests with similar characteristics can reference precedents for faster evaluation.

const decision = await evaluateRequest(request, {
  precedents: relevantPrecedents,
});

if (decision.createsPrecedent) {
  // This decision will inform future evaluations
  console.log('Precedent ID:', decision.precedentId);
}

Orchestrator Pattern

The A3I Orchestrator coordinates multi-agent workflows. It manages:

  1. Intent routing -- Determining which agent(s) should handle a request
  2. Trust-scoped dispatch -- Ensuring agents only receive actions within their tier
  3. Delegation -- Escalating actions to higher-trust agents when needed
  4. Result aggregation -- Combining outputs from multiple agents

Trust Band to Autonomy

The orchestrator uses trust bands to determine what each agent can do automatically versus what needs council approval:

const TRUST_BAND_AUTONOMY: Record<TrustBand, CanonicalRiskLevel> = {
  T0_SANDBOX:     'low',       // Low-risk only
  T1_OBSERVED:    'low',
  T2_PROVISIONAL: 'medium',    // Low-medium auto
  T3_MONITORED:   'medium',
  T4_STANDARD:    'high',      // Low-high auto
  T5_TRUSTED:     'high',
  T6_CERTIFIED:   'critical',  // Low-critical with oversight
  T7_AUTONOMOUS:  'critical',  // Full autonomy
};

If an agent needs to perform an action above its autonomy level, the orchestrator routes it to the council or delegates to a higher-trust agent.

Multi-Agent Coordination Example

Consider a data pipeline that requires three agents:

  1. Reader (T1, score 250) -- Reads source data
  2. Transformer (T3, score 550) -- Processes and transforms data
  3. Writer (T4, score 700) -- Writes to production database
graph LR
    subgraph "Data Pipeline"
        R[Reader T1<br/>READ risk] -->|data| T[Transformer T3<br/>MEDIUM risk]
        T -->|transformed| W[Writer T4<br/>HIGH risk]
    end

    subgraph "Governance"
        E1[ENFORCE: ALLOW<br/>250 >= 0 for READ]
        E2[ENFORCE: ALLOW<br/>550 >= 400 for MEDIUM]
        E3[ENFORCE: ALLOW<br/>700 >= 600 for HIGH]
    end

    R -.-> E1
    T -.-> E2
    W -.-> E3

Each agent operates at its own trust level. The Reader cannot write to production (it lacks the trust and capability). The Writer cannot read source data without the Reader's output. The orchestrator chains them together, with each agent independently governed.

Agent-to-Agent Communication

When agents communicate directly, trust is verified at each hop:

interface A2ARequest {
  caller: {
    car: string;        // CAR identifier
    signature: string;  // Ed25519 signature
    nonce: string;
  };
  target: {
    car: string;
    endpoint: string;
    requiredTrust?: number;
  };
  action: string;
  payload: unknown;
  trustContext: {
    callerScore: number;
    attestationChain?: string[];
  };
}

The target agent verifies:

  1. The caller's CAR is valid
  2. The caller's trust score meets the target's minimum requirement
  3. The cryptographic signature is valid

If trust is insufficient, the request is denied. The caller can escalate through the delegation system.

Examination (Academy Graduation)

The Council also handles agent qualification decisions. When an agent completes its training course, the Council evaluates whether to graduate it:

import { evaluateExamination } from '@/lib/council/council-service';

const decision = await evaluateExamination(
  'trainee-agent-001',
  'standard-onboarding',
  {
    modulesCompleted: 31,
    totalModules: 31,
    averageScore: 87,
  },
);
// Risk level 2 (elevated) -- single validator (Guardian) can approve

This is treated as a risk-level-2 action -- the Guardian validator evaluates whether the training results meet the qualification bar.

Governance Constraints

All multi-agent patterns respect these constraints:

  1. Trust is not transitive: Agent A trusting Agent B does not mean Agent B trusts Agent A
  2. Trust is not inherited: Spawned agents start at score 0 regardless of parent
  3. Decisions expire: Council decisions have 15-minute TTL
  4. Proofs are mandatory: Every inter-agent action produces a proof record
  5. Escalation is upward: Lower agents get results, not authority
  6. Penalties propagate: All agents in a delegation chain share failure penalties

Next Steps

All Documentation