M3 Core Vocabulary

The four clusters of Stage 3. Source: the Agentic Operations Knowledge Map. Sister sheets: M1 · M2 · M4.

The M3 gate: you can architect multi-agent systems, diagnose failure modes from traces, and stand up evaluation and observability that catch regressions before users do. Arc signal: debug a failing agent from traces alone; build an eval suite that catches a planted regression.

Cluster A — Agent architectures

Single-agent: One loop, one context. Simplest, easiest to debug — the best default.
Multi-agent: Multiple specialized agents collaborating. More capability, more coordination cost.
Orchestrator / subagent: A lead agent decomposes work and delegates to focused subagents with isolated context windows. Why it matters: context isolation is the main reason to go multi-agent, not "more brains." Real-world account: Anthropic's multi-agent research system.
The architecture intuition ⚠️: Most teams reach for multi-agent too early — added agents multiply failure surface and cost. Justify every extra agent.

Cluster B — State & run lifecycle

Agent state: The full picture of a run: goal, history, memory, pending tools.
Run lifecycle: Start → plan → act → observe → loop → terminate — plus retries, timeouts, and stop conditions.
Durability: Checkpointing and resuming long runs — the problem workflow runtimes like Temporal exist to solve. See durable execution meets AI. Vernant's own pipeline runs on Temporal — you operate this daily.

Cluster C — Failure modes & self-correction

Common failure modes: Hallucination, looping, context overflow, tool misuse, goal drift, silent partial failure.
Self-correction: Reflection, verification steps, and critic/validator patterns.
The failure intuition ⚠️: Agents fail silently and confidently — the dangerous failures are the plausible-looking wrong answers, not the crashes.

Cluster D — Observability & evaluation

Tracing: Capturing the full step-by-step trajectory of a run for inspection — every LLM call, tool invocation, and retrieval step. Tooling exists for this (Langfuse, Arize, Opik) — the point is the discipline, not the vendor.
Evals: Trajectory-level and outcome-level scoring — not just final-answer accuracy. Agents must be judged on how they got there. Practitioner canon: Your AI Product Needs Evals (Husain).
LLM-as-judge & human-in-the-loop scoring: Automated judging scales, but the metrics need continuous human recalibration — measure the judge's agreement with humans before trusting it. How: Using LLM-as-a-Judge (Husain).

The three critical intuitions

You debug agents by reading traces, not by staring at prompts. Observability is a prerequisite, not a nice-to-have.
⚠️ Eval on trajectories, not just outcomes. A right answer via a broken path will break at scale.
Every architecture decision is a context-management decision in disguise. (M1's lesson, at system scale.)

The three M3 exercises

Build an orchestrator with 2–3 subagents and prove (with traces) it beats a single agent on a decomposable task — or admit it doesn't.
Instrument an agent with full tracing and build an eval set that catches a regression you deliberately introduce.
Add a critic/verifier step and measure the reduction in silent wrong answers.