Chain of Command

agents

Chain of Command

Definition

Chain of Command is a hierarchical authority structure that defines how decisions, directives, and information flow through a multi-tier agent system. In the Prismatic Platform, the chain of command governs the relationship between 530+ AIAD agents organized across five authority levels: L5 Supreme, L4 Command, L3 Strategic, L2 Tactical, and L1 Operational. Each tier has precisely defined responsibilities, escalation paths, and override capabilities, ensuring that every action taken by any agent can be traced back through a clear authority lineage.

Unlike flat organizational structures where any component can invoke any other, a chain of command enforces disciplined information flow -- directives propagate downward while reports, alerts, and escalations propagate upward. This bidirectional flow ensures accountability at every level and prevents unauthorized lateral action that could compromise system integrity.

Overview

The concept of a chain of command originates from military and organizational theory, where clear hierarchical structures prevent confusion, duplication of effort, and unauthorized actions. In software systems, this translates to governance models that control how autonomous agents make decisions, access resources, and interact with each other.

In the Prismatic Platform, the chain of command is not merely an organizational metaphor -- it is a runtime-enforced authority system embedded in the AIAD framework. Every agent declaration includes an explicit authority_level field that determines what operations it can perform, what resources it can access, and which other agents it can direct or override.

The five-tier hierarchy creates natural separation of concerns:

  • L5 Supreme agents hold cosmic clearance and can override any lower-tier decision
  • L4 Command agents orchestrate cross-domain operations
  • L3 Strategic agents plan and coordinate within their domain
  • L2 Tactical agents execute specific operational tasks
  • L1 Operational agents perform atomic, focused actions

This tiered approach ensures that critical decisions (security policy changes, production deployments, quality gate overrides) require appropriate authority while routine operations proceed without unnecessary escalation.

Technical Details

Authority Tier Architecture

The chain of command in Prismatic is implemented through a combination of AIAD agent specifications, runtime authority checks, and supervision tree hierarchies.

TierAuthority LevelScopeOverride PowerAgent CountExample Agents
L5Supreme / CosmicPlatform-wideAll tiers~5archer-supreme, supreme-coordinator
L4CommandCross-domainL3 and below~15orchestrator, red-commander, blue-commander
L3StrategicDomain-wideL2 and below~60elixir-architect, security-analyst, quality-guardian
L2TacticalTask-specificL1 only~200code-reviewer, test-runner, drift-detector
L1OperationalAtomic actionsNone~250file-scanner, lint-checker, metric-collector

Decision Flow Model

Decisions in the chain of command follow a strict downward delegation pattern with upward reporting:

L5 Supreme ──────────── Platform Directive
    │
    ├── L4 Command ──── Cross-Domain Orchestration
    │       │
    │       ├── L3 Strategic ──── Domain Planning
    │       │       │
    │       │       ├── L2 Tactical ──── Task Execution
    │       │       │       │
    │       │       │       └── L1 Operational ──── Atomic Action
    │       │       │
    │       │       └── L2 Tactical ──── Task Execution
    │       │
    │       └── L3 Strategic ──── Domain Planning
    │
    └── L4 Command ──── Cross-Domain Orchestration

Elixir Implementation

The chain of command is enforced through GenServer-based authority validation:

defmodule PrismaticAgents.ChainOfCommand do
  @moduledoc """
  Enforces hierarchical authority structure across the AIAD agent system.
  Validates that agent operations respect tier boundaries, escalation paths,
  and override permissions defined by the chain of command.
  """

  use GenServer

  alias PrismaticAgents.{AgentRegistry, AuthorityValidator}

  @type tier :: :l5_supreme | :l4_command | :l3_strategic | :l2_tactical | :l1_operational
  @type authority_check :: {:ok, :authorized} | {:error, :insufficient_authority}
  @type escalation :: {:escalate, tier(), term()}

  @tier_hierarchy %{
    l5_supreme: 5,
    l4_command: 4,
    l3_strategic: 3,
    l2_tactical: 2,
    l1_operational: 1
  }

  # --- Client API ---

  @spec start_link(keyword()) :: GenServer.on_start()
  def start_link(opts \\ []) do
    GenServer.start_link(__MODULE__, opts, name: __MODULE__)
  end

  @doc """
  Validates whether an agent at a given tier can direct an operation
  at or below the specified target tier.
  """
  @spec authorize_directive(tier(), tier(), term()) :: authority_check()
  def authorize_directive(source_tier, target_tier, operation) do
    GenServer.call(__MODULE__, {:authorize, source_tier, target_tier, operation})
  end

  @doc """
  Routes an escalation request upward through the chain of command
  until an agent with sufficient authority is found.
  """
  @spec escalate(tier(), term()) :: {:ok, tier()} | {:error, :no_authority_available}
  def escalate(current_tier, issue) do
    GenServer.call(__MODULE__, {:escalate, current_tier, issue})
  end

  @doc """
  Returns the complete chain from a given tier up to L5 Supreme.
  """
  @spec chain_above(tier()) :: [tier()]
  def chain_above(tier) do
    tier_value = Map.fetch!(@tier_hierarchy, tier)

    @tier_hierarchy
    |> Enum.filter(fn {_name, value} -> value > tier_value end)
    |> Enum.sort_by(fn {_name, value} -> value end)
    |> Enum.map(fn {name, _value} -> name end)
  end

  # --- Server Callbacks ---

  @impl GenServer
  def init(opts) do
    state = %{
      escalation_log: [],
      override_history: [],
      config: Keyword.get(opts, :config, %{})
    }

    {:ok, state}
  end

  @impl GenServer
  def handle_call({:authorize, source_tier, target_tier, operation}, _from, state) do
    source_level = Map.fetch!(@tier_hierarchy, source_tier)
    target_level = Map.fetch!(@tier_hierarchy, target_tier)

    result =
      if source_level >= target_level do
        AuthorityValidator.validate_operation(source_tier, operation)
      else
        {:error, :insufficient_authority}
      end

    {:reply, result, state}
  end

  @impl GenServer
  def handle_call({:escalate, current_tier, issue}, _from, state) do
    case find_authority(current_tier, issue) do
      {:ok, resolving_tier} ->
        updated_log = [{current_tier, resolving_tier, issue, DateTime.utc_now()} | state.escalation_log]
        {:reply, {:ok, resolving_tier}, %{state | escalation_log: updated_log}}

      {:error, reason} ->
        {:reply, {:error, reason}, state}
    end
  end

  # --- Private Functions ---

  defp find_authority(current_tier, issue) do
    current_tier
    |> chain_above()
    |> Enum.find_value({:error, :no_authority_available}, fn tier ->
      case AuthorityValidator.can_resolve?(tier, issue) do
        true -> {:ok, tier}
        false -> nil
      end
    end)
  end
end

AIAD Agent Specification

Every agent in the AIAD framework declares its position in the chain of command through a YAML specification:

# .aiad/agents/example-tactical-agent.agent.md
agent-spec:
  id: "tactical-scanner"
  name: "Tactical Security Scanner"
  authority_level: "L2"
  tier: "tactical"
  chain_of_command:
    reports_to: "security-analyst"       # L3 Strategic
    can_direct: ["file-scanner", "lint-checker"]  # L1 Operational
    escalation_path: ["security-analyst", "red-commander", "archer-supreme"]
  permissions:
    read: ["source_code", "configuration"]
    write: ["scan_results", "alerts"]
    execute: ["static_analysis", "pattern_matching"]
  enforcement:
    doctrine: "no-mercy-no-doubts"
    version: "2.0.0"
    compliance: mandatory

Escalation Protocol

When an agent encounters a situation that exceeds its authority, the chain of command defines a strict escalation protocol:

StepActionTimeoutFallback
1Agent identifies authority gapImmediateLog and halt
2Escalate to direct superior (next tier)5 secondsSkip to tier above
3Superior evaluates and either resolves or escalates10 secondsAuto-escalate
4Continue until resolution or L5 Supreme reached30 seconds totalEmergency halt
5L5 Supreme makes final decisionNo timeoutAlways resolves

Implementation in Prismatic Platform

The chain of command is deeply integrated into the Prismatic Platform's 530+ agent ecosystem:

Agent Registry: The Agent Registry maintains a complete mapping of every agent's tier, reporting relationships, and override permissions. This registry is consulted on every cross-agent interaction to validate authority.

Supervision Trees: Elixir's OTP supervision tree architecture naturally mirrors the chain of command. Higher-tier agents supervise lower-tier agents, with restart strategies propagating through the hierarchy.

Color Team Integration: The six color teams (Gray, Red, Blue, Purple, White, Black) each have their own internal chain of command with L3 commanders directing L2 and L1 specialists. Cross-team coordination flows through the Purple coordinator at L3, with L4 Command agents orchestrating multi-team operations.

NO MERCY Enforcement: The No Mercy, No Doubts doctrine is enforced at every tier. An L1 agent cannot bypass quality gates any more than an L2 agent can -- the doctrine applies universally, but enforcement authority escalates with tier level.

Runtime Telemetry: Every authority check, escalation, and override is logged through Telemetry events ([:prismatic_agents, :chain_of_command, :authorize | :escalate | :override]), providing complete audit trails for governance compliance.

Comparison with Alternatives

ModelDecision FlowOverride MechanismScalabilityPrismatic Fit
Chain of Command (Prismatic)Strict hierarchicalTier-based overrideExcellent (530+ agents)Native
Flat/Peer-to-PeerAny-to-anyConsensus-basedPoor at scaleRejected
Matrix OrganizationDual reportingNegotiationModerateToo ambiguous
Hub-and-SpokeCentral coordinatorCentral authorityBottleneck riskPartial (L4 only)
HolacracyCircle-basedGovernance meetingsModerateToo slow for real-time

The strict hierarchical model was chosen for Prismatic because it provides deterministic authority resolution -- there is never ambiguity about who has the authority to make a decision. In a system with 530+ agents operating across security, quality, intelligence, and development domains, ambiguity in authority would be catastrophic.

Best Practices

  1. Explicit Authority Declaration: Every agent must declare its tier and reporting relationships in its AIAD specification. Implicit authority is forbidden.

  2. Minimal Authority Principle: Agents should operate at the lowest tier that can accomplish their task. Do not assign L3 Strategic authority to an agent that only needs L1 Operational access.

  3. Fast Escalation: When an agent encounters an authority boundary, escalate immediately rather than attempting workarounds. The chain of command is designed for rapid escalation (sub-second at each tier).

  4. Audit Everything: Every authority check and escalation must produce telemetry events. Silent authority decisions are a governance violation.

  5. Test Tier Boundaries: Write tests that verify agents cannot exceed their tier authority. Property-based testing is particularly effective for validating authority boundaries across all tier combinations.

  6. Document Override Rationale: When a higher-tier agent overrides a lower-tier decision, the override reason must be logged and traceable.

  7. Separation of Command and Execution: L4/L5 agents should direct but not directly execute. Execution belongs to L1/L2 agents under the direction of their superiors.

Common Pitfalls

  1. Authority Inflation: Assigning agents higher tiers than necessary "just in case." This defeats the purpose of hierarchical control and creates unnecessary override surface area.

  2. Escalation Loops: Poorly configured escalation paths that cycle between two agents at the same tier. The chain_above/1 function prevents this by only escalating upward.

  3. Bypassing the Chain: Allowing an L1 agent to directly invoke an L5 Supreme operation. Every interaction must pass through intermediate tiers or use the formal escalation protocol.

  4. Missing Fallbacks: Not defining what happens when the entire chain is unavailable. The implementation includes timeout-based auto-escalation and emergency halt mechanisms.

  5. Conflicting Commands: Two L3 agents in different domains issuing contradictory directives to the same L2 agent. This is resolved by domain isolation -- agents can only direct within their domain, with cross-domain coordination handled by L4 Command.

  6. Stale Authority State: Agent registry not reflecting current tier assignments after reconfiguration. The ETS-backed registry with PubSub notifications ensures consistency.

Use Cases

Security Incident Response

When the Blue Team's drift detector (L2) identifies a potential security anomaly, it escalates through the chain: L2 Drift Detector reports to L3 Blue Commander, who evaluates and potentially escalates to L4 Purple Coordinator for cross-team synthesis. If the threat is severe, L5 Supreme (archer-supreme) takes direct control, overriding all lower-tier decisions.

Quality Gate Enforcement

The quality gate system uses the chain of command to determine who can waive specific checks. L1 agents run individual checks, L2 agents aggregate results, L3 agents evaluate domain-level quality, and only L5 Supreme can authorize a quality gate bypass (which is documented and audited).

Multi-Domain Orchestration

When a feature requires changes across multiple umbrella applications, an L4 Command agent (the orchestrator) coordinates L3 Strategic agents in each domain, who in turn direct their L2 Tactical and L1 Operational agents. The chain ensures that database migrations, API changes, and UI updates proceed in the correct order.

Emergency Platform Recovery

During a critical failure, the chain of command enables rapid response. L5 Supreme can issue platform-wide directives that propagate through all tiers simultaneously, overriding normal operational procedures. The autoheal system leverages this for autonomous recovery.

See Also

Connect & Contribute

Created by Tomas Korcak (korczis) | Open Source under GHL

Back to Glossary