← Work

Agent architecture review

A focused, written assessment of an existing or proposed agent system: where it is likely to fail in production, what evidence supports that conclusion, and which changes reduce the most risk first.

The review is built around a production decision, not a generic best-practice checklist. Should this system move from prototype to pilot? Can this workflow take real actions without creating an unbounded failure path? What must change before autonomy, traffic, or data access expands? The answer is delivered in days once the evidence is available, not after months of documentation theatre.

When this is useful

• You have a credible prototype, but the path to production is unclear.
• An agent already runs in production, but failures are difficult to reconstruct, contain, or learn from.
• The architecture has accumulated models, tools, retrieval, memory, and orchestration without a clear trust or operating model.
• A consequential design decision — autonomy, memory, multi-tenancy, tool access, evaluation, or durable execution — needs an independent technical challenge.
• Leadership needs a defensible production decision while engineering needs concrete next actions.

It is not a substitute for a penetration test, compliance audit, load test, or line-by-line code review. Where one of those is needed, the assessment should say so rather than imply coverage it did not perform.

What I review

The review follows the system's real trajectory — from user intent and context assembly through model decisions, retrieval, tools, state changes, human approvals, external effects, telemetry, and recovery. It examines the seams where agent systems tend to become unsafe or unmanageable:

• Purpose, authority, and autonomy: what the system may decide or do, for whom, and where approval is required.
• Execution and tools: termination, retries, idempotency, checkpoints, cancellation, tool contracts, and external effects.
• Context, data, state, and memory: provenance, freshness, typing, scope, tenancy, versioning, and forgetting.
• Models and control plane: routing, fallback, configuration, structured outputs, budgets, and change traceability.
• Evaluation and observability: production-shaped scenarios, replay, release evidence, drift, cost, and trajectory reconstruction.
• Security, privacy, and governance: identity, authorization, trust boundaries, untrusted content, egress, audit, and retention.
• Reliability and operations: degraded dependencies, blast radius, exception queues, recovery, rollback, and ownership.

How the review works

1. Frame the decision. We name the system, lifecycle stage, intended operating conditions, consequential actions, review question, and exclusions. “Is the architecture good?” is not a useful scope; “can this claims workflow enter a supervised production pilot?” is.
2. Inspect the evidence. I review the architecture, contracts, data and memory model, evals, traces, incidents, deployment and operating material you already have. Every material conclusion is marked as verified, asserted, inferred, or unknown.
3. Trace critical trajectories. We walk a representative run and a consequential, exceptional, or failed run end to end. This exposes differences between the architecture as described and the architecture as it actually behaves.
4. Model and challenge failure paths. Findings are written as causal chains: the condition, trigger, failure, consequence, missing control, detection signal, and recovery path. Small, non-destructive probes may be used where one unresolved question could change the verdict.
5. Prioritize the path forward. Recommendations are sequenced: first contain unbounded effects; then make the system observable and recoverable; then improve capability, autonomy, scale, or economics.

View the review workflow → See the stages, inputs, outputs, and decision gates as one operating sequence.

Download the architecture review process presentation → A 10-slide visual walkthrough of the review workflow.

What you receive

• Executive verdict: proceed, proceed with conditions, do not expand yet, or insufficient evidence — tied to the exact production decision.
• As-evidenced architecture: the critical trajectories, trust boundaries, state and data flows, and material differences from the team's stated model.
• Failure-mode analysis: the few causal paths that dominate production risk, including existing controls and their limits.
• Prioritized findings: severity and confidence kept separate, so a dangerous unknown becomes an urgent test rather than a falsely precise score.
• Sequenced remediation register: immediate containment, structural changes, dependencies, owner roles, effort bands, and acceptance evidence.
• Handoff session: a working review of the evidence, trade-offs, disagreements, and next decisions with the people who will own the system.

The recommendation is expressed as a required capability, not a vendor shopping list. “Add guardrails” is not a recommendation. “Reject a duplicated external write under a deterministic idempotency test, and preserve the result in the correlated run record” is.

What I need from your team

I ask for existing material, not newly polished documents: an architecture view; one representative run; one difficult or high-consequence run; tool and data contracts; state or memory schemas; available eval and telemetry evidence; deployment and recovery material; and access to the technical and operating owners for a focused working session. Do not send secrets or unrestricted production data by ordinary email.

Timing and scope

A tightly scoped review normally takes three to four working days after the evidence pack is ready: intake and architecture working session, analysis and focused follow-ups, written assessment, then handoff. Multi-agent, regulated, multi-tenant, or very broad systems may need a longer review — or, usually better, a narrower decision boundary.

The method is deliberately bounded. The goal is not to inspect everything. It is to leave the team able to answer five questions: which failures can materially harm production use; what evidence supports that conclusion; which changes reduce the most risk first; what remains unknown; and who owns the next decision.

Considering a review? Send me what you are building, where it is stuck between demo and production, and the production decision you need to make. I will reply with a direct view on whether a focused architecture review is the right next step.