Why multi-agent alignment matters
A single agent’s alignment is between it and its principal. Multi-agent alignment introduces a harder problem: inter-agent compatibility. Two agents can each be perfectly aligned with their respective principals while being fundamentally incompatible with each other. Consider:- Agent A declares
minimal_dataas a core value. Agent B requirescomprehensive_analyticsto function. If A delegates data collection to B, whose value wins? - Agent A commits to
transparencyand discloses all reasoning. Agent B treats its decision process as proprietary. Their definitions of good behavior conflict. - Agent A’s
conflicts_withlist includes a value that Agent B declares. No amount of runtime negotiation fixes a structural incompatibility.
Registering multiple agents
Each agent gets its own Alignment Card declaring its values, autonomy envelope, and audit commitment. There is no shared card for a fleet — alignment is per-agent. Here are two agents with different value sets and operational scopes:Value Coherence checks
Before two agents coordinate on a task, run a coherence check to verify their values are compatible. Thecheck_coherence function compares both Alignment Cards and returns a structured result.
Understanding the result
The coherence result contains three key fields:Coherence checks operate on declared values only. They verify that two agents’ claims are compatible, not that either agent actually acts on those values. Behavioral verification happens through AP-Traces and integrity checkpoints.
Fleet monitoring with the Mnemom Gateway
When you run multiple agents through the Mnemom gateway, each agent gets its own:- Trace history — Every AP-Trace and integrity checkpoint is stored per agent, queryable by agent ID.
- Integrity scores — Rolling integrity ratio computed from recent checkpoints. A healthy agent stays above 0.90.
- Drift alerts — Automated alerts when behavioral patterns shift away from the agent’s declared alignment.
Drift detection across agents
Each agent should be monitored for drift independently. Drift is the gradual divergence of an agent’s behavior from its declared alignment — it rarely appears as a single dramatic violation. More commonly, an agent that used to escalate 15% of decisions quietly drops to 5%, or stops applying a declared value in its traces. Usedetect_drift per agent to compare recent traces against the agent’s baseline:
sustained_threshold parameter controls how many consecutive low-similarity traces are required before an alert fires, preventing false positives from one-off edge cases.
For the full drift detection algorithm, calibration thresholds, and alert structure, see Drift Detection.
Enforcement modes per agent
Each agent in your fleet can have its own enforcement mode, controlling how the gateway responds when violations are detected. The three modes are:
Set enforcement mode per agent by updating the alignment card’s top-level
integrity_mode / autonomy_mode fields. These are master switches on the alignment card; the legacy per-agent /enforcement endpoint was retired 2026-05-14. The pattern is the standard alignment-card read-modify-write flow — see Card Management.
mnemom card edit --agent "$agent" opens that agent’s alignment card in $EDITOR for an interactive change — fine for a one-off, but there is no --set flag for non-interactive field edits. To flip the master switches across a fleet, script the read-modify-write flow with card show + card publish (or the API PUT). For example, using yq to patch the YAML in place:
- Production agents on
enforce— violations are blocked before reaching end users. - Staging agents on
observe— violations are recorded for review during testing without blocking development workflows. - New agents on
nudge— the agent gets feedback and a chance to self-correct while you build confidence in its alignment.
API-based registration
In addition to CLI-based setup, you can register and manage agents programmatically via the CRUD API. This is useful for automated fleet provisioning, CI/CD pipelines, and dynamic agent lifecycle management.
When registering an agent, you must provide a
hash_proof — the SHA-256 hex digest of your API key combined with the agent name (SHA256(apiKey + '|' + agentName)). This proves ownership of the API key without transmitting it. See Agent Identity § Registration for the canonical formula, the auto-create vs programmatic paths, and the legacy claim/link flow.
agent_hash (the gateway-computed identity) and card_id (the default alignment card attached on registration). If an agent with the same hash already exists, the API returns 409 Conflict.
To customize the card post-registration, publish a unified alignment card with PUT /v1/alignment/agent/{agent_id} — see the card management guide for the full flow. Policy (capability mappings + enforcement rules) is now embedded in the alignment card’s capabilities and enforcement sections; there is no separate policy_yaml field.
DELETE /v1/agents/:id is a GDPR Art. 17 deletion. The API responds 202 Accepted immediately with a deletion_request_id; the server then cascades through traces, checkpoints, drift alerts, reclassifications, and other agent-owned records asynchronously. Poll /v1/agents/{id}/deletion-status or subscribe to the deletion webhook to know when the cascade completes.Next steps
AAP Quickstart
Create your first Alignment Card, generate a traced decision, and verify it in 5 minutes.
Enforcement Modes
Deep dive into observe, nudge, and enforce modes with streaming behavior and configuration options.
API Reference
Full API reference for agents, traces, coherence checks, drift detection, and enforcement.