Audit Dependency Containment in a Production Agent
Apply Advanced Agents Step 22 to determine whether one unhealthy model, browser, API, verifier or datastore can cascade across the whole agent platform.
How to use this
- Open a repository-aware AI assistant.
- Give it access to the repository or files you want reviewed.
- Copy the prompt below and run it unchanged first.
- Use the evidence it finds to decide what to inspect or change next.
PromptCopy and run against your own project
You are reviewing a production AI-agent system for dependency-failure containment.
Do not begin by recommending more retries, larger timeouts, more workers, or a different provider.
First reconstruct how dependency failure propagates through the system.
Inspect the repository and identify every material external or shared dependency used during agent execution, including where applicable:
- model providers,
- browser pools,
- retrieval/search services,
- embedding services,
- databases,
- queues,
- sandbox workers,
- verifier services,
- third-party APIs,
- shared caches,
- internal RPC services.
For each dependency, build a table containing:
1. caller / call site,
2. timeout,
3. retry policy,
4. retry ownership,
5. concurrency limit,
6. queue or worker pool used,
7. failure classification,
8. circuit-breaker behavior,
9. fallback or degradation behavior,
10. whether failure can consume capacity needed by healthy work.
Then trace at least one realistic failure path end to end:
dependency slows or fails
→ timeout
→ retry
→ queue/worker occupancy
→ upstream retry or replanning
→ additional load
→ system-wide effect
Look specifically for:
- retries at multiple layers multiplying attempts,
- no retry budget,
- identical policy for transient and permanent failures,
- unbounded queues,
- shared pools that allow one dependency to starve unrelated work,
- missing circuit breakers,
- circuit breakers without half-open recovery logic,
- fallback paths that silently weaken correctness,
- degraded modes that are not visible to verification,
- timeout values longer than the useful lifetime of the operation,
- model-driven retries that bypass system retry policy.
Classify each finding as:
- confirmed from code/config,
- strongly implied,
- requires runtime evidence.
Propose the minimum containment architecture needed. Prefer explicit retry budgets, bulkheads, bounded queues, dependency health state, circuit breakers and declared degradation over generic resilience advice.
For every recommended change, specify:
- failure mode it addresses,
- metric or experiment that would validate it,
- what behavior should occur when the dependency remains unhealthy.
Do not call the system resilient merely because retries exist. A resilient system must prevent a local dependency failure from consuming the control and execution capacity required by healthy work.