When AI Refunds Go Wrong: Why Successful Calls Aren't Correct Actions

The Refund That Shouldn't Have Happened

A customer asks a support agent: "Can I return this order?" The agent checks the order status, pulls up current refund policies, confirms the item hasn't shipped, and notes no promotional credits were used. Then it calls refund_order. The API returns success. Logs look clean: tool: refund_order, order_id: 20260710001, result: success.

But the customer only asked if they could return it. They never authorized the refund. The tool call succeeded, yet the business action was wrong. This is the new reality when AI systems move from answering questions to taking actions.

Traditional software would have a button, a confirmation dialog, and backend checks. The code path encodes the reasons: when to call, who can call, what to verify first. Logs can be traced back to code versions and workflow rules. But with AI agents, the model interprets user intent at runtime, assembles context, picks tools, and decides whether to act. The same sentence—"Can I see if I can return this?"—could mean a simple inquiry, a refund request, or a comparison of options. The choice is no longer hardcoded.

From Logs to Reasons: The Missing Link

Call logs record what happened, not why. For high-impact actions, we need an external, auditable record of the judgment that led to the action. This is where KDC (Knowledge-driven Computing) introduces the Reasoning Object.

A reasoning object is not a prompt. Prompts organize input but don't capture what evidence was used, what conclusions were drawn, or what risks were assessed. It's not a trace either—traces show which components were hit and how long they took, not the business semantics. And it's not a full chain-of-thought; we don't need the model's internal monologue. We need an external structure that can be inspected and audited.

For a high-impact judgment, a reasoning object should capture:

• Goal: What task was being addressed?
• Context: User, order, time, session, system state.
• Knowledge references: Which knowledge objects and versions were used?
• Memory references: What historical preferences or precedents influenced the judgment?
• Evidence: What facts, documents, or confirmations support the conclusion?
• Key judgments: What checkable steps led from goal to conclusion?
• Conclusion type: Factual judgment, recommendation, plan, or action request?
• Uncertainty: Is evidence sufficient? Need more info?
• Risk: What's the impact if wrong?
• Action suggestion: Should a capability be invoked?
• Feedback: Did the real-world outcome confirm or refute the judgment?

Separating Fact from Authorization

In the refund case, a proper reasoning object would distinguish between two conclusions: the order meets refund conditions (a factual judgment) and the user explicitly requested an immediate refund (an authorization). These are different. The first can be supported by order facts and policy. The second requires explicit user confirmation. If the system tags the task as "eligibility inquiry" and flags "user confirmation" as a precondition for the action, a control mechanism could block the agent from jumping from consultation to execution.

The point of a reasoning object isn't to make the model look smarter. It's to let the system check whether a judgment has the authority to become an action.

Three Layers: Tool, Skill, Capability

To govern actions, we need to separate three layers that often get conflated.

Tool: How to Execute

A tool is the minimal executable entry point. get_order_status, check_refund_eligibility, refund_order—these are tools. They have names, parameters, and return values. But just because a tool exists doesn't mean a model should call it in any context.

Skill: How to Organize Around a Goal

A skill organizes multiple tools around a business goal. "Process order refund" isn't a single tool; it involves clarifying intent, checking order status, retrieving policy, judging eligibility, getting user confirmation, executing refund, tracking status, and escalating if needed. A reusable skill should define the business goal, preconditions, required context, participating tools, orchestration logic, risk boundaries, failure handling, and audit requirements. Skills sit between fixed workflows and fully free-form planning.

Capability: How to Act Within Governance Boundaries

A capability adds governance semantics. refund_order is a tool; "initiate order refund capability" includes identity and business meaning, inputs/outputs and real-world impact, who can invoke it, risk level, owner, version, preconditions and postconditions, human confirmation requirements, audit and observability policies, and rollback/compensation strategies.

In short: Tool = how to execute; Skill = how to organize execution around a goal; Capability = how to execute within governance boundaries.

Why Prompt Rules Aren't Enough

Teams often put rules in the system prompt: "Must get user confirmation before refund." That's a useful instruction, but it's not a reliable safeguard. Prompts can be influenced by context, models may misinterpret natural language, and instructions can be lost in complex tasks. If the underlying refund_order tool is fully open to the model, the governance responsibility rests on a single probabilistic judgment.

Capability governance lifts key boundaries into system mechanisms: permissions (is this actor allowed to refund?), risk level (does the amount or situation require stricter controls?), policy checks (are knowledge, evidence, and preconditions complete?), human-in-the-loop (does the user or an approver need to confirm?), rate limiting and circuit breakers, transaction and compensation (avoid half-done states), audit (who initiated the action and why), observability (success rate, policy rejections, human interventions, real-world outcomes), and lifecycle (experimental, stable, retired).

This doesn't mean slowing everything down. Read-only, reversible, low-impact actions can be lightweight. Writes, money, permissions, and irreversible actions need stricter evidence and confirmation.

The Agent as Coordinator, Not Container

If you treat the agent as an all-purpose entity, it becomes responsible for everything: understanding goals, holding context, forming judgments, choosing tools, executing actions, handling failures, and generating audits. The system seems simple, but accountability becomes impossible to untangle. When something goes wrong, you get "the agent made a mistake," but the real cause could be in goal interpretation, knowledge version, memory usage, reasoning path, skill selection, capability implementation, governance policy, or the external system.

KDC places the agent above objects, runtimes, and governance mechanisms, not as the foundation. The agent can interpret user goals, request and organize context, coordinate reasoning, select reusable skills, propose capability calls, and handle execution feedback. But high-impact judgments should form reasoning objects or equivalent audit records, and high-risk actions should go through capability governance. The agent can suggest an action, but it shouldn't automatically have the authority to execute just because it did the reasoning.

A Practical Exercise: Reconstructing an AI Action Audit Trail

Pick a real high-impact action—a refund, payment confirmation, permission change, approval submission, order creation, or external notification. Don't design a new platform yet. Start with a single real call log and try to reconstruct the chain:

• Business goal → knowledge and memory basis → auditable judgment and risk → skill and capability selection → permission and policy check → user confirmation or HITL → execution result → real-world feedback.

Create a minimal AI Action Record. Look for four gaps:

• Causal gap: You see a tool call but can't trace the goal and basis.
• Semantic gap: The tool has parameters but no business meaning, risk, or owner.
• Governance gap: Key boundaries exist only in prompts, not in system policies.
• Feedback gap: The API succeeded, but there's no verification of the real-world outcome.

This record isn't meant to be a universal schema or to be saved for every read-only query. Its purpose is to verify: for important actions, can the system answer "why was this done, who allowed it, based on what, and what was the result?" If you still have to piece together answers from chat logs, prompts, and multiple log files, your audit trail isn't a stable engineering capability yet.

Conclusion: The Real Test Is Knowing When Not to Act

Getting a model to call a tool is no longer the hard part. The hard part is putting runtime judgment, business risk, and execution authority into a single governable chain. Reasoning objects let the system express why it judged a certain way. Skills allow goal-level processes to be reusable while keeping room for adaptation. Capabilities give actions meaning, permissions, risk, ownership, and lifecycle. Control planes make critical boundaries depend on more than model self-regulation.

So remember: a successful call doesn't mean the judgment was correct. A correct judgment doesn't mean the user authorized the action. An API returning success doesn't mean the real-world goal was achieved.

Enterprise AI's value isn't in letting agents do as much as possible. It's in letting them act when they should, stop when uncertain or unauthorized, and make every important action explainable, auditable, and accountable. But even when the reasoning and action are right, the system isn't reliable long-term. Reality changes, knowledge expires, users correct the system, and capabilities fail. That's the topic for the next piece: how history and feedback become memory, and how to avoid amplifying mistakes.