DEV Community: Sudhanshu Thakur

Most Developers Are Building AI Agents Wrong: MCP Is the Missing Contract

Sudhanshu Thakur — Fri, 02 Oct 2026 16:45:24 +0000

AI agents are easy to demo and difficult to trust.

A developer can connect a language model to a few tools in an afternoon. The first demo looks impressive: the agent reads a request, calls an API, checks a database, and returns an answer.

Then production arrives.

The agent calls the wrong tool. It sends an incomplete payload. It retries a payment operation. It exposes information from another tenant. Nobody can explain why it made a decision.

The problem is not always the language model. The deeper problem is that many teams are building agents without a clear contract between the model, the tools, the data, and the people responsible for the outcome.

That is where the Model Context Protocol, or MCP, becomes important.

An AI agent is more than a chatbot

A useful enterprise agent usually has five parts:

A model that reasons about the request
Instructions that define its role and limits
Tools that allow it to read or change systems
Memory or context that helps it understand the task
Guardrails that control what it is allowed to do

A chatbot mainly generates text. An agent can take actions.

That difference changes the engineering problem completely. If an agent only produces an explanation, an inaccurate response may be corrected by a human. If an agent can approve a refund, change a production configuration, or submit a healthcare request, an inaccurate response becomes an operational incident.

The agent must therefore be treated like a distributed system with an unreliable reasoning component.

The tool boundary is the real architecture

Many early agent implementations expose tools with a name, description, and input schema. That is not enough for production.

A safe tool contract must answer several questions:

Which user or tenant is the agent allowed to access?
Which values are valid?
Does the operation require approval?
Is the operation idempotent?
What happens if the network times out after success?
How is the action audited?

A tool description is not a security policy. It is only the beginning of a contract.

Why MCP matters

MCP provides a standard way for AI applications to discover and use external tools and resources. Instead of building a different integration for every model and every application, teams can expose capabilities through a consistent protocol.

That standardization is valuable, but it does not automatically make an integration safe.

MCP should be treated as an interoperability layer, not as permission to give an agent unrestricted access to a system.

A production MCP tool should define:

A clear business purpose
Read or write classification
Authentication and authorization requirements
Tenant and data-scope restrictions
Input validation
Idempotency behavior
Timeout and retry rules
Rate limits
Audit events
Human approval requirements
A safe failure response

The most important design principle is simple:

The model may request an action, but the platform must decide whether that action is allowed.

A safer agent flow

A reliable enterprise agent should follow a controlled sequence:

User request -> identity verification -> permitted context -> model plan -> policy evaluation -> human approval when required -> MCP tool execution -> result validation -> audit event -> user response

The model should not directly own the complete workflow. It should operate inside one.

For example, an agent may propose: Cancel this payment.

The policy layer should check whether the user is authenticated, whether the payment belongs to the user organization, whether it is still cancellable, whether the amount exceeds an approval threshold, whether the request was already processed, and whether the downstream tool is healthy.

Only after these checks should the action reach the payment service.

MCP and Spring Boot

A practical Java implementation can place an agent gateway in front of domain services.

The gateway can provide:

Spring Security authentication
OAuth2 or JWT validation
Tool-level authorization
Request and response schemas
Correlation IDs
Rate limiting
OpenTelemetry traces
Approval workflow integration
Central audit logging

The domain service should still enforce its own business rules. Never assume that because a request came from an AI gateway, it is trustworthy.

A safe execution model is: validate the user, evaluate policy, validate the tool input, enforce idempotency, call the domain service, validate the result, and record an audit event.

The model can select a tool. It should not bypass the same controls that apply to a human-operated API.

Read tools and write tools are not equal

Read-only tools may retrieve an invoice, search a knowledge base, or check an order status. Write tools may create a payment, update a customer, delete a document, or deploy software.

These categories should have different controls. A read tool may require normal user authorization. A high-impact write tool may require explicit confirmation, a second approver, a transaction limit, a dry-run mode, or a compensating action.

Do not hide a write operation behind a friendly name such as manage account. Use names that reveal the action and its risk: create refund, disable user, or deploy release.

Clear names help models, developers, reviewers, and security teams understand what is happening.

The biggest MCP security risks

MCP-based systems introduce familiar security risks in a new form.

Excessive permissions

An agent receives access to more data and tools than it needs. If the model or server is compromised, the blast radius becomes large.

Prompt injection

Untrusted content inside a document, webpage, or ticket attempts to influence the agent instructions. Retrieved content must be treated as data, not as a higher-priority instruction.

Confused deputy problems

The agent uses its own powerful credentials to perform an action on behalf of a user who does not have that permission.

Tool poisoning

A malicious or poorly maintained tool provides misleading descriptions, hidden side effects, or unsafe defaults.

Data leakage

The agent combines information from different users, tenants, or conversations and includes it in a response.

The solution is not one magic prompt. It is layered security: least privilege, isolation, validation, monitoring, and clear ownership.

Observability is not optional

Traditional application monitoring asks what request failed, which service was slow, and what status code was returned.

Agent observability needs additional questions:

What was the original user intent?
What context was retrieved?
Which tools were considered?
Which tool was selected?
What policy decision was made?
How many retries occurred?
Was human approval requested?
What data was returned to the user?

Every agent action should have a correlation ID that follows the request across the model gateway, MCP server, domain service, database, and audit system.

Without this trail, debugging becomes guesswork.

Start with narrow agents

The best first production agent is rarely a general-purpose assistant with access to the entire company.

Start with one bounded workflow:

Search internal documentation
Summarize support tickets
Validate an invoice
Classify incoming documents
Explain a failed transaction
Draft, but do not send, a customer response

Measure accuracy, latency, cost, refusal quality, tool-selection errors, and security violations. Then expand carefully.

A narrow agent with clear boundaries can create more business value than a general agent that appears intelligent but cannot be trusted.

The future of agents is controlled autonomy

AI agents will become more capable, but capability alone is not the goal.

The goal is controlled autonomy: systems that can complete useful work while remaining observable, explainable, reversible, and accountable.

MCP can help create a common interface between agents and the software world. But the protocol is only one layer. The real production architecture still needs identity, policy, security, resilience, testing, and human judgment.

The strongest agent teams will not ask only, What can the model do? They will also ask, What should the model be allowed to do, under which conditions, and how can we prove what happened?

That is the difference between an impressive demo and an enterprise system.

Final checklist

Before exposing an MCP tool to an AI agent, verify:

Is the tool purpose narrow and explicit?
Is access scoped to the authenticated user and tenant?
Are inputs validated independently of the model?
Are write actions idempotent?
Are high-risk actions reversible or approval-gated?
Are prompts and retrieved documents treated as untrusted data?
Are tool calls, policy decisions, and outputs audited?
Can the team trace a failed decision?
Is there a rate limit and emergency disable mechanism?
Does the system fail safely when the model is wrong?

If the answer to several of these questions is no, the agent is not ready for production.

It is ready for a better architecture.

A production agent architecture

flowchart LR
    U[User request] --> G[Agent gateway]
    G --> P[Policy and identity checks]
    P --> M[Model plan]
    M --> C[MCP server]
    C --> D[Domain service]
    D --> A[Audit and observability]
    A --> R[Validated response]

The model proposes the next action, but the gateway, policy layer, MCP server, and domain service each enforce their own boundary. This layered design prevents one incorrect model decision from becoming an uncontrolled production change.

Reference

Model Context Protocol official documentation

The Future Won’t Be Humans vs AI. It Will Be Humans With AI Everywhere.

Sudhanshu Thakur — Fri, 02 Oct 2026 16:12:35 +0000

Artificial intelligence is no longer something we discuss only in research laboratories or science-fiction movies.

It is already approving bank transactions, detecting fraud, helping doctors read medical scans, optimizing factories, writing software, and recommending what we should watch next.

The next phase will be much more personal.

AI will move from being an application we open to becoming an invisible layer that works around us—inside our homes, workplaces, vehicles, financial systems, hospitals, factories, and eventually spacecraft.

The important question is not whether AI will change the future.

It already has.

The real question is: what kind of future are we building with it?

Banking: From Transactions to Intelligent Financial Partners

Traditional banking is based on products: savings accounts, loans, credit cards, investments, and insurance.

Future banking will be based on continuous intelligence.

Imagine receiving a message from your bank:

“Your electricity bill is higher than usual. Based on your upcoming expenses, paying the full credit-card balance today may reduce your emergency reserve below the recommended level. Would you like to pay in three installments?”

The bank will not simply show a balance. It will understand context.

AI systems will analyze:

Spending patterns
Income stability
Upcoming bills
Credit behaviour
Fraud signals
Market conditions
Personal financial goals

A customer may not need to search for a loan, compare interest rates, or manually transfer money between accounts. An AI financial assistant could identify a need, explain the available options, simulate the risks, and ask for approval.

However, this future creates serious responsibilities.

If an AI denies a loan, the customer should know why. If a fraud model blocks a payment, there must be a fast appeal process. If a financial assistant gives poor advice, the bank must remain accountable.

The future of banking will not be defined only by faster algorithms. It will be defined by transparency, fairness, privacy, and human control.

The Home: Robots That Understand Routines

Household robots will gradually move beyond vacuum cleaners and smart speakers.

The first generation of useful home robots may not look like humanoid machines. They may be practical machines designed for specific tasks:

Cleaning floors and kitchens
Folding clothes
Moving groceries
Monitoring elderly family members
Preparing simple meals
Managing home energy consumption
Detecting water leaks or electrical problems

The most valuable feature will not be mechanical strength. It will be context.

A future home robot might understand:

“My mother has not moved from the bedroom for several hours. She usually takes her medication at 8:00 AM. Should I remind her or call someone?”

That sounds helpful, but it also raises difficult questions.

Who owns the information collected inside the home? Can the manufacturer use camera recordings to train its models? What happens if the robot misunderstands a situation? Can a family disable its sensors completely?

The home of the future may be more convenient, but convenience without privacy can become surveillance.

We should not design homes where people feel watched by their own appliances.

Manufacturing: Human Workers and Intelligent Machines

Manufacturing will probably be one of the areas transformed most rapidly by AI and robotics.

Robots are already used for welding, packaging, inspection, assembly, and material movement. Future factories will combine robotics with AI systems that can make decisions in real time.

A smart factory could:

Predict when a machine will fail
Adjust production based on demand
Detect microscopic defects
Reorganize workflows automatically
Reduce energy and material waste
Train workers through augmented-reality instructions

A worker may wear lightweight glasses that display the next assembly step, warn about a dangerous condition, and translate instructions into their preferred language.

This does not necessarily mean that humans disappear from factories.

Instead, the nature of work will change. Repetitive and dangerous tasks will increasingly be automated, while humans will handle supervision, exception management, design, maintenance, safety, and ethical decisions.

The risk is that companies may treat workers as an expense to remove instead of people to develop.

A responsible factory should use automation to improve human safety and productivity—not simply to eliminate jobs without a transition plan.

Superintelligence: The Most Powerful Tool We Have Ever Created

Today’s AI systems can perform impressive tasks, but they are still limited. They do not possess a complete understanding of the world, and they can make confident mistakes.

Superintelligence would be different.

A superintelligent system could potentially outperform humans across scientific research, engineering, medicine, strategy, and software development. It could discover new materials, design better medicines, optimize global logistics, and solve problems that currently appear impossible.

This could be the greatest opportunity in human history.

It could also be one of the greatest risks.

The danger is not necessarily that an advanced AI system becomes “evil.” A more realistic concern is that it follows an objective in a way humans did not anticipate.

If we ask a highly capable system to maximize a particular outcome without enough constraints, it may take actions that technically satisfy the objective while causing unacceptable harm.

That is why safety cannot be added at the end.

Future AI systems will need:

Clear limits on authority
Human approval for high-impact actions
Independent monitoring
Auditable decision histories
Strong cybersecurity
Emergency shutdown mechanisms
Testing in simulated environments
International agreements

The more powerful the system, the more important the boundaries become.

Space Technology: AI Beyond Earth

Space exploration is another area where AI will become essential.

Communication between Earth and distant spacecraft is slow. A rover on Mars cannot wait for instructions every few seconds. A spacecraft travelling far from Earth must make many decisions independently.

AI could help spacecraft:

Navigate autonomously
Avoid obstacles
Repair or reconfigure systems
Analyze planetary geology
Search for water and useful minerals
Manage energy and communication
Coordinate fleets of satellites
Assist astronauts during emergencies

In the future, robots may construct landing areas, solar farms, laboratories, or habitats before humans arrive.

AI could also support the discovery of life beyond Earth by analyzing enormous quantities of signals, images, chemical measurements, and geological data.

But space technology will require a different kind of reliability. A software mistake in a household robot may be inconvenient. A mistake millions of kilometres away may be impossible to repair.

Space AI must therefore be designed for uncertainty, isolation, radiation, limited energy, and delayed communication.

The Future Will Be a Partnership, Not a Replacement

The popular debate often asks whether AI will replace humans.

That is too simple.

Some jobs will disappear. Many will change. New professions will emerge. The people who can work effectively with intelligent systems will have a major advantage.

The most valuable human skills may become:

Good judgement
Creativity
Empathy
Leadership
Communication
Ethical reasoning
The ability to define meaningful problems

AI can generate thousands of possible solutions. Humans still need to decide which problems deserve to be solved and what consequences are acceptable.

The future will not be created by AI alone. It will be created by the institutions, engineers, governments, and communities that decide how AI should be used.

The Question We Should Ask Today

We should not wait for superintelligence to begin discussing responsibility.

The decisions we make today will shape the systems that influence our finances, homes, workplaces, health, and future exploration.

A good AI future should be:

More productive, but not more exploitative
More convenient, but not more invasive
More intelligent, but not less accountable
More automated, but not less human
More ambitious, but not careless

The future is not a distant event waiting to arrive.

It is being assembled through every model we deploy, every dataset we approve, every business process we automate, and every decision we delegate.

The most important technology question of the next decade may not be:

“How intelligent can machines become?”

It may be:

“Can human beings become wise enough to use that intelligence responsibly?”

Your API Returned 200 OK. Your AI Agent Still Failed.

Sudhanshu Thakur — Sun, 20 Sep 2026 10:52:01 +0000

Why successful API calls are no longer enough when AI agents can take real-world actions

For most backend systems, 200 OK is comforting.

It means the request reached the server, passed validation, and completed successfully.

For an AI agent, however, 200 OK can hide one of the most dangerous failure modes in modern software:

The API did exactly what the agent asked — but the agent asked for the wrong thing.

Imagine an AI-powered banking assistant.

A customer says:

“Refund the duplicate payment from yesterday.”

The agent retrieves several transactions, identifies what it believes is the duplicate, and calls:

POST /refunds

The request is authenticated.

The agent is authorised.

The transaction ID exists.

The refund API processes the request successfully.

HTTP/1.1 200 OK

Every technical dashboard is green.

But the agent selected the wrong transaction.

The API succeeded.

The business outcome failed.

As AI systems evolve from chatbots that recommend actions into agents that execute them, backend engineers need to rethink what “success” actually means.

The Problem: We Treat Success as a Single Layer

Traditional systems usually measure success at several technical levels.

At the network layer:

Did the request reach the service?

At the API layer:

Did the service return a successful response?

At the database layer:

Did the transaction commit?

That works reasonably well when deterministic application code has already decided what operation should happen.

For example:

refundService.refund(transactionId);

The developer has chosen:

which service to call,
which transaction to target,
when the call should happen,
what should happen after it succeeds.

Agentic systems change this relationship.

An AI agent may be given tools such as:

findCustomer()
lookupTransaction()
issueRefund()
cancelOrder()
sendEmail()
disableAccount()
restartService()

The model then determines:

Which tool should I call?
Which parameters should I use?
Should I retry?
What should I do next?

We have introduced probabilistic reasoning before deterministic side effects.

That means we need another definition of success.

Three Levels of Success

I find it useful to separate agent success into three layers.

1. Transport Success

Did the technical request complete?

HTTP/1.1 200 OK

2. Execution Success

Did the backend perform the requested operation?

Refund created successfully.

3. Intent Success

Did the system perform the right action, on the right resource, for the right user, under the right conditions, exactly as intended?

For a refund that might mean:

Correct customer
Correct transaction
Correct amount
Correct reason
Correct approval
Exactly once

The first two are familiar engineering problems.

The third becomes much more important once AI starts selecting and sequencing actions dynamically.

Failure Mode 1: The API Correctly Executes the Wrong Decision

Consider this user request:

“Refund the most recent duplicate charge.”

The agent receives:

[
  {
    "id": "TX-18419",
    "amount": 2500,
    "merchant": "ABC Store"
  },
  {
    "id": "TX-18491",
    "amount": 2500,
    "merchant": "ABC Store"
  }
]

The agent incorrectly chooses:

TX-18491

and sends:

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

The backend validates the request.

The account has sufficient authority.

The transaction exists.

The refund executes.

Technically, there is no error.

But the customer wanted another transaction refunded.

This is an important distinction:

API correctness does not guarantee semantic correctness.

The service knows how to refund a transaction.

It does not necessarily know whether the AI chose the correct transaction.

Failure Mode 2: The Agent Retries Something That Already Worked

Now imagine the refund really is correct.

The agent calls the service.

Agent → Refund API

The refund succeeds.

But the response is lost.

The agent sees:

Timeout

It reasons:

“The refund probably failed. I should retry.”

The second call also succeeds.

Without protection, one user intent may produce multiple real-world side effects.

This problem is familiar to payment engineers and distributed-systems developers.

The difference is that with autonomous agents, retries may not come from a predefined retry library.

The model itself can decide:

“Let me try that again.”

That makes idempotency even more important.

Give Every Important Action an Intent ID

We already use identifiers such as:

request_id
trace_id
span_id

Those identify technical execution.

Agents also need something representing the business objective.

For example:

intent_id = REFUND_DUPLICATE_CHARGE_8472

One intent may generate many technical requests:

REFUND_DUPLICATE_CHARGE_8472
        |
        +-- lookup transaction
        |
        +-- validate eligibility
        |
        +-- create refund
        |
        +-- update CRM
        |
        +-- notify customer

Suppose the refund API times out.

Instead of asking:

Should I POST /refunds again?

the system can ask:

Has REFUND_DUPLICATE_CHARGE_8472
already produced a successful refund?

That is a much safer abstraction.

A Simple Intent Model

Conceptually:

public record AgentIntent(
    UUID intentId,
    String userId,
    String action,
    String resourceId,
    IntentStatus status,
    String resultId
) {}

With:

public enum IntentStatus {
    PENDING,
    EXECUTING,
    COMPLETED,
    REQUIRES_REVIEW,
    FAILED
}

Before executing a mutation:

AgentIntent intent = intentRepository.findById(intentId)
    .orElseThrow();

if (intent.status() == IntentStatus.COMPLETED) {
    return previousResult(intent.resultId());
}

The exact implementation will vary.

The principle is what matters:

A retry should refer to the same business intent instead of silently becoming a new action.

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

Imagine an account-closing agent.

It successfully executes:

✓ Cancel subscription
✓ Revoke API credentials
✓ Delete files
✓ Generate final invoice
✓ Close account

Every API returns success.

But company policy requires:

Export compliance archive
BEFORE
Delete files

The agent skipped the archive.

Five green tool calls.

One invalid business process.

This is why agent observability cannot stop at:

Tool call succeeded

We need to ask:

Was the workflow itself valid?

Put a Deterministic Gate Between Reasoning and Mutation

For read-only operations, directly exposing tools may be reasonable.

For high-impact actions, I prefer an architecture like:

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

Before issuing a refund, deterministic code can verify:

transaction belongs to authenticated user
AND transaction is refundable
AND amount <= remaining refundable amount
AND approval threshold is satisfied
AND intent has not already completed

The model proposes.

The system verifies.

The API executes.

The system verifies again.

That separation is important.

Authorised Does Not Mean Appropriate

Security controls still matter enormously.

But authorisation alone does not solve every agent problem.

Suppose an agent legitimately has permission to call:

restartProductionService()

The credentials are valid.

The operator has the correct role.

But should the service restart now?

Perhaps:

a deployment is currently running

or:

an incident is already active

or:

traffic is at its daily peak

or:

another restart happened 30 seconds ago

Authentication answers:

Who are you?

Authorisation answers:

Are you allowed to perform this operation?

Agentic systems also need:

Is this action appropriate in the current context?

That requires policy, state, and sometimes human judgement.

Define Preconditions and Postconditions

Many tools are described approximately like this:

name: issue_refund
description: Refund a customer transaction

That tells the model what the tool does.

It does not define the conditions that make using it safe.

A stronger contract might be:

tool: issue_refund

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

execution:
  idempotency_required: true

postconditions:
  - refund record exists
  - refund references expected transaction
  - refund amount matches approved amount
  - ledger state reconciles

approval:
  required_above: 5000

Now success is not simply:

function returned successfully

It becomes:

preconditions satisfied
+
action executed
+
postconditions verified

Don’t Let the Agent Grade Its Own Homework

A tempting pattern is:

Agent performs action
↓
Agent asks itself:
"Did that work?"
↓
Agent continues

For low-risk workflows, this may be sufficient.

For important actions, it is fragile.

If the model misunderstood the original request, asking the same model whether its interpretation was correct may reproduce the same mistake.

High-impact actions should be verified against external evidence:

database state
payment receipt
ledger state
policy engine
independent validator
sensor state
human approval

The model can reason about these signals.

It should not invent them.

Observability Needs to Move Above HTTP

Imagine this dashboard:

refund-api availability:       99.99%
tool-call success rate:        98.9%
average API latency:           310 ms

Everything appears healthy.

But you are not measuring:

wrong-target actions
duplicate mutations
policy violations
unverified outcomes
human reversals

Agentic systems need higher-level metrics.

For example:

verified_outcome_rate
duplicate_action_rate
postcondition_failure_rate
human_override_rate
ambiguous_outcome_rate
intent_reconciliation_rate

A meaningful future SLO might look like:

99.95% of high-impact agent intents complete with a verified business outcome and no duplicate side effect.

That tells us far more than API availability.

A Safer End-to-End Example

Suppose a user tells an AI commerce agent:

“Cancel my duplicate order and refund it.”

Instead of immediately executing actions, the workflow could be:

1. Create intent
   CANCEL_DUPLICATE_ORDER_9821

2. Retrieve candidate orders

3. Deterministically verify:
   - same customer
   - duplicate item
   - matching amount
   - cancellable state

4. Generate action preview:
   Cancel Order A1842
   Refund £74.99

5. Request human confirmation if required

6. Cancel order using intent ID

7. Issue refund using same intent context

8. Verify:
   order == CANCELLED
   refund == CONFIRMED
   refund amount == £74.99

9. Mark intent COMPLETED

10. Tell user:
    "Done"

Step 10 is the important part.

The agent does not say “done” because it received 200 OK.

It says “done” because the system verified the intended business outcome.

Six Controls I’d Use for High-Impact Agent Actions

For any agent capable of moving money, modifying production systems, changing permissions, deleting information, or performing irreversible actions:

1. Explicit intent

Persist the actual business objective.

2. Least-privilege tools

Expose only capabilities required for the task.

3. Deterministic preconditions

Keep critical business rules outside the model.

4. Idempotent mutations

Design retries so repeating a request does not repeat the side effect.

5. Independent postcondition verification

Verify the resulting state using trusted systems.

6. Outcome-level auditability

Connect:

user intent
→ agent decision
→ policy result
→ tool call
→ API response
→ verified business state

That gives us:

Intent
  ↓
Policy
  ↓
Action
  ↓
Receipt
  ↓
Verification
  ↓
Outcome

instead of:

Prompt
  ↓
Tool
  ↓
200 OK
  ↓
"Done!"

Agent-Facing APIs May Need Richer Contracts

Traditional APIs mainly answer:

What operation can I call?
What arguments are required?
What response will I receive?

AI-agent-facing capabilities may need to expose more:

What risk level does this action carry?
Is the operation reversible?
Does it require approval?
Can it be retried safely?
What preconditions must hold?
What proves successful completion?

That turns the API from a simple interface into something closer to a capability contract.

The AI supplies flexible reasoning.

The surrounding system supplies deterministic guarantees.

Final Thought

We are investing enormous effort in making AI agents smarter.

Better models.

More context.

More tools.

Longer workflows.

Greater autonomy.

But once an agent can modify the real world, the hardest production question may not be:

Can the model determine what to do?

It may be:

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

The most dangerous failure may never generate an exception.

It may not trigger PagerDuty.

It may not appear in the error logs.

Every service may remain healthy.

All you may see is:

HTTP/1.1 200 OK

The API succeeded.

The AI agent completed its task.

And the business still lost.

That is why production Agentic AI needs more than successful tool calls.

It needs verified outcomes.

References and Further Reading

OWASP — LLM06: Excessive Agency: guidance on risks caused by excessive functionality, permissions, and autonomy in LLM applications.
OWASP — Agentic AI Security: emerging guidance for autonomous AI applications and tool-enabled agents.
NIST — AI Agent Identity and Authorization: work examining how established identity and authorisation practices apply to software and AI agents.
AWS Well-Architected Framework — Idempotent Mutating Operations: guidance for making retries safe in distributed systems.
Stripe API Documentation — Idempotent Requests: a practical example of retry-safe financial API mutations.