Introduction: The Failure That Demos Do Not Show
A user asks an AI agent a simple question:
“Create a procurement request for 10 laptops for the new project team.”
The agent does what it was designed to do.
It checks the procurement policy. It verifies budget availability. It calls the procurement system. The procurement system successfully creates request PR-10482.
Then the network drops.
The response from the procurement system never reaches the agent. From the agent’s perspective, the tool call timed out. It does not know whether the operation succeeded, failed, or reached the downstream system at all.
So, the agent retries.
The procurement system creates PR-10483.
The agent tells the user:
Your procurement request has been created.
That response is technically correct. A procurement request was created.
The business operation is wrong. Two requests now exist.
This is the kind of failure that does not usually appear in a demo. The model did not hallucinate. The tool was not permanently down. The final response was not obviously incorrect. The failure happened at the boundary between decision, tool call, external state, and side effect.
That boundary is where production agent engineering begins.
The core lesson is this:
For an AI agent, a failed response is not necessarily a failed operation, and a successful response is not necessarily a successful operation.
If an agent performs real work through APIs, databases, workflow systems, MCP servers, or enterprise tools, reliability cannot depend only on better prompts or smarter models. Agent reliability requires explicit failure semantics around every side-effecting tool.
Why Agent Failures Are Different
Traditional application reliability patterns still matter. Timeouts, retries, circuit breakers, observability, idempotency, and transactional state are not new ideas.
What changes with agentic AI is where those patterns must be applied.
A traditional application usually has relatively deterministic control flow. A service receives a request, validates input, calls dependencies, commits state, and returns a response. The developer owns the workflow.
An AI agent introduces a probabilistic decision layer into that workflow. The agent may decide which tool to call, when to call it, whether to call another tool, whether the answer is sufficient, and whether to retry after failure.
Microsoft Foundry Agent Service is documented as a managed platform for building, deploying, and scaling AI agents. It supports prompt agents and hosted agents. Hosted agents allow developers to bring custom code and frameworks while Foundry provides a managed endpoint, scaling, identity, and observability capabilities. See What is Microsoft Foundry Agent Service?.
That makes the reliability problem broader. A production agent can fail because:
- The model made a poor decision.
- A tool failed or timed out.
- The tool succeeded but the agent did not receive the result.
- The downstream system changed state but the agent did not know.
- The agent retried an unsafe operation.
- The user received a confident message that did not match the business outcome.
- The recovery path introduced a second failure.
A reliable agentic system must therefore reason about more than response quality. It must reason about operation state.
The Core Principle: Response Success Is Not Operation Success
In conventional chat evaluation, we often ask whether the answer was accurate, relevant, safe, and grounded.
Those questions remain important. But they are not sufficient when an agent takes action.
For production AI agents, engineers also need to ask:
- Did the intended business operation occur?
- Did it occur exactly once?
- Did the agent know whether it occurred?
- Did the agent verify uncertain state before retrying?
- Did the agent escalate when autonomous recovery was unsafe?
- Can we reconstruct what happened later?
This leads to five practical distinctions.
Model failure means the model produced a poor decision or response.
Tool failure means an external tool failed to respond, returned an error, or behaved unexpectedly.
State uncertainty means the system cannot determine whether the requested operation actually occurred.
Business failure means the technical operation succeeded, but the desired business outcome was not achieved.
Recovery failure means the system responded incorrectly to the original failure, often making the situation worse.
The procurement incident is not a simple tool failure. It is an unknown-state failure followed by a recovery failure. The timeout was not proof that the procurement request failed. It was proof that the caller did not know the outcome.
That difference matters.
A Failure Taxonomy for Agentic Systems
The table below is not a Microsoft-defined taxonomy. It is a proposed engineering taxonomy for production agentic systems.
| Failure type | Example | Recommended behavior |
|---|---|---|
| Transient timeout | Read-only API times out | Retry safely with backoff |
| Timeout after side effect | Request created but response lost | Verify state before retry |
| Duplicate action | Same business request submitted twice | Use idempotency and an action record |
| Authorization failure | User or agent lacks permission | Stop and escalate |
| Stale data | Tool returns outdated state | Re-fetch from authoritative source |
| Conflicting data | Two sources disagree | Resolve by trust hierarchy or escalate |
| Partial completion | Multi-step workflow partially succeeds | Recover, compensate, or escalate |
| Unknown state | Cannot determine whether action occurred | Verify before deciding |
| Unsafe uncertainty | Agent lacks enough evidence to act | Ask a human or ask the user |
| Tool success, business failure | API succeeds but requested outcome fails | Verify business outcome |
These failure types are different because they require different recovery behavior.
A transient read timeout can often be retried. A timeout after a write cannot be treated the same way. An authorization failure should not trigger repeated retries. Conflicting data may require a trust hierarchy, not another model call. Partial completion may require compensation, not summarization.
Agent reliability starts by naming these distinctions.
Designing Failure Semantics Around Tools
In many prototypes, a tool returns one of two outcomes:
Success or failure.
That is not enough for production systems.
A side-effecting tool should expose richer operational semantics. The agent or orchestrator needs to know whether an operation is safe to retry, whether a side effect may already have happened, whether verification is required, and whether human intervention is appropriate.
The following JSON is a conceptual example. It is not an official Microsoft Foundry API contract.
“operation_id”: “create-procurement-request”,
“idempotency_key”: “user-123:laptops:2026-08-12:normalized-request-hash”,
“correlation_id”: “trace-7f4c9a”,
“status”: “unknown”,
“side_effect_possible”: true,
“side_effect_confirmed”: false,
“retryable”: false,
“requires_verification”: true,
“business_reference”: null,
“error_type”: “timeout_after_submit”,
“recommended_next_action”: “verify_state”
}
Each field exists for a reason.
operation_idtells the system which business operation is being attempted.idempotency_keyhelps prevent duplicate side effects.correlation_idconnects the tool call to traces and logs.statusdistinguishes completed, failed, and unknown outcomes.side_effect_possiblewarns that downstream state may have changed.side_effect_confirmedsays whether the system knows that change occurred.retryableprevents blind retries when retrying may create duplicates.requires_verificationforces a state check before recovery.business_referencerecords the downstream object if known.error_typeclassifies the failure.recommended_next_actiongives the orchestrator a safe next step.
Microsoft Foundry provides tools and tool integration capabilities for agents. Microsoft documentation describes tools as capabilities that enable agents to perform actions such as searching the web, running code, accessing enterprise data, and calling external services or APIs. The same documentation describes Toolboxes as the recommended way to make tools available to agents through a managed MCP endpoint that centralizes credential and policy management and supports reuse across agents. See Types of tools in Foundry Agent Service.
The engineering responsibility remains with the application team: define the operational contract of each side-effecting tool.
The Action Ledger Pattern
An Action Ledger is the memory of business operations, not conversational memory.
It records what the agent attempted to do, what tool it called, whether the action may have changed external state, and how the system recovered.
This is an engineering pattern, not a Microsoft Foundry product feature. It can be implemented using an appropriate durable transactional store based on the application’s requirements. The right store depends on consistency needs, query patterns, recovery requirements, and the downstream systems involved.
A practical Action Ledger entry might include:
| Field | Purpose |
|---|---|
| Operation ID | Identifies the business operation |
| Idempotency key | Prevents duplicate side effects |
| Correlation ID | Connects action state to traces and logs |
| Tool name | Identifies the dependency invoked |
| Request hash | Detects repeated equivalent requests |
| Side-effect type | Classifies read, reversible write, irreversible write |
| Status | Tracks started, unknown, verified, completed, failed, escalated |
| Business reference | Stores downstream ID such as PR-10482 |
| Attempt count | Tracks retry behavior |
| Last error | Preserves latest failure classification |
| Human review status | Tracks whether a human reviewed or resolved the action |
The Action Ledger helps answer the question that matters during recovery:
Have we already attempted this business operation, and could it have changed external state?
Without that record, the agent may be forced to infer state from an incomplete conversation. That is not a safe boundary for production side effects.
Here is a conceptual Action Ledger record:
“operation_id”: “create-procurement-request”,
“idempotency_key”: “user-123:laptops:2026-08-12:hash”,
“correlation_id”: “trace-7f4c9a”,
“tool_name”: “procurement-api”,
“request_hash”: “sha256:…”,
“side_effect_type”: “irreversible_write”,
“status”: “unknown”,
“business_reference”: null,
“attempt_count”: 1,
“last_error”: “timeout_after_submit”,
“human_review_status”: “not_required”
}
Idempotency: Preventing Duplicate Side Effects
Every irreversible or externally visible agent action should have an idempotency strategy.
That includes:
- Procurement requests
- Ticket creation
- Email sending
- CRM updates
- Approval submissions
- Payment-like operations
- Resource provisioning
- Access grants
Idempotency is not merely an API concern. In agentic systems, it becomes a reasoning boundary.
The agent or orchestrator must know whether repeating an action is safe.
A read-only lookup can usually be retried. Creating a procurement request cannot be treated the same way. Sending an email twice might look harmless in a local test but can create real business confusion. Submitting the same approval twice can break downstream audit trails.
A useful rule:
If the action changes external state, creates a record, sends a message, submits a decision, or triggers a workflow, it needs an idempotency strategy.
Examples:
| Action | Possible idempotency strategy |
|---|---|
| Create procurement request | User ID + normalized request + business date + request type |
| Create support ticket | Source system + requester + issue hash |
| Send email | Draft ID or message intent hash |
| Update CRM record | Record ID + operation type + expected version |
| Submit approval | Approval request ID + approver + decision |
| Provision resource | Environment + resource name + requested configuration hash |
The model should not have to guess whether an action is safe to repeat. The system should make that decision explicit.
The Unknown State Problem
The most dangerous retry is the one issued from unknown state.
Request → Timeout → Did the downstream system execute? → Unknown → Do not blindly retry → Verify state → Recover or retry safely.
A timeout does not mean failure.
It means the caller does not know the outcome.
That distinction is one of the most important reliability concepts for production AI agents. If a tool call timed out before reaching the downstream system, retrying may be safe. If the downstream system executed the action but the response was lost, retrying may create a duplicate.
The agent cannot resolve this by sounding confident.
It must verify state.
In the procurement incident, the safe recovery path is not:
Timeout → retry
It is:
Timeout → check Action Ledger → verify procurement system → recover or retry safely
If the verification call finds PR-10482, the agent should recover and inform the user that the request was created once. If verification proves no request exists, the agent can retry using the same idempotency key. If verification cannot determine state, the agent should escalate.
Designing a Recovery State Machine
Recovery should be treated as an explicit state transition, not an implicit prompt instruction.
STARTED → TOOL_CALLED → clear result? → VERIFY_OUTCOME → COMPLETED
If the tool result is unclear: TOOL_CALLED → UNKNOWN_STATE → VERIFY_STATE → RECOVER, RETRY_SAFE, or ESCALATE.
The point is not the exact diagram. The point is that recovery is part of the application architecture.
A production agent should not simply receive an instruction such as “retry if the tool fails.” That is too vague for side-effecting operations. The orchestrator should know what state the operation is in, what evidence is available, what risks exist, and which transitions are allowed.
The following pseudocode is a conceptual example. It is not Microsoft Foundry SDK code.
if ledger_entry and ledger_entry.status == “completed”:
return “return_existing_result”
if tool_result.status == “completed” and tool_result.side_effect_confirmed:
return “complete”
if tool_result.status == “failed” and tool_result.retryable:
return “retry_safe”
if tool_result.side_effect_possible and not tool_result.side_effect_confirmed:
return “verify_state”
if ledger_entry and ledger_entry.status == “unknown”:
return “verify_state”
if tool_result.error_type in [“authorization_failure”, “policy_conflict”]:
return “escalate”
return “escalate”
This logic makes the recovery decision visible. It also makes the decision testable.
When Should an Agent Ask a Human?
Human intervention is often described as an approval gate, but that is too narrow.
For production agents, human intervention should be risk-driven.
An agent should ask for help when:
- Unknown state cannot be verified.
- An irreversible operation is involved.
- Data sources conflict.
- User intent is ambiguous.
- Authorization or policy conflict occurs.
- Recovery behavior is flagged as unsafe.
- Business impact is too high for autonomous recovery.
Microsoft Foundry human evaluation documentation describes a preview capability in which agent builders define evaluation templates and human reviewers evaluate agent responses using question types such as thumbs up/down, sliders, multiple choice, and free-form text, with results available in the Foundry portal. See Set up human evaluation for your agents.
That is useful for evaluating agent behavior. The engineering pattern proposed here is broader: use human intervention as a structured recovery path when autonomous action is unsafe.
A human should not receive a vague message like:
The agent failed.
The human reviewer should receive enough context to decide:
- What did the user request?
- What operation was attempted?
- What tool was called?
- Was a side effect possible?
- Was the downstream state verified?
- What downstream records were found?
- What recovery action is recommended?
- What happens if the human approves or rejects the recovery?
That turns human-in-the-loop from a generic safety phrase into an operational recovery mechanism.
Using Microsoft Foundry for Tracing and Evaluation
Microsoft Foundry should not be presented as automatically solving idempotency, transaction semantics, or business recovery orchestration. Those remain application architecture responsibilities.
What Microsoft Foundry provides is an operational foundation that makes these patterns easier to observe, test, and improve.
What Microsoft Foundry Provides
Microsoft Foundry Agent Service is documented as a managed platform for building, deploying, and scaling AI agents, supporting prompt agents and hosted agents, with capabilities including tools, observability, identity, security, and publishing. See What is Microsoft Foundry Agent Service?.
Microsoft Foundry documentation describes the agent development lifecycle as including creating agents, adding tools and data, saving versions, debugging with tracing, evaluating quality and safety, publishing, monitoring, and iterating. See Agent development lifecycle.
Foundry tools allow agents to go beyond text generation by calling external services and APIs, accessing enterprise data, using built-in tools, and connecting custom capabilities. Toolboxes expose tools through a managed MCP endpoint for centralized credential and policy management and reuse across agents. See Types of tools in Foundry Agent Service.
Microsoft documentation for MCP integration describes connecting Foundry agents to Model Context Protocol servers, authenticating to MCP servers, reviewing and approving MCP tool calls, troubleshooting common integration issues, and considering public and private endpoint requirements. See Connect agents to Model Context Protocol servers.
Foundry tracing documentation says tracing is used to debug agents and monitor behavior in production, capturing telemetry including latency, exceptions, prompt content, and retrieval operations. It also states that server-side tracing works for agents hosted in Foundry after connecting Application Insights. See Set up tracing in Microsoft Foundry.
The agent tracing overview describes tracing as capturing inputs, outputs, tool usage, retries, latencies, and costs, helping developers understand execution across complex multi-step agent runs. See Agent tracing overview.
Foundry evaluation documentation describes running agent-targeted evaluations against Foundry agents or hosted agents, using rubric evaluators, built-in evaluators, test datasets, and evaluation results to establish quality and safety baselines before deployment. See Evaluate your AI agents.
What the Application Developer Remains Responsible For
The developer still owns:
- Tool-specific failure contracts
- Idempotency strategy
- Action Ledger implementation
- Business-state verification
- Recovery state machine
- Human escalation rules
- Failure-injection scenarios
- Domain-specific recovery metrics
The trace is the black-box recorder for an agent run.
A useful trace should help engineers reconstruct:
- Original user request
- Agent decision
- Tool invocation
- Tool response
- Timeout or error
- Action Ledger lookup
- Verification attempt
- Recovery decision
- Human escalation, if required
- Final outcome
Observability is more valuable when it explains why recovery happened, not merely that an error occurred.
Turning Failures into Evaluation Cases
Reliable recovery should be tested deliberately.
A team could create a failure-injection dataset containing scenarios such as:
- Tool timeout
- Timeout after side effect
- Duplicate action risk
- Authorization failure
- Stale data
- Conflicting data
- Partial completion
- Unknown state
- Required human escalation
This does not need to start large. An example experimental design might include 50 controlled failure cases across these categories. That number is not a Microsoft recommendation. It is simply a practical way to ensure the agent is tested against more than happy-path conversations.
Microsoft Foundry portal evaluation documentation describes running evaluations before deployment or after deployment, using built-in or custom evaluators, and selecting evaluation approaches across agents, models, datasets, synthetic data, existing conversations, and existing traces. See Run evaluations from the Microsoft Foundry portal.
The key is to evaluate recovery behavior, not only final answers.
For example:
| Scenario | Expected recovery behavior |
|---|---|
| Procurement create times out after submit | Verify state before retry |
| Duplicate request exists | Return existing business reference |
| Budget source conflicts with procurement source | Escalate or resolve by trust hierarchy |
| User lacks permission | Stop and explain authorization boundary |
| Verification tool unavailable | Escalate rather than retry irreversible action |
| Partial workflow completion | Recover completed steps and identify remaining work |
Measuring Recovery Behavior
This article proposes an engineering metric called Failure Recovery Score, or FRS.
This is not a Microsoft-defined metric. It is a suggested way to evaluate whether an agent recovered safely.
A simple model:
FRS = failure classification score + retry decision score + duplicate prevention score + state verification score + escalation correctness score + recovery outcome score
Each dimension can be scored from 0 to 1.
| Dimension | Question |
|---|---|
| Failure classification | Did the system correctly classify the failure type? |
| Retry decision | Did it retry only when safe? |
| Duplicate prevention | Did it prevent duplicate external side effects? |
| State verification | Did it verify downstream state when required? |
| Escalation correctness | Did it escalate when autonomous recovery was unsafe? |
| Recovery outcome | Did it reach a safe and useful final state? |
In a production implementation, teams could measure:
- Duplicate actions
- Unsafe retries
- Recovery success rate
- Correct escalation rate
- Task completion rate
- Mean recovery time
- Cost per recovered run
- Trace completeness
- Human review resolution rate
The goal is not to create another dashboard for its own sake. The goal is to make recovery behavior measurable enough to improve.
“failure_recovery_score”: {
“failure_classification”: 0.0,
“retry_decision”: 0.0,
“duplicate_prevention”: 0.0,
“state_verification”: 0.0,
“escalation_correctness”: 0.0,
“recovery_outcome”: 0.0
}
}
A Practical Reference Architecture
The following architecture combines Microsoft Foundry capabilities with application-owned reliability patterns.
User → Microsoft Foundry Agent → Tool Contract Layer → Tools / MCP / Enterprise APIs → Action Ledger → Failure Classifier → Retry / Recover / Escalate → Human Intervention → Tracing + Evaluation + Regression Tests
Component Responsibilities
Microsoft Foundry Agent
Handles agent orchestration, model interaction, instructions, tool selection, and interaction flow depending on the agent design. Foundry Agent Service supports prompt agents and hosted agents for different levels of application control.
Tool Contract Layer
Application-owned layer that normalizes tool outputs into operational semantics: retryability, side-effect possibility, verification requirements, and business references.
Tools / MCP / Enterprise APIs
External systems that perform work. Foundry supports tools and MCP integrations, but each tool still needs a safe business contract.
Action Ledger
Application-owned durable record of attempted operations, idempotency keys, side-effect state, and recovery status.
Failure Classifier
Classifies errors into categories such as transient timeout, unknown state, authorization failure, duplicate risk, or partial completion.
Retry / Recover / Escalate
Explicit recovery actions. Retry should not be the default. It should be one transition in a controlled recovery state machine.
Human Intervention
Risk-driven escalation path for cases where autonomy is unsafe or insufficient.
Tracing + Evaluation + Regression Tests
Foundry tracing and evaluation capabilities can help debug agent behavior, evaluate agent output, and turn failures into testable cases.
Design Principles and Lessons Learned
1. Do Not Treat Timeout as Failure
Timeout means the caller does not know the result. For side-effecting actions, unknown state must be verified.
2. Do Not Let the Model Infer Transaction State
The model should not guess whether a procurement request, ticket, email, or approval was created. External state should be verified through deterministic mechanisms.
3. Tool Contracts Need Operational Semantics
A production tool response should tell the orchestrator more than success or failure. It should describe retryability, side-effect risk, verification needs, and business references.
4. Idempotency Is a Reasoning Boundary
Idempotency helps the system decide whether repeating an action is safe. That decision should be explicit, not hidden in model behavior.
5. Human Intervention Should Be Risk-Driven
Humans should not be inserted into every workflow. They should be introduced where uncertainty, irreversibility, conflict, or business impact justify the cost.
6. Traces Should Explain Recovery, Not Just Errors
A trace should show why the system retried, recovered, escalated, or stopped.
7. Evaluate Recovery Behavior
Accuracy, relevance, groundedness, and safety are important. Production agents also need recovery metrics such as duplicate prevention, state verification, and correct escalation.
Get Started
If you want to apply this pattern, start small. Pick one side-effecting tool in your current agent and design explicit failure semantics around it.
- Try Microsoft Foundry Agent Service: Start with Microsoft Foundry Agent Service and identify where your agent performs real-world actions.
- Explore tool calling and MCP: Review Foundry tools and MCP integrations to understand how your agent connects to external systems.
- Enable tracing early: Connect Application Insights and use Foundry tracing to observe tool calls, retries, errors, and recovery decisions.
- Evaluate recovery behavior: Use agent evaluation and failure-injection scenarios to test more than happy-path responses.
- Use human review intentionally: Explore human evaluation for structured review workflows, especially where uncertainty or business risk is high.
Want to implement this pattern? The Action Ledger and Failure Recovery Score concepts in this post are engineering patterns, not Microsoft Foundry product features. If you build your own implementation, consider sharing your design with the community so others can learn from your failure cases, recovery patterns, and evaluation approach.
Conclusion
Reliable AI agents are not created by making the model smarter alone.
They are created by engineering explicit boundaries around uncertainty, side effects, state, recovery, and human intervention.
Microsoft Foundry provides important capabilities for building, operating, tracing, and evaluating AI agents. But when an agent starts performing real-world actions through tools, APIs, MCP servers, workflow systems, and enterprise data, application teams must design the reliability semantics around those actions.
The production question is not only:
Can the agent answer?
It is also:
Can the agent act safely when it does not know what happened?
That is where failure-resilient agent design begins.
Your next step: Pick one side-effecting tool in your current agent and implement the tool contract pattern described above. Start with the retryable, side_effect_possible, and requires_verification fields. Then connect tracing so you can observe whether the agent retries, verifies, recovers, or escalates when the system enters unknown state.