When AI Tool Calls Succeed but Actions Fail: The Governance Gap

The Refund That Shouldn't Have Happened

Picture this: a customer asks a support agent, "Can I get a refund on this order?" The agent checks the order status, pulls up the current refund policy, confirms the item hasn't shipped, and sees no promotional credits were used. Then it calls refund_order. The API returns success.

The execution log looks clean: tool: refund_order, order_id: 20260710001, result: success. But the user only asked if they could refund, not to actually process it. The tool call succeeded, but the business action was wrong.

This is the new reality of AI agents: they don't just answer questions anymore; they take actions. And when they do, the traditional logs we rely on—tool, parameters, result—tell us nothing about why the action happened.

Why Traditional Logs Fall Short

In conventional software, a refund sits behind a clear code path. A user clicks a button, confirms a dialog, the backend checks permissions and order state, risk rules may flag it for review, and the transaction service executes with retries and rollbacks. The developer already decided when to call, who can call, what to check, and what happens on failure. So even a minimal log—interface, parameters, result—can be traced back to the code to understand the cause.

Agents change that. The model interprets user intent at runtime, assembles context, picks tools, and decides whether to act based on natural language. The same phrase "can I get a refund" could be a question about eligibility, a request to proceed, or just a comparison. The choice is no longer hardcoded.

When important actions are chosen at runtime, the reasons for those actions need to become manageable runtime objects too. Otherwise, we have systems with ever-growing capabilities and ever-shrinking explanations.

Introducing Reasoning Objects

KDC (Knowledge-driven Computing) proposes a structure called a Reasoning Object—an engineering artifact that captures the business semantics and causal basis of a decision. It's not a prompt, which merely organizes input. It's not a trace, which records request flow and timing. And it's definitely not a requirement to expose the model's full chain-of-thought, which may be unavailable, unstable, or irrelevant.

For a high-impact decision, a Reasoning Object should at least articulate:

• Goal: What the task is supposed to accomplish
• Context: User, order, time, session, system state
• Knowledge references: Which knowledge objects and versions were used
• Memory references: Historical preferences or precedents that influenced the judgment
• Evidence: Facts, documents, or human confirmations that support the conclusion
• Key judgments: The external checkpoints from goal to conclusion
• Conclusion type: Fact, recommendation, plan, or action request
• Uncertainty: Whether evidence is sufficient
• Risk: Potential impact if the decision or action is wrong
• Action suggestion: Whether to invoke a capability
• Feedback: Whether real-world results later confirmed or refuted the judgment

In the refund case, a proper structure would separate two things: this order is eligible for refund (a fact) and the user explicitly requested the refund now (an authorization). These are not the same. If the Reasoning Object marks the task as "eligibility inquiry" and lists "user confirmation" as a precondition, the control system can stop the agent from jumping from advice to action.

From Judgment to Action: A Traceable Chain

A governed AI action shouldn't just leave a tool call record. It needs a chain:

Business goal → Knowledge & evidence → Reasoning Object → Capability suggestion → Policy & permission check → Capability invocation → Execution result → Real-world feedback

The Reasoning Object sits between knowledge and action, acting as the upstream causal anchor. It tells auditors: this refund happened because the system identified a goal, referenced a specific version of the refund policy, read the order facts, assessed risk, and formed an action recommendation. It also makes refusal a normal outcome. If evidence is missing or the goal is ambiguous, the system can say "cannot act now" without waiting for the tool to fail.

Not every action needs a full Reasoning Object. Low-risk read-only queries can skip it. But for refunds, payments, permission changes, external notifications, approvals, and irreversible operations, we should keep at least the equivalent of goal, evidence, risk, and authorization. The higher the impact, the more explicit the responsibility.

Reasoning Runtime: Managing Judgments, Not Just Prompts

Reasoning Objects define what a judgment should include. The Reasoning Runtime handles how these objects are created, updated, and used during system operation. It identifies goal types, assembles context from knowledge and memory, binds evidence, creates the object, expresses uncertainty and risk, suggests capabilities, and later links feedback back to the original judgment.

The runtime isn't the model itself. Goal classification can be done by rules and models together; evidence completeness can be checked by the system; risk levels can come from policy; user confirmation can be an interaction state; feedback can arrive long after the model call ends. It's also not a prompt orchestrator. A prompt organizes one model input; the runtime manages knowledge versions, object identity, risk state, action suggestions, and feedback loops.

You don't need to build a separate platform for this. Start with application modules, structured records, and policy checks. What matters is that someone owns the judgment lifecycle, not that we create a shiny new service.

Tool, Skill, and Capability: Three Layers of Execution

Once you have a judgment, you need to execute it. But execution shouldn't be a free-for-all. KDC distinguishes three layers:

• Tool: How to execute a specific operation (e.g., get_order_status, refund_order)
• Skill: How to organize multiple operations around a business goal (e.g., a refund skill that includes eligibility check, user confirmation, execution, and exception handling)
• Capability: The governance boundary around an action—its semantics, permissions, risk level, owner, lifecycle, and audit requirements

If you skip this separation, an action suggestion from the Reasoning Object will land directly on a Tool, mixing business goals, orchestration, and governance into one blurred mess.

Why Prompt Rules Aren't Enough

Teams often write in the system prompt: "You must get user confirmation before refunding." That's a useful instruction, but it shouldn't be the only defense for a high-risk action. Prompts get influenced by context, models can misunderstand language, and instructions can be forgotten in complex tasks. If the raw refund_order tool is open to the model, you're betting the house on a probabilistic judgment.

Capability governance needs to be a system mechanism: permissions, risk levels, policy checks, human-in-the-loop, rate limiting, circuit breakers, transaction compensation, audit trails, observability, and lifecycle state. In the refund case, the control plane should treat "explicit user confirmation" as a hard precondition for the transactional refund capability. Even if the agent's reasoning is flawed or the skill misses a step, the capability won't execute.

This isn't about slowing everything down. Read-only, reversible, low-impact actions can stay lightweight. Writes, money, permissions, and irreversible actions deserve stricter evidence and approval.

The Agent's Rightful Place: Coordinator, Not Everything

If you treat the agent as a universal actor, it ends up responsible for understanding goals, storing context, making judgments, choosing tools, executing actions, handling failures, and generating audits. The system looks simple, but responsibility is impossible to untangle. When something goes wrong, you get "the agent made a mistake"—but the real cause could be in goal interpretation, knowledge versions, memory use, reasoning path, skill selection, capability implementation, governance policy, or an external system.

KDC puts the agent above objects, runtimes, and governance mechanisms. The agent can interpret user goals, request context, coordinate reasoning, pick reusable skills, suggest capability calls, and handle feedback. But high-impact judgments must form Reasoning Objects or equivalent audit records, and high-risk actions must pass through capability governance. The agent can suggest an action, but it doesn't get execution permission just by completing a reasoning process.

This doesn't mean turning the agent into a fixed script. Goal interpretation and path selection remain dynamic—just not hidden in the agent's ephemeral context.

Building an AI Action Audit Trail

If you want to see how this works in practice, pick one high-impact action your system already performs—a refund, a payment confirmation, a permission change, an approval submission, or sending a notification. Don't design a new platform first. Take a real call record and try to reconstruct the chain: business goal → knowledge and memory basis → auditable judgment and risk → skill and capability choice → permission and policy check → user confirmation or HITL → execution result → real-world feedback.

Then look for four gaps:

• Cause gap: You only see the tool call, not the goal or reasoning
• Semantic gap: The tool has parameters but no business meaning, risk, or owner
• Governance gap: Key boundaries exist only in the prompt, not in system policy
• Feedback gap: The interface returned success, but no one verified the real-world outcome

You don't need every system to share the same fields. But for important actions, your system should be able to answer: why did we do this, who allowed it, what was the evidence, and what happened afterward. If you're still stitching together chat logs, prompts, and scattered logs to figure that out, your action audit chain isn't a stable engineering capability yet.

The Real Challenge: 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 permissions into a single governable chain. Reasoning Objects let the system say why it judged the way it did. Skills let goal-level processes be reusable yet flexible. Capabilities give actions semantics, permissions, risk, ownership, and lifecycle. A control plane makes key boundaries depend on more than model self-discipline.

So remember: call success ≠ correct judgment; correct judgment ≠ authorized action; API success ≠ real-world goal achieved. Enterprise AI's value isn't in doing as much as possible—it's in acting when appropriate, stopping when uncertain or unauthorized, and leaving a trail that can be explained, audited, and held accountable.