AACP · Blog

What auditability actually means in a multi-agent workflow

By Andrew Mackay·26 June 2026·6 min read

What people mean when they say auditable

Auditability in AI systems tends to mean one of two things.

The first is output logging: keeping a record of what the model produced. What did the agent write? What decision did it make? What did it recommend? This is the most common interpretation and most frameworks support it reasonably well.

The second is process auditing: what happened between the inputs and the outputs? What instructions did each agent receive? From whom? In what order? What was the exact wording of the coordination message that sent the payroll agent to retrieve March data instead of February data?

The second is where most multi-agent systems have a gap.

The coordination audit problem

In a standard multi-agent LLM workflow, agents coordinate by writing natural language messages to each other. The orchestrator tells the HR agent what to retrieve. The HR agent tells the finance agent what to calculate. The finance agent tells the audit agent what to log.

Those messages get logged. But they look like this:

[2026-06-10 09:14:22] HR Agent: "Please retrieve the employee salary records
for the period ending March 2026. I need all active employees, their
departments, cost centres, base salary, any changes made this month,
and pension contribution rates. Return as JSON array."

[2026-06-10 09:14:31] HR Agent: "I have retrieved the employee records as
requested. There are 147 active employees across 12 departments. I'm
now passing this to the Finance Agent for payroll calculation."

[2026-06-10 09:14:39] Finance Agent: "Thank you. I'll process the payroll
calculations now. Could you also include the pension contribution rates
in the next request?"

You can read this. A human can follow it. But you cannot reliably query it, parse it programmatically, or diff it against last month's run to find what changed. If an error occurred in the March payroll run, finding the exact instruction that caused it means reading through paragraphs of slightly different generated prose.

And critically: the wording of those messages varies on every run. The agent wrote different English in March than it wrote in February. Both meant the same thing. The audit log reflects that variation even when the underlying workflow was identical.

What a structured audit trail looks like

When coordination messages are AACP packets, the same workflow produces this:

[2026-06-10 09:14:22] FETCH|HR|return:HR-Agent|p:1|aacp:1.4|res:emp_salary|period:2026-03|filter:status=active|fmt:json

[2026-06-10 09:14:31] PROC|FIN|return:FIN-Agent|p:1|aacp:1.4|res:payroll_calc|src:HR-Agent|period:2026-03|rules:payroll_v2|validate:budget_cc

[2026-06-10 09:14:39] LOG|HR|return:AUD-Agent|p:2|aacp:1.4|res:payroll_audit|period:2026-03|status:complete|agent:FIN-Agent

Every packet is machine-readable. Every field is named and typed. The same workflow in April will produce packets that are character-for-character identical to March, except for the period field. That difference is immediately visible in a diff.

If an error occurred in March, you can query the log for every packet sent to the finance agent in that run. You can extract the exact rules: field that was applied. You can replay the coordination sequence with identical inputs and verify the result.

None of that requires post-processing the log. The structure is in the message itself.

The audit agent costs nothing

There is a concrete operational consequence of this.

In the QBR lab I built for AACP, one of the five agents is an audit agent. Its job is to log every coordination hop as a structured record, flag anomalies, and maintain the audit trail for the workflow run.

In a natural language system, an audit agent needs LLM calls to parse and categorise incoming messages. The messages vary in wording. Extracting structured meaning from them requires interpretation.

In an AACP system, the audit agent reads structured packets. It does not need an LLM to interpret them. It reads the TASK field, the domain, the return address, the resource, the period, and the status. All of that is already there. The audit agent in the lab runs at $0.00 per workflow because it is doing structured data processing, not language model inference.

At scale, that is not a trivial saving. An audit agent running on every workflow execution, every day, adds up.

Why this matters more in some industries

For most internal tools and prototype systems, this level of auditability is not the primary concern. If something goes wrong, you debug it. The logs are imperfect but good enough.

For compliance-sensitive environments, the bar is different.

Financial services workflows need to demonstrate, often to regulators, what instruction was sent, by whom, at what time, under what rule set. HR workflows touching payroll or joiners and leavers need an auditable record of every state change and the instruction that triggered it. Legal workflows processing contracts need a record of every decision point and the input that drove it.

In those environments, “we have logs of what the agent wrote” is not the same as “we have a structured, queryable, replayable record of every coordination instruction.” The difference matters when an auditor asks for it.

IETF Internet-Draft draft-mackay-aacp-03 provides the formal specification for organisations that need to reference a defined standard in their compliance documentation rather than an internal implementation decision.

Replay as a test primitive

There is one more property of structured coordination that is worth naming directly: replayability.

When a workflow run is fully captured as a sequence of AACP packets, you can replay it. Take the packet log from last month's payroll run, feed it back through the system with the same data, and verify you get the same output. The coordination layer is deterministic. The replay is exact.

With natural language coordination, replay is approximate. The agent might generate slightly different wording. The receiving agent might interpret it slightly differently. The replay is close but not identical. For debugging, that is inconvenient. For compliance verification, it is a real problem.

AACP makes replay a property of the coordination layer itself rather than something you have to engineer separately.

What this does not solve

To be clear about the limits.

Structured coordination messages do not make task outputs auditable. If the payroll calculation agent produces a wrong result, that is a task-layer problem. The coordination audit tells you what instruction it received, not whether its calculation was correct.

It also does not solve the data provenance problem. If the HR agent retrieves data from the wrong source, that is not visible in the coordination packet alone. You need data lineage tooling alongside coordination auditing, not instead of it.

And it only applies to the workflows you have defined. Novel, open-ended agent interactions that do not follow a repeating pattern are not covered by rule-based encoding. The audit trail for those is still natural language until the pattern has been seen enough times to warrant encoding.

The simplest framing

When one agent tells another what to do, that instruction is a decision. It should be logged as a decision, not as a paragraph.

A typed packet is a logged decision. Natural language is a logged paragraph. The difference is whether the audit trail is a structured record or a document.

For systems where that distinction matters, the coordination layer is worth making structured.

Read on

Read the spec View on GitHub IETF Draft-03 More posts →