{ "slug": "circuit-breakers-and-degraded-mode-for-ai-agents", "title": "How to Design a Circuit Breaker for AI Agents", "description": "A deep-dive on the circuit breaker pattern for AI agents: the Closed/Open/Half-Open state machine with a worked open-source example, where to place a breaker in an agent's call path, and degraded-mode fallback design as its own discipline per dependency type.", "kind": "sub", "order": 10, "target_query": "circuit breaker pattern for AI agents", "secondary_queries": [ "circuit breaker state machine closed open half-open", "degraded mode fallback design AI agent", "circuit breaker failure threshold cooldown", "AI agent tool outage fallback", "half-open probe request circuit breaker" ], "tags": [ "agents", "reliability", "circuit-breaker", "degraded-mode", "production", "resilience" ], "published": "2026-08-30", "updated": "2026-08-30", "words": 1592, "estimated_tokens": 2117, "premium": false, "rights": { "access": "free", "note": "Editorial guides are always free and never part of the licensed corpus.", "license": "https://changegamer.ai/license.xml", "pricing": "https://changegamer.ai/api/pricing.json", "payment": "https://changegamer.ai/api/payment.json" }, "license": "https://changegamer.ai/license.xml", "citation": "ChangeGamer (2026-08-30). How to Design a Circuit Breaker for AI Agents. ChangeGamer. https://changegamer.ai/articles/circuit-breakers-and-degraded-mode-for-ai-agents (updated 2026-08-30).", "bibtex": "@misc{changegamer_circuit_breakers_and_degraded_mode_for_ai_agents, title = {How to Design a Circuit Breaker for AI Agents}, publisher = {ChangeGamer}, year = {2026}, url = {https://changegamer.ai/articles/circuit-breakers-and-degraded-mode-for-ai-agents}, note = {Updated 2026-08-30}}", "canonical": "https://changegamer.ai/articles/circuit-breakers-and-degraded-mode-for-ai-agents", "markdown": "https://changegamer.ai/articles/circuit-breakers-and-degraded-mode-for-ai-agents.md", "takeaways": [ "A circuit breaker for an AI agent is a three-state machine — Closed, Open, and Half-Open — built to stop a caller from repeatedly retrying a dependency that has already shown a sustained pattern of failure.", "The Closed state lets every request through while tracking outcomes, the Open state rejects every request immediately without attempting the downstream call, and the Half-Open state lets a small number of probe requests through after a cooldown timer expires to test whether the dependency has recovered.", "One open-source AWS CDK Patterns implementation of a Lambda circuit breaker configures a failure threshold of 3 consecutive failures, a success threshold of 2 consecutive probes, and a 10-second per-call timeout, as of August 2026 — an illustrative worked example from a single implementation, not a universal default.", "Degraded-mode fallback design means deciding in advance, per dependency type, what an acceptable reduced-quality response looks like when that dependency becomes unavailable, rather than improvising a response for the first time during a live incident.", "An AI gateway's provider-failover routing strategy — automatically retrying an unresponsive primary model provider on a secondary provider after a 5xx or timeout — is a documented degraded-mode mechanism already in production use as of August 2026.", "A circuit breaker's internal state-machine mechanics, the retry-and-backoff logic that precedes it, and the incident-response runbook that triggers it are three distinct disciplines, each answering a different question about how an agent behaves under dependency failure." ], "outline": [ { "depth": 2, "text": "What is the circuit breaker pattern for an AI agent?", "anchor": "what-is-the-circuit-breaker-pattern-for-an-ai-agent", "url": "https://changegamer.ai/articles/circuit-breakers-and-degraded-mode-for-ai-agents#what-is-the-circuit-breaker-pattern-for-an-ai-agent" }, { "depth": 2, "text": "The three-state circuit breaker state machine", "anchor": "the-three-state-circuit-breaker-state-machine", "url": "https://changegamer.ai/articles/circuit-breakers-and-degraded-mode-for-ai-agents#the-three-state-circuit-breaker-state-machine" }, { "depth": 3, "text": "A worked example, from one open-source implementation", "anchor": "a-worked-example-from-one-open-source-implementation", "url": "https://changegamer.ai/articles/circuit-breakers-and-degraded-mode-for-ai-agents#a-worked-example-from-one-open-source-implementation" }, { "depth": 2, "text": "Where should a circuit breaker sit in an agent's call path?", "anchor": "where-should-a-circuit-breaker-sit-in-an-agent-s-call-path", "url": "https://changegamer.ai/articles/circuit-breakers-and-degraded-mode-for-ai-agents#where-should-a-circuit-breaker-sit-in-an-agent-s-call-path" }, { "depth": 2, "text": "Why does degraded mode have to be designed before an incident, not during one?", "anchor": "why-does-degraded-mode-have-to-be-designed-before-an-incident-not-during-one", "url": "https://changegamer.ai/articles/circuit-breakers-and-degraded-mode-for-ai-agents#why-does-degraded-mode-have-to-be-designed-before-an-incident-not-during-one" }, { "depth": 3, "text": "Degraded-mode design by dependency type", "anchor": "degraded-mode-design-by-dependency-type", "url": "https://changegamer.ai/articles/circuit-breakers-and-degraded-mode-for-ai-agents#degraded-mode-design-by-dependency-type" }, { "depth": 2, "text": "How does a circuit breaker fit alongside retries and incident response?", "anchor": "how-does-a-circuit-breaker-fit-alongside-retries-and-incident-response", "url": "https://changegamer.ai/articles/circuit-breakers-and-degraded-mode-for-ai-agents#how-does-a-circuit-breaker-fit-alongside-retries-and-incident-response" }, { "depth": 2, "text": "Where this leaves you", "anchor": "where-this-leaves-you", "url": "https://changegamer.ai/articles/circuit-breakers-and-degraded-mode-for-ai-agents#where-this-leaves-you" } ], "faq": [ { "question": "What are the three states of a circuit breaker?", "answer": "A circuit breaker's three states are Closed, where the breaker operates normally and lets every request through while monitoring outcomes; Open, where the breaker has tripped and rejects every request immediately — with an error or a fallback response — without attempting the downstream call at all; and Half-Open, where a limited number of probe requests are let through after the open-state cooldown timer expires, closing the breaker again on success or returning it to Open on failure." }, { "question": "Who invented the circuit breaker pattern?", "answer": "The circuit breaker pattern is widely attributed to Michael Nygard's book \"Release It!\", though that specific attribution is widely repeated across software-architecture writing rather than independently verified against a primary source, and the pattern itself has since been implemented and popularized across many production systems, cloud platforms, and open-source libraries independent of its origin." }, { "question": "What failure threshold should a circuit breaker use?", "answer": "No universal failure threshold exists for a circuit breaker, because the right number depends on the specific dependency's own failure and latency profile rather than a value that transfers between systems; one illustrative open-source example, the AWS CDK Patterns \"lambda circuit breaker,\" configures a threshold of 3 consecutive failures before opening and 2 consecutive successful probes before closing again as of August 2026, but a slower or more expensive dependency may warrant a lower threshold and a cheap, flaky one a higher one." }, { "question": "What is degraded mode for an AI agent?", "answer": "Degraded mode for an AI agent is a pre-designed fallback behavior that activates once a circuit breaker trips on a specific dependency, serving a reduced-but-usable response — such as results from a secondary model provider or an unranked retrieval result — instead of failing the entire request or continuing to retry a dependency that has already demonstrated it is unavailable." } ], "body": "The [agent reliability in production](/articles/agent-reliability-in-production) pillar names circuit breakers and degraded mode in one paragraph and gives two illustrative examples. This article expands both halves of that paragraph into their own disciplines: the circuit breaker's internal state machine, using a real, citable worked example rather than an invented number, and degraded-mode fallback design as a decision made per dependency type before an incident happens, not during one.\n\n## What is the circuit breaker pattern for an AI agent?\n\nThe circuit breaker pattern is a safeguard that stops an agent from continuing to hammer a dependency that has already demonstrated it is down, converting an open-ended stall into an immediate, predictable failure instead. It works on a longer time horizon than ordinary retry logic: a retry loop assumes the very next attempt still has a real chance of landing, while a circuit breaker assumes the opposite once its threshold is crossed — that the dependency needs a recovery window with no additional load, and that every request sent during that window wastes the caller's time at best and adds strain to an already-struggling service at worst. The mechanics of that earlier retry layer — transient-versus-terminal classification, exponential backoff with full jitter, idempotency keys for a retried side effect — are their own discipline and are not re-derived here; see [how to make AI agent retries idempotent](/articles/retries-and-idempotency-for-ai-agents) for that mechanism in full.\n\n## The three-state circuit breaker state machine\n\nA circuit breaker for an agent operates as a state machine with exactly three states — Closed, Open, and Half-Open — moving between them based on the outcomes of the calls it observes. This three-state design is widely attributed to Michael Nygard's book \"Release It!\" and popularized broadly in software-architecture writing since, though that specific attribution is itself widely repeated rather than independently verified against a primary source this session.\n\n- **Closed** is the normal operating state: every request is let through to the dependency, and the breaker silently tracks the outcome of each call — success or failure — against its configured threshold.\n- **Open** is the tripped state: once the failure threshold is crossed, the breaker stops sending requests to the dependency entirely and rejects every call immediately — either with an explicit error or a fallback response — without attempting the real downstream call at all, for the duration of a cooldown period.\n- **Half-Open** is the recovery-testing state: once the open-state cooldown timer expires, the breaker lets a small, limited number of probe requests through to check whether the dependency has actually recovered. If those probes succeed, the breaker resets to Closed and resumes normal traffic; if they fail, it returns to Open and starts the cooldown again.\n\nThis three-state design is what separates a circuit breaker from a simple \"give up after N failures\" flag: the Half-Open state gives the system a controlled, low-risk way to detect recovery on its own, rather than requiring a human to notice the dependency is back and manually re-enable traffic to it.\n\n### A worked example, from one open-source implementation\n\nNo universal failure-threshold number, cooldown duration, or probe count exists for a circuit breaker — each dependency's own failure and latency profile should drive its own choice, and treating any single set of numbers as a default to copy elsewhere is a mistake. As of August 2026, one concrete, citable implementation of the pattern is the AWS CDK Patterns open-source repository's [\"the-lambda-circuit-breaker\" example](https://github.com/cdk-patterns/serverless/blob/main/the-lambda-circuit-breaker/README.md), which configures a `failureThreshold` of 3 consecutive failures before the breaker opens, a `successThreshold` of 2 consecutive successful probes before it closes again from Half-Open, and a 10-second per-call timeout, with a dedicated fallback function invoked in place of the real call while the breaker sits Open. Treat these three numbers as one illustrative example from a single implementation, not a prescription: a dependency behind a slow, expensive downstream call might reasonably open after a single failure, while a cheap, flaky one might tolerate ten before tripping — the right values come from that dependency's own observed behavior, not from a table of defaults.\n\n## Where should a circuit breaker sit in an agent's call path?\n\nA circuit breaker belongs wrapped tightly around the specific call to one dependency — one tool endpoint, one model provider, one retrieval index — rather than wrapped around an entire multi-step agent run, because its failure count only means something if it tracks one dependency's behavior in isolation. A breaker that blends failures from several unrelated calls into one counter trips for the wrong reason and recovers at the wrong time: a spike of failures from one flaky tool would needlessly cut off traffic to an unrelated, healthy model provider sharing the same counter. Each dependency an agent calls — each distinct tool, each model provider, each retrieval backend — gets its own breaker instance with its own threshold, cooldown, and state, sized to that dependency's own latency and failure characteristics rather than a value shared across the whole system.\n\n## Why does degraded mode have to be designed before an incident, not during one?\n\nDegraded mode has to be designed before an incident because deciding, for the first time, what an agent should say or do when a dependency is unreachable is a design decision, not a triage action, and an on-call responder mid-incident has neither the time nor the full context to make that decision safely under pressure. Degraded mode is the specific fallback behavior a tripped circuit breaker routes traffic into: instead of the caller simply receiving an error, the agent serves a pre-defined, reduced-but-usable response. Designing it in advance means answering, per dependency, how much quality reduction is acceptable and how it gets disclosed before that dependency ever actually fails — a decision with product, correctness, and disclosure implications that belong in a design review, not in a Slack thread during an outage.\n\n### Degraded-mode design by dependency type\n\nThe table below works through a reasonable fallback for three dependency types an agent commonly relies on — one grounded in a documented, corpus-verified mechanism, and two reasoned from how those systems are architected rather than from an observed or documented practice:\n\n| Dependency | What \"unavailable\" looks like | Reasoned degraded-mode fallback | Grounding |\n|---|---|---|---|\n| Primary model provider | 5xx errors or timeouts from the preferred provider | An AI gateway automatically retries the call on one or more fallback providers instead of failing the request | Documented: [AI gateways and LLM routing](/resources/ai-gateways-llm-routing) names \"provider failover — primary provider first; on error (5xx, timeout) automatically retry on one or more fallback providers\" as a standard gateway routing strategy, current as of August 2026 |\n| Retrieval index | The primary index is unreachable or times out | Return the most recent successfully cached result, or narrow the query to whatever smaller, already-loaded slice of the index remains reachable, and mark the response as reduced-confidence rather than presenting it as complete | Reasoned inference — no dedicated corpus resource documents this as an observed practice; treat it as an architectural default worth designing, not a cited pattern |\n| Reranking stage | The reranker service is down or times out | Serve the first-stage retrieval results directly, unranked, rather than blocking the whole response on a stage that is optional by design | Reasoned inference from [RAG and retrieval for agents](/resources/rag-retrieval-for-agents), which documents reranking as an optional second stage layered on top of first-stage retrieval — because that stage is optional architecturally, a system can reasonably serve first-stage results directly when it is unavailable, though no corpus source documents this specific fallback as observed practice |\n\nThe pattern across all three: each fallback keeps the agent answering rather than failing outright, and each one accepts a specific, bounded quality reduction instead of an unbounded one — a stale cache instead of nothing, an unranked list instead of nothing, a slower or different model instead of nothing.\n\n## How does a circuit breaker fit alongside retries and incident response?\n\nA circuit breaker sits between an agent's retry logic and its incident-response process, handling the layer neither of the other two owns. Retry-and-backoff logic decides what to do about a single failing call and is not re-derived here — see [how to make AI agent retries idempotent](/articles/retries-and-idempotency-for-ai-agents) for that mechanism. Incident-response runbooks decide what a team does once an outage is confirmed, naming \"trip a circuit breaker so the agent switches to its pre-defined degraded mode\" as the first response to a tool or dependency outage without covering the breaker's own internal mechanics — see [how to build an incident response runbook for AI agent failures](/articles/agent-incident-response-runbooks) for that triage and response layer. This article is the layer in between: the state machine that decides, mechanically and without human intervention, when to stop calling a dependency and when to try it again. The full ten-dimension production ship gate this discipline sits inside, including cost controls and rollback, is in [shipping AI agents to production](/resources/shipping-agents-to-production).\n\n## Where this leaves you\n\nBuild one circuit breaker per dependency — not one per agent run — sized with a failure threshold, a cooldown duration, and a half-open probe count drawn from that specific dependency's own failure and latency profile rather than copied from any single example, worked or otherwise. Design degraded mode for each dependency type ahead of time, deciding what a reduced-but-honest response looks like before the dependency ever actually fails, and disclose the reduction rather than hiding it. For the other eleven reliability disciplines this one sits inside, see the [agent reliability in production](/articles/agent-reliability-in-production) pillar.", "cluster": { "id": "agent-reliability", "title": "Agent reliability in production", "description": "How to make an AI agent reliable — tool-calling contracts, structured outputs, retries and idempotency, timeouts, durable execution, guardrails, evaluation in CI, observability, incident response, and rollout.", "status": "complete", "pillar": { "slug": "agent-reliability-in-production", "title": "Agent Guardrails and the AI Agent Reliability Playbook", "description": "Agent guardrails plus the eleven other disciplines that make an AI agent reliable in production: tool calling, retries, durable execution and rollout.", "kind": "pillar", "order": 0, "html": "https://changegamer.ai/articles/agent-reliability-in-production", "markdown": "https://changegamer.ai/articles/agent-reliability-in-production.md", "json": "https://changegamer.ai/api/articles/agent-reliability-in-production.json" }, "articles": [ { "slug": "tool-calling-contracts-for-ai-agents", "title": "How to Make AI Agent Tool Calling Reliable", "description": "An operator playbook for tool-calling contracts: per-provider strict-mode config (OpenAI, Anthropic, Gemini, self-hosted grammars), the full failure-mode-to-fix table, what BFCL actually measures, and how to stop parallel tool calls from breaking a dependency chain.", "kind": "sub", "order": 1, "html": "https://changegamer.ai/articles/tool-calling-contracts-for-ai-agents", "markdown": "https://changegamer.ai/articles/tool-calling-contracts-for-ai-agents.md", "json": "https://changegamer.ai/api/articles/tool-calling-contracts-for-ai-agents.json" }, { "slug": "structured-outputs-vs-tool-calling", "title": "Structured Outputs vs Tool Calling: When to Use Each", "description": "A decision framework for structured outputs versus tool calling in AI agents, with runnable JSON Schema examples for OpenAI, Anthropic, Gemini, vLLM/SGLang, and llama.cpp, plus mitigation code for truncation, refusal, and grammar-compilation latency.", "kind": "sub", "order": 2, "html": "https://changegamer.ai/articles/structured-outputs-vs-tool-calling", "markdown": "https://changegamer.ai/articles/structured-outputs-vs-tool-calling.md", "json": "https://changegamer.ai/api/articles/structured-outputs-vs-tool-calling.json" }, { "slug": "retries-and-idempotency-for-ai-agents", "title": "How to Make AI Agent Retries Idempotent", "description": "A deep-dive on retrying agent tool calls safely: the transient-vs-terminal decision, why an agent side effect can fire before a failure signal reaches the caller, idempotency-key mechanics (run ID + step index), the unknown-outcome edge case, and where idempotency keys do not reach.", "kind": "sub", "order": 3, "html": "https://changegamer.ai/articles/retries-and-idempotency-for-ai-agents", "markdown": "https://changegamer.ai/articles/retries-and-idempotency-for-ai-agents.md", "json": "https://changegamer.ai/api/articles/retries-and-idempotency-for-ai-agents.json" }, { "slug": "durable-execution-for-ai-agents", "title": "When Do AI Agents Need Durable Execution?", "description": "A deep-dive on durable execution for AI agents: the persisted event log, the replay-determinism constraint, the four architectural shapes mapped across ten engines and frameworks, and a decision framework for when a durable execution engine is worth adding at all.", "kind": "sub", "order": 4, "html": "https://changegamer.ai/articles/durable-execution-for-ai-agents", "markdown": "https://changegamer.ai/articles/durable-execution-for-ai-agents.md", "json": "https://changegamer.ai/api/articles/durable-execution-for-ai-agents.json" }, { "slug": "agent-guardrails-for-reliability", "title": "How to Design Guardrails for AI Agent Reliability", "description": "An operator playbook for reliability guardrails: the three checkpoints (input, output, action), layering cheap checks under slow ones with a fail-closed default, the two-of-three-properties rule for when a tool call needs human approval, and logging every verdict against the run trace ID.", "kind": "sub", "order": 5, "html": "https://changegamer.ai/articles/agent-guardrails-for-reliability", "markdown": "https://changegamer.ai/articles/agent-guardrails-for-reliability.md", "json": "https://changegamer.ai/api/articles/agent-guardrails-for-reliability.json" }, { "slug": "evaluating-ai-agents-in-ci", "title": "How to Evaluate AI Agents in CI", "description": "An operator playbook for gating an AI agent release in CI: why agent eval needs trajectory-level scoring across the tasks it actually runs, how public benchmarks diverge as proxies, ground-truth vs LLM-as-judge tool-call scoring, and the three-layer test pyramid that keeps CI fast and non-flaky.", "kind": "sub", "order": 6, "html": "https://changegamer.ai/articles/evaluating-ai-agents-in-ci", "markdown": "https://changegamer.ai/articles/evaluating-ai-agents-in-ci.md", "json": "https://changegamer.ai/api/articles/evaluating-ai-agents-in-ci.json" }, { "slug": "agent-rollout-and-rollback", "title": "How to Roll Out a New AI Agent Version Safely", "description": "An operator playbook for shipping a new agent version without breaking production: in-repo vs. registry prompt storage, a version-numbering comparison, the six-step promotion flow, A/B-test mechanics, the composite-version trace fields, and a rollback drill.", "kind": "sub", "order": 7, "html": "https://changegamer.ai/articles/agent-rollout-and-rollback", "markdown": "https://changegamer.ai/articles/agent-rollout-and-rollback.md", "json": "https://changegamer.ai/api/articles/agent-rollout-and-rollback.json" }, { "slug": "agent-incident-response-runbooks", "title": "How to Build an Incident Response Runbook for AI Agent Failures", "description": "An operator playbook for the moment an AI agent fails in production: a triage step to classify the failure fast, trace freezing before rollback destroys the evidence, first-response depth on the four failure classes, and a blameless post-mortem that feeds back into guardrails and eval.", "kind": "sub", "order": 8, "html": "https://changegamer.ai/articles/agent-incident-response-runbooks", "markdown": "https://changegamer.ai/articles/agent-incident-response-runbooks.md", "json": "https://changegamer.ai/api/articles/agent-incident-response-runbooks.json" }, { "slug": "timeouts-and-deadlines-for-ai-agents", "title": "How to Set Timeouts for AI Agent Tool Calls", "description": "A deep-dive on timeout and deadline design for AI agents: sizing LLM-call, tool-call, and sub-agent-hop timeouts differently, allocating a wall-clock budget across a multi-step chain, and propagating a remaining-deadline value from parent to child calls.", "kind": "sub", "order": 9, "html": "https://changegamer.ai/articles/timeouts-and-deadlines-for-ai-agents", "markdown": "https://changegamer.ai/articles/timeouts-and-deadlines-for-ai-agents.md", "json": "https://changegamer.ai/api/articles/timeouts-and-deadlines-for-ai-agents.json" }, { "slug": "circuit-breakers-and-degraded-mode-for-ai-agents", "title": "How to Design a Circuit Breaker for AI Agents", "description": "A deep-dive on the circuit breaker pattern for AI agents: the Closed/Open/Half-Open state machine with a worked open-source example, where to place a breaker in an agent's call path, and degraded-mode fallback design as its own discipline per dependency type.", "kind": "sub", "order": 10, "html": "https://changegamer.ai/articles/circuit-breakers-and-degraded-mode-for-ai-agents", "markdown": "https://changegamer.ai/articles/circuit-breakers-and-degraded-mode-for-ai-agents.md", "json": "https://changegamer.ai/api/articles/circuit-breakers-and-degraded-mode-for-ai-agents.json" }, { "slug": "agent-observability-for-reliability", "title": "What Should an AI Agent's Observability System Capture?", "description": "An operator playbook for instrumenting an AI agent: the trace/span model behind a run, the OpenTelemetry GenAI attributes that name each field, the fields worth capturing per span, and what to redact before any of it gets logged.", "kind": "sub", "order": 11, "html": "https://changegamer.ai/articles/agent-observability-for-reliability", "markdown": "https://changegamer.ai/articles/agent-observability-for-reliability.md", "json": "https://changegamer.ai/api/articles/agent-observability-for-reliability.json" }, { "slug": "agent-reliability-production-checklist", "title": "The AI Agent Production Reliability Checklist", "description": "A go/no-go checklist that turns the agent reliability pillar's twelve-discipline closing list into checkable gates — the specific artifact, header, or trace field that proves each one holds, with a link to whichever sibling article owns its mechanics.", "kind": "sub", "order": 12, "html": "https://changegamer.ai/articles/agent-reliability-production-checklist", "markdown": "https://changegamer.ai/articles/agent-reliability-production-checklist.md", "json": "https://changegamer.ai/api/articles/agent-reliability-production-checklist.json" } ] }, "navigation": { "pillar": { "slug": "agent-reliability-in-production", "title": "Agent Guardrails and the AI Agent Reliability Playbook", "description": "Agent guardrails plus the eleven other disciplines that make an AI agent reliable in production: tool calling, retries, durable execution and rollout.", "kind": "pillar", "order": 0, "html": "https://changegamer.ai/articles/agent-reliability-in-production", "markdown": "https://changegamer.ai/articles/agent-reliability-in-production.md", "json": "https://changegamer.ai/api/articles/agent-reliability-in-production.json" }, "previous": { "slug": "timeouts-and-deadlines-for-ai-agents", "title": "How to Set Timeouts for AI Agent Tool Calls", "description": "A deep-dive on timeout and deadline design for AI agents: sizing LLM-call, tool-call, and sub-agent-hop timeouts differently, allocating a wall-clock budget across a multi-step chain, and propagating a remaining-deadline value from parent to child calls.", "kind": "sub", "order": 9, "html": "https://changegamer.ai/articles/timeouts-and-deadlines-for-ai-agents", "markdown": "https://changegamer.ai/articles/timeouts-and-deadlines-for-ai-agents.md", "json": "https://changegamer.ai/api/articles/timeouts-and-deadlines-for-ai-agents.json" }, "next": { "slug": "agent-observability-for-reliability", "title": "What Should an AI Agent's Observability System Capture?", "description": "An operator playbook for instrumenting an AI agent: the trace/span model behind a run, the OpenTelemetry GenAI attributes that name each field, the fields worth capturing per span, and what to redact before any of it gets logged.", "kind": "sub", "order": 11, "html": "https://changegamer.ai/articles/agent-observability-for-reliability", "markdown": "https://changegamer.ai/articles/agent-observability-for-reliability.md", "json": "https://changegamer.ai/api/articles/agent-observability-for-reliability.json" } }, "resources": [ { "slug": "ai-gateways-llm-routing", "html": "https://changegamer.ai/resources/ai-gateways-llm-routing", "markdown": "https://changegamer.ai/resources/ai-gateways-llm-routing.md", "json": "https://changegamer.ai/api/resources/ai-gateways-llm-routing.json" }, { "slug": "rag-retrieval-for-agents", "html": "https://changegamer.ai/resources/rag-retrieval-for-agents", "markdown": "https://changegamer.ai/resources/rag-retrieval-for-agents.md", "json": "https://changegamer.ai/api/resources/rag-retrieval-for-agents.json" }, { "slug": "shipping-agents-to-production", "html": "https://changegamer.ai/resources/shipping-agents-to-production", "markdown": "https://changegamer.ai/resources/shipping-agents-to-production.md", "json": "https://changegamer.ai/api/resources/shipping-agents-to-production.json" } ] }