Can you catch an AI agent processing a $1,000 refund before it’s too late?
Imagine an AI agent handling customer refunds.
It checks the order.
It calls the payment system.
It decides the refund amount.
It executes the refund.
Everything looks fine.
Except the agent just processed a $1,000 refund that should have been $100.
Would you know why it happened?
Would you be able to stop it?
Would you have the evidence to understand exactly what the agent did?
That’s the problem we’re building Traccia for.
Not just observing AI agents after something goes wrong.
Controlling them while they run.
Trace the execution.
Evaluate decisions.
Enforce policies.
Control risky actions.
We’re building Traccia as an Agent Control Plane for production AI agents.
The interesting question isn’t:
“Can we see what the agent did?”
It’s:
“Can we control what the agent is allowed to do?”
Would you let an AI agent process a $1,000 refund without a control layer?
Replies
The gap I'd worry about is between the check and the write, not the check itself. Rabnoor's ratio test is the right test. But if the control plane evaluates and then the agent executes, that's two steps, and anything re-entering in between walks past a check that already passed.
Money in my product is credits. Read the balance, decide it's enough, write the new balance, and under a retry the same credit gets spent twice. What fixed it was moving the condition into the write. One UPDATE, the rule sitting in the WHERE clause, and zero rows changed is the refusal. "The impossible-amount case" has the same shape: the amount and the ceiling go in one statement, so there's never a moment where something has been approved but not yet committed.
That stops working the moment the commit leaves my own database. I can't put my condition in Stripe's WHERE clause, so over there I fall back to an idempotency key and exactly one piece of code allowed to write the "this was paid" marker. Weaker, and I know it: it makes a retry harmless
So which side of that line is Traccia on? Can you be inside the transaction that moves the money, or are you next to it deciding whether to allow the call?
Traccia
@siarheihamanovich This is a fair distinction — and I agree with the concern.
Traccia currently operates at the agent execution/control boundary, rather than pretending to be the transaction manager for the underlying system of record.
So for something like Stripe, Traccia can govern whether an agent is allowed to execute an action and capture the evidence around that execution. But Stripe still owns the atomicity, idempotency and final commit semantics of the payment transaction.
I think those are two different responsibilities:
Control plane: “Is this agent allowed to perform this action under the current policy?”
System of record: “Can this state transition be committed atomically and safely?”
We don't want to blur those two and claim that a policy check magically makes an external API transaction atomic.
The interesting engineering problem for us is making that control boundary increasingly close to the consequential action — without pretending to replace the guarantees of the system executing the transaction.
the thing id gate isnt the refund, its the ratio. an agent that can issue refunds is either switched on or switched off, and both settings are useless in practice. what actually catches your example is checking the amount against the order it came from, because 1000 against a 100 order is impossible rather than just large, and impossible is something you can test without a model in the loop. the other half of it is that one agent computed the amount and also committed it. splitting propose from commit gets you most of a control plane for almost nothing, since nothing moves until a second step agrees.
Traccia
@rabnoor_s Yes — I think that's the more interesting way to frame it.
The control shouldn't just be “refunds over $X are blocked.” It should be able to evaluate the action in context — including the order, amount, agent identity, and the policy governing that action.
And I agree with the propose → commit distinction. The agent can reason about an action, but the consequential action should still pass through an explicit control boundary before execution.
We don't want an LLM sitting in the middle of every transaction. The goal is to make the enforcement layer as deterministic as possible, while preserving the agent's execution trace and evidence around the decision.
That's much closer to what we mean by an Agent Control Plane.
I keep thinking about false positives. If the system blocks a leitimate $1,000 refund by mistake how quickly can a human review and approve it without breaking the workflow?
Traccia
@simonclark55 The violated policy gets captured real time and gets flagged/alerted. You just need to review the policy violations and take action depending on the severity of the violations.