The question is about people, not agents
Give an agent a way to pay and the review meeting changes. Nobody asks how clever the agent is. They ask whose it is, what it did, what it could have done, and who said yes.
Those are questions about accountability, and the answer has to be something you can look up afterwards, not something you reconstruct from memory. That is what a trace is for.
One trace, from the request to the outcome
In Waggle, every action is an event on the event bus. An event carries an id, a time, a source, a type, a workspace, a principal and a trace id. The principal says which human or which agent did it, by id. Events link into chains through the trace id.
A trace shows each agent turn: the workspace, the agent, the account the agent belongs to, what triggered it, the outcome, the tools and credentials it used, and any approvals along with who decided them. Follow one chain and you can read a piece of work from the person's request, through the agent's turn, the credential it was leased, the approval, and the outcome.
This exists today for agent work in general. The payment-specific part, a purchase as its own kind of event, is what we are building next.
What payment-security reviewers tend to ask
Reviewers who work from payment card standards such as PCI DSS ask for similar things in general terms. Each person is individually accountable. Credentials are never exposed to the thing that uses them. There are limits on what can be spent. And the logs tie each action back to one human.
We are not claiming compliance with any standard. What we can do is say plainly how the design lines up with those questions. Accountability: every event names its principal by id. Credentials: they sit in escrow, and an agent holds a lease, never the value. The log: events share a trace id, so an action leads back to the person who asked or approved.
Spend limits are the one that does not exist yet. We will say that every time it comes up.
Live today, and what we are building
Live today: events with a principal and a trace id, traces per agent turn, approvals that record who decided, and credentials held in escrow with leases for agents. Nothing about a payment is live. An agent cannot spend money through Waggle today.
We are building payment events on the same bus: who authorized a purchase, which agent spent, a spend limit per agent, and step-up approval above a threshold. Also a tamper-evident payment log, and card-number redaction at ingress, so a card number someone pastes into a message does not land in the log.
Be clear about the log as it is. The event log is not signed or hash-chained, and it is retained 90 days by default, longer when an archive is configured. A reviewer who needs a log nobody can quietly edit, kept for a year or more, needs more than we have. Signing or hash-chaining the payment log, and a longer retention, are what would have to be added.
Ask a model to read the trace
Traces are tools on the MCP endpoint, so you can point an assistant at them. Add https://api.hachiflow.com/mcp to your client, sign in, and ask in plain language what your agents did.
The assistant calls hachi_traces_ls to list the agent turns, picks one, and calls hachi_trace_get on it. That returns the whole linked chain of events for that piece of work, and the model reads it back as a short account: who asked, which agent acted, which credential it used, who approved, what happened.
Today that answers who approved what an agent did. Payment events do not exist yet. When they do, we are building them so the same question covers spend, with the amount and the limit that applied.
The question and the two tools it uses. The answer comes from the trace, not from the model's memory.
Traces also show what to stop asking a model to do
Reading traces has a second use. When the same task shows up turn after turn with the same tools in the same order and the same outcome, it is not really a judgment call anymore. It is a routine.
Those are the tasks worth turning into deterministic code. Keep the model for the work that varies, and let a plain script do the work that does not. The trace tells you which is which, because it records what happened rather than what anyone remembers.
Where this leaves us
Accountability for agent work is live: principals, trace chains, approvals and credential leases. Accountability for agent spending is planned: payment events, spend limits, step-up approval and a tamper-evident log. We would rather tell you which is which than imply that one covers the other.