The model is not the whole agent: 10 failure modes to audit

AI-agent architecture reviews often begin with model selection. That is backwards.

The failures that matter usually emerge in the connections between context, memory, tools, permissions and side effects. A strong model can still operate inside a weak system.

Disclosure: I am building ChaseOS, a local-first workspace and control plane for governed agents.

Map the system that actually exists

Start with every model, runtime, queue, memory store, retrieval index, tool adapter, credential boundary, scheduler, approval service, provider, destination and audit sink.

For each surface, ask:

• What data can it read?
• Can it create durable state?
• Can it cause an external effect?
• Where are identity and tenant boundaries enforced?
• What retries or fallback paths exist?
• Which claims have test or live evidence?

Then label the state honestly: implemented, configured but unverified, partial, planned, blocked or retired. A diagram should not grant imaginary security to a placeholder service.

Trace the complete path

An audit should follow the whole route:

untrusted input -> normalized source -> candidate context
 -> bounded task packet -> proposal -> policy / approval
 -> effect -> observed result -> audit / governed writeback

Every transition is a trust decision. Browser content may become a summary, enter retrieval, influence a plan and appear inside a tool call. The original source and its trust state must survive those transformations.

Ten failure families

1. Input: untrusted content becomes instruction.
2. Memory: low-trust material is promoted or retrieved incorrectly.
3. Planning: required checks disappear from the generated plan.
4. Tools: schemas are ambiguous or hostile output looks successful.
5. Authority: permissions exceed the task, tenant or target.
6. Approval: the reviewed payload differs from the executed payload.
7. Execution: retries duplicate or partially apply effects.
8. Provider: fallback silently changes privacy, cost or behaviour.
9. Observation: the system cannot prove what actually happened.
10. Recovery: rollback is absent, destructive or untested.

This list includes adversarial and ordinary operational failures. Timeouts, stale caches and malformed responses can be just as damaging as deliberate prompt injection.

Separate prevention, detection and recovery

Do not credit one control three times.

• Least privilege may prevent a write.
• A digest comparison can detect payload drift.
• Idempotency can prevent duplicate effects.
• A postcondition can detect false success.
• A backup can support recovery.

An audit log explains an action after the fact. It does not prevent the action.

Demand negative evidence

Happy-path screenshots prove only that the intended route can work. Test the cases the system is expected to refuse or survive:

• wrong tenant
• expired approval
• mismatched payload digest
• missing credential
• malformed tool response
• duplicate callback
• provider loss
• attempted protected write

Record the fixture, command, environment, output, remaining risk and release decision. "The architecture looks safe" is not evidence.

How I am applying this in ChaseOS

ChaseOS separates provider, execution surface and permission scope. Runtime profiles declare ceilings; task packets narrow context; activity records preserve evidence; sensitive effects are intended to route through explicit policy and approval boundaries.

The important status boundary: enforcement is verified in some bounded lanes, while other provider and operator paths remain partial or planned. A control-plane diagram is not proof of universal enforcement.

The complete field guide, including sources and an audit evidence checklist, is here:

How to audit AI agent architecture and failure modes

What failure mode has surprised you most in a real agent system: stale context, retries, permissions, or something else?