Auditing Friction: A Practitioner's Checklist for Multi-Agent Systems

The first Behaviorist piece argued that choice architecture applies to agentic systems in its own right, not as a borrowed metaphor. This one is narrower and more useful on a Tuesday: what does it actually look like to audit friction in a live multi-agent system, and what do you do once you've found it.

Friction, in the agentic sense, is computational rather than physical: an extra tool call, a longer retrieval, more context an agent has to hold to justify a choice. It is easy to treat as an engineering detail, latency to optimise away, rather than as a lever that is actively shaping which decisions a system reaches. It is both. Treating it only as the first misses a real design surface.

Where to look first

Friction concentrates at handoffs. A single agent working a single task rarely shows much of it, the interesting cases are the points where one agent's output becomes another agent's input, or where an agent has to decide whether to act, log, or escalate to a human. Three places consistently repay a look:

Tool call depth per decision. Count how many tool calls a given decision point requires before the agent commits to an action. Options that require more calls to evaluate are, all else equal, structurally disadvantaged, independent of their actual merit. If your system has one path that resolves in one call and an equally valid path that needs three, you have built a default without meaning to.

Context window pressure near the decision. Look at what else is competing for context immediately before a consequential choice. An agent making a judgement call late in a long context window, with a lot of prior conversation or retrieved documents still in play, is operating under a real form of load. This is the closest agentic analogue to a human making a call while distracted or fatigued, and it is measurable: token count and position in context at the moment of decision.

Escalation cost asymmetry. Compare the friction of auto-executing against the friction of stopping to ask a human. If escalating is meaningfully more expensive, more tool calls, more latency, a worse user-facing experience, than proceeding, the system is quietly biased toward autonomy regardless of what your policy documents say the threshold should be. This is the single most common finding in early audits: the stated policy and the actual incentive gradient point in different directions.

What counts as a finding

A friction audit is not complete when you have a list of slow paths. The useful output distinguishes three categories, because they call for different fixes:

Friction that is accidental and should be removed. An unnecessarily deep tool-call chain that exists because of how the system evolved, not because of any intended design. Fix: simplify the path.

Friction that is load-bearing and should be preserved, possibly increased. A deliberately added check before an irreversible action. This is friction doing its job, and an optimisation pass that treats all latency as waste will quietly remove exactly the friction that was protecting you.

Friction that is misallocated. The escalation-cost-asymmetry case above: friction sitting on the wrong side of the decision, making the safer path the harder one. This is usually the highest-value finding in an audit, because it is invisible in normal operation and only shows up when something goes wrong and someone asks why the system didn't stop to check.

A short worked example

Take a support system where an agent can issue a refund under a threshold, log the action, and move on, or escalate to a human for anything above it. An audit found that the escalation path required the agent to compose a structured summary, wait on a queue placement call, and confirm receipt, three tool calls and a wait state, while the auto-execute path was a single function call. The threshold itself was reasonable. The friction sitting on top of it was not: on marginal cases, close to the threshold either way, the system had a real, measurable pull toward auto-execute that had nothing to do with the merits of the specific case. Collapsing the escalation path to a single call closed most of the gap without changing the threshold at all.

The audit is not a one-time pass

Friction shifts as a system changes. A new tool gets added, a retrieval step gets inserted upstream of a decision point, a model upgrade changes how much context a given judgement call actually needs, and the friction profile moves with it, usually without anyone deciding it should. Treating a friction audit as a launch-gate exercise rather than a recurring one is the most common way a well-designed system drifts into an unintended default six months after it shipped.

None of this replaces the harder design conversation about where autonomy should sit in the first place. It is the maintenance work underneath that conversation: making sure the friction actually built into the system matches the friction someone intended to build, rather than whatever the architecture happened to produce.