For years, backend engineers have been trained to fear failed requests.

500 Internal Server Error
503 Service Unavailable
Timeout
Connection reset

Those failures are visible. They trigger alerts. Dashboards turn red. Retries begin. Engineers investigate.

AI agents introduce a more uncomfortable possibility:

What if nothing fails?

Imagine an enterprise agent processing a refund. It has valid credentials. It calls the correct refund API. The request passes authentication and authorisation. The API returns HTTP 200 OK. The transaction completes exactly as the API was designed to complete.

And the agent has just refunded the wrong customer.

Every infrastructure dashboard may remain green. No exception was thrown. No authentication control failed. No service was unavailable. No malicious payload was detected. The system was technically successful. The business outcome was wrong.

That is one of the most dangerous classes of failure we are likely to encounter as AI agents move from answering questions to taking actions.

We Have Been Treating “Success” as One Thing

Traditional application monitoring gives us familiar layers. At the network layer: did the request reach the service? At the API layer: did the service return 2xx? At the application layer: did the database update?

For deterministic software, these signals are often enough because the developer has already decided which operation should happen.

An AI agent changes that assumption. A developer may expose tools such as lookupCustomer(), issueRefund(), cancelOrder(), sendEmail(), disableAccount() or restartService(). The model can decide which tool to call, when to call it and which arguments to provide.

That introduces a new layer of success: was this the correct action for the user’s actual intent? A 200 OK cannot answer that.

Failure Mode #1: The API Did Exactly What the Agent Asked

Suppose the user says: “Refund the most recent duplicate charge.” The agent retrieves five transactions. Two are similar. It selects transaction TX-18491. The correct duplicate was actually TX-18419.

{
  "transactionId": "TX-18491",
  "amount": 2500
}

Everything validates. The user has permission. The payment service performs the refund. The response is successful.

From the API’s perspective, there is no failure. From the customer’s perspective, the system acted on the wrong transaction.

This does not require prompt injection or excessive privilege. It can be an incorrect interpretation followed by a perfectly valid mutation. The closer agents get to systems of record, the more important this distinction becomes.

Failure Mode #2: The Agent Retries a Successful Action

Now consider a different sequence. The agent calls POST /refund. The service processes the refund. The response is lost because of a network timeout. The agent observes a timeout and concludes that the refund probably failed, so it tries again.

The second request also succeeds. The model did not hallucinate. The service did not break. The problem is that the agent could not distinguish “operation failed” from “operation succeeded, acknowledgement failed”.

Distributed systems have dealt with this problem for years. AWS Well-Architected recommends making mutating operations idempotent so retries do not repeat side effects [6]. Stripe likewise supports idempotency keys so mutating financial requests can be retried safely after connection failures [7].

Agents do not make this old problem disappear. They make it more important because the agent may reason itself into a retry.

Failure Mode #3: Every Step Succeeds, but the Workflow Is Wrong

Consider an agent handling an account closure. It cancels the subscription, revokes the API key, deletes stored files, issues the final invoice and closes the account. Every tool call returns success.

But suppose policy requires the compliance archive to be exported before deleting files. The agent skipped that step. Technically, five out of five tool calls succeeded. Operationally, the workflow violated policy.

A green trace is not proof of a correct workflow.

Failure Mode #4: The Agent Was Allowed to Do It

Security teams naturally focus on authorisation, and that is essential. NIST has highlighted identity and authorisation as core concerns when software and AI agents are given access to tools, applications and data [4][5].

OWASP similarly identifies Excessive Agency as a major LLM risk, particularly when systems grant excessive functionality, permissions or autonomy [1]. Its Agentic Applications Top 10 and 2026 incident work broaden that focus to autonomous workflows, tool misuse, identity/privilege abuse and cascading failures [2][3].

But there is a subtle problem: authorised does not mean appropriate.

Imagine an agent has legitimate permission to restartProductionService(). The credentials are valid. The requesting operator is authorised. But should the service be restarted right now? Is a deployment in progress? Is another incident active? Is the agent acting on stale telemetry?

Identity answers who is acting. Authorisation answers what they may do. Agentic systems also need to answer whether this permitted action should happen in this context.

The Missing Layer: An Intent and Outcome Gate

Consequential agent actions need a layer between reasoning and mutation. Instead of allowing the model to act as the final judge of whether its own action was correct, the system should evaluate deterministic preconditions and postconditions around high-impact actions.

User / Business Goal
↓
AI Agent
↓
Intent + Policy Gate
↓
Tool Gateway
↓
Business API
↓
Outcome Verification

For a refund, deterministic checks could confirm that the transaction belongs to the authenticated customer, the amount is refundable, the reason code is valid, the approval threshold is satisfied and the same intent has not already completed.

After execution, postconditions can verify that the refund exists, is linked to the expected transaction, matches the approved amount and is reconciled in the ledger.

This moves correctness outside the prompt.

Use Business Intent, Not Just Request IDs

Traditional observability gives us request_id, trace_id and span_id. They are excellent for reconstructing technical execution. Autonomous workflows need another identifier: intent_id.

A request ID asks: which HTTP request was this? An intent ID asks: which real-world objective was this request trying to satisfy? One intent can generate many technical requests.

Intent: REFUND_DUPLICATE_CHARGE_8472

Request 1: lookup transaction
Request 2: validate duplicate
Request 3: issue refund
Request 4: update CRM
Request 5: notify customer

If Request 3 times out, the system can ask whether intent REFUND_DUPLICATE_CHARGE_8472 has already produced a refund instead of immediately generating another mutation.

This is where idempotency becomes more meaningful for agentic workflows.

Semantic Success Needs Explicit Postconditions

Agent tools are often described by what they do, not by what successful business completion means. A stronger contract can define deterministic preconditions, idempotency requirements, postconditions and approval thresholds.

tool: issue_refund

preconditions:
  - transaction belongs to authenticated customer
  - transaction is refundable
  - amount <= remaining refundable amount

execution:
  idempotency_required: true

postconditions:
  - refund record exists
  - refund amount equals approved amount
  - refund references expected transaction
  - ledger balance reconciles

human_approval:
  required_above: 5000

Now the orchestration layer has something deterministic to verify. The model can reason; the system verifies.

Do Not Let the Agent Grade Its Own Homework

A convenient pattern is to let the agent perform an action, ask itself whether the action succeeded and then continue. That is weak for high-impact operations.

If the same reasoning system misunderstood the original intent, asking it to evaluate its own action may reproduce the same misunderstanding.

For consequential workflows, outcome verification should come from external evidence: database state, ledger state, an API receipt, a policy engine, an independent validator or a human approval.

The agent can interpret those signals, but it should not invent the source of truth.

Observability Must Move From Requests to Outcomes

Imagine a dashboard showing refund-api availability at 99.99%, agent tool-call success at 98.7% and average latency at 320 ms. Everything looks excellent.

But the dashboard may not be measuring wrong-target refunds, duplicate refunds, policy-violating refunds, unverified outcomes or human reversals.

For autonomous systems, teams should consider outcome metrics such as:

• verified_outcome_rate
• duplicate_action_rate
• postcondition_failure_rate
• human_override_rate
• intent_reconciliation_rate
• ambiguous_outcome_rate

A more meaningful SLO could be: 99.95% of consequential agent intents complete with a verified business outcome and no duplicate side effect.

That is very different from API availability.

A Practical Example

Suppose an agent receives: “Cancel my duplicate order and refund it.” A safer flow might be:

1. Create a durable intent: CANCEL_DUPLICATE_ORDER_9821.
2. Identify candidate orders.
3. Deterministically verify same customer, duplicate SKU, matching amount and eligible cancellation state.
4. Present a preview of the exact order and amount to be changed.
5. Require confirmation when policy demands it.
6. Execute cancellation using the intent ID.
7. Execute refund using the same business intent.
8. Verify order state == CANCELLED, refund state == CONFIRMED and the refund amount is correct.
9. Mark the intent COMPLETED.
10. Only then tell the user: “Done.”

“Done” should be produced because the system has evidence that the intended postconditions are true — not because the model feels confident.

Security Teams Should Care About This Too

This may sound like reliability engineering. It is. It is also security.

OWASP’s Excessive Agency guidance focuses on damage that can occur when agents have excessive functionality, permissions or autonomy [1]. Its 2026 agentic work shows the security conversation moving toward agent identities, orchestration, tool misuse and cascading failures [2][3].

NIST’s 2026 analysis of AI-agent security feedback similarly found broad agreement that agentic systems create novel security concerns and that established cybersecurity practices remain relevant but require adaptation [4].

A valid action can still be a dangerous action.

Security cannot stop at asking whether the call was authenticated, authorised and syntactically valid. It must also ask whether the action was consistent with the user’s intent, safe in the current state, executed exactly once and independently verified.

The Pattern I Would Use in Production

1. Explicit Intent — Create a durable identifier for the user’s actual objective.
2. Least-Privilege Tools — Expose only the capabilities required for the workflow.
3. Deterministic Preconditions — Validate critical business rules outside the model.
4. Idempotent Execution — Make retries safe wherever possible.
5. Independent Postcondition Verification — Prove that the expected state actually exists.
6. Outcome-Level Auditability — Connect user intent, agent reasoning, tool execution and final business state.

That gives you a stronger chain:

Intent → Policy → Action → Receipt → Verification → Outcome.

The Future Agent API Is a Capability Contract

For human-facing software, APIs have traditionally answered: what operations does this service expose?

Agentic APIs may need to answer more: what action is this, what risk level does it carry, is it reversible, does it require confirmation, what makes it idempotent, what are the preconditions, and what proves successful completion?

That makes the API less like a thin CRUD interface and more like a capability contract. The model still provides intelligence. The API provides deterministic guarantees around how that intelligence can affect the world.

Final Thought

We are spending enormous effort making AI agents smarter: better reasoning, more context, more tools and more autonomy.

But once an agent can act on production systems, the hardest question may not be whether the agent can figure out what to do.

How do we prove that the thing it just did was actually the thing we intended?

The most dangerous failure may not produce an exception. It may not trigger an alert. It may not look like a security incident.

HTTP/1.1 200 OK

The API succeeded. The agent succeeded. And the business still lost.

That is why production Agentic AI needs something stronger than successful tool calls. It needs verified outcomes.

References & Evidence

1. OWASP — LLM06:2025 Excessive Agency — Explains risks from excessive functionality, permissions and autonomy in LLM-based systems.

2. OWASP — Top 10 for Agentic Applications 2026 — Peer-reviewed framework for critical risks in autonomous and agentic AI systems.

3. OWASP — GenAI Exploit Round-up Q1 2026 — Documents real-world incidents and trends involving agent identities, orchestration, permissions and cascading failures.

4. NIST — Summary Analysis: Security Considerations for AI Agents — Summarises 2026 feedback on AI-agent security and the need to adapt cybersecurity practices.

5. NIST — Identity and Authority of Software Agents — Discusses identity and authorisation controls for software and AI agents accessing tools, data and applications.

6. AWS Well-Architected — Make Mutating Operations Idempotent — Guidance on using idempotency tokens to make retries safe in distributed systems.

7. Stripe API — Idempotent Requests — Practical API example for safely retrying mutating financial requests without duplicating side effects.