GAP-02 · Agent architecture

Agent Failure and Recovery Inspector

Inspect the failure, the signal that detects it and the policy that recovers.

Current decision

Inspect the complete happy-path trace

No failure is injected. Choose a failure to inspect its detection and recovery policy.

Trace events: 9
Selected event: Not started

Same instrument · 3 industries choosing a scenario replaces its inputs; save or share your current changes first

Prefer to read? The two minute case study · problem → approach → metric → outcome

Problem

Enterprise teams often discuss agents as if autonomy is the main decision. The more important decision is whether the organization has the harness required to observe, interrupt, retry, escalate, or roll back agent behavior when it drifts.

Approach

The inspector steps through single agent, orchestrator worker, and evaluator optimizer patterns. For each architecture, it shows how specific failures are detected, what recovery policy applies, and what latency or operational overhead the control introduces.

Why this way

This connects agent architecture to reliability, control cost, incident exposure, and the support model required to operate autonomous workflows safely.

The metric

Failure classes caught vs escaped; harness coverage of the taxonomy.

The trade-off

A richer harness costs money and latency; an un instrumented failure reaches a system of record.

Outcome

A defensible observability harness budget tied to the failure modes that actually occur.

Architecture

Inject failure

SpeedStatic view · 0/9 steps

Choose a step

Press Play explanation or Step to inspect the authored trace. No tool is executed.

The harness you budget for

Tool error
non-2xx / timeout → retry + fallback
Loop
repeated action ≥3 → cap + escalate
Hallucinated args
schema validation → reject + re-ask
Context overflow
token budget → summarize + evict

Every one needs a detection signal and a recovery policy. That's the observability line item.

Read the full trace without playback

Complete authored trace
Event	Type	Explanation
1	thought	I need the dispute details first.
2	action	get_dispute("DSP-48213")
3	observation	status=under_review · amount=$214.50
4	thought	Check the chargeback policy for this reason code.
5	action	read_resource("disputes://policy/chargeback")
6	observation	reason 'not_recognized' → issuer review, 30-day SLA
7	action	open_dispute(account="ACCT-0021", amount=214.50, reason="not_recognized")
8	observation	dispute_id=DSP-48999 opened
9	final	Dispute filed; member notified. Done in one linear loop.

If you act on this · the call → expected lift → how you'd measure it

The call

Size the observability and recovery harness to the actual failure modes of the chosen architecture.

Expected lift · illustrative

Reduces uncontrolled agent behavior by pairing each failure mode with a detection signal and recovery policy.

How you'd measure it

Failure detection time, recovery success rate, escalation rate, repeat failure rate, incident cost.

Failure injection is the whole point

A happy-path demo tells you nothing about production. The four failures above are what actually happen, and each is cheap to catch with the right signal and expensive to miss. That gap is the observability budget.

Steering committee takeaway: Do not budget for agents alone. Budget for agents plus the operating harness that detects failures, recovers safely, and knows when to involve a human.

How this is built

Each architecture defines a base Thought→Action→Observation trace; a selected failure splices a failure→detection→recovery triad into the loop. The stepper reveals steps in order.

Stack: Next.js (static) + shared design system; deterministic client side.

Limitations: this artifact models representative failure paths. A production environment would require live traces, tool telemetry, policy enforcement, alert routing, and incident management integration.