Multi-Agent Systems Need Tiers, Not a Single Policy

On August 10, Australia’s Department of Industry, Science and Resources published the first report of the Australian AI Safety Institute, written by Gradient Institute. It adds little to the usual list of risks inside one company. Its subject is what happens when agents interact across organisational boundaries, with partners, customers, suppliers, and counterparties nobody has vetted.

The report starts from a premise most agent policies skip: a system made up of individually safe and reliable agents is not necessarily a safe and reliable system. Failures emerge from the interactions themselves, and when the agents belong to different organisations, no single organisation’s controls reach all of them.

The framework is simple enough to steal. Three tiers, sorted by who can still reach the system.

Tier 1, singular governance: one organisation governs every agent and can specify, inspect, monitor, and intervene on each of them.

Tier 2, federated governance: several organisations deploy agents into a shared environment under agreed rules. Nobody controls the whole, and new failures appear when incentives diverge.

Tier 3, open environments: agents operate through public infrastructure with no central authority. Whatever governance exists comes from voluntary standards.

The sentence that matters for buyers: the controls available for a given risk, and who can apply them, depend on how much governance the interacting agents actually share, and not on the agents’ architecture, task, or scale. A policy written for Tier 1 stops at the edge of Tier 1.

One agent policy for the whole firm is a filing error. The tier is the control surface.

What actually changed

Most firms still write one page titled “AI agents.” It names a model, a reviewer, and a hope that staff will stay inside the tools the firm bought.

That page assumes singular governance. It assumes you can see every handoff, isolate context, and pull a credential. The moment your coding agent opens a ticket in a vendor’s system, or a customer’s agent calls your API, you have left Tier 1.

The report organises what goes wrong into four failure types: miscoordination between agents, propagation and contagion of errors or data, strategic and incentive failures, and infrastructure and environment failures. Which ones you face depends on the tier, and each tier carries forward the risks of the one before it.

In Tier 1 the question is whether your own agents work well together. The report’s example deserves a place in every steering deck. In one public experiment, an agent hallucinated a contact list and asked another agent to use it. The second agent created an empty file whose name implied 93 contacts. The rest of the group read the file as proof that the list had existed and been corrupted, and pivoted to “recovering” it, even as humans repeatedly said the list had never existed. Nobody outside the organisation was involved. The controls the report points to are internal: structured handoffs with defined schemas instead of free text, deliberately diverse models so agents do not share the same blind spots, an orchestrating agent that keeps the group on task, and checkpoints to roll back to a last-known-good state.

In Tier 2 the new problem is split ownership. Your reviewer does not sit on the other organisation’s agent. Each agent can pursue its own principal’s goals rationally and still produce a harmful outcome; the report’s example is algorithmic collusion on pricing that nobody instructed. The control becomes the shared framework: conditions of participation, shared infrastructure, and monitoring across the whole population of agents. If a partner’s agent can write into your case file, your policy covers half the system.

In Tier 3 the default is distrust. The report offers two paths. Lock the agent’s scope down, with limited tools, limited permissions, and narrow goals, accepting less autonomy in exchange for control. Or deploy agents that implement voluntary standards and deal only with peers they can verify at run time. The report calls the second path polycentric governance and warns that it carries new risks of its own.

Last week supplied a live Tier 3 example. The report’s illustration of an infrastructure failure is a Sybil attack: one agent presenting itself as many counterparties, fabricating identities to manufacture false consensus. That is close to what the UK AI Security Institute reported on August 4, when an agent built fake identities on GitHub to pressure a real maintainer into approving malicious code. Inside AISI’s lab, the agents sat in Tier 1. The harm landed in Tier 3.

None of this is exotic. It describes what a support agent and a billing agent do when they agree on a refund the finance policy forbids, or what two procurement agents do when they learn to clear each other’s exceptions.

Why owners should care now

Mid-market firms already stand in more than one tier without naming them.

The internal knowledge assistant that only reads SharePoint is Tier 1. The same assistant with a connector into a client’s data room becomes Tier 2 the day the client’s agent writes back. The coding agent that can open a public pull request is touching Tier 3, whatever the architecture slide says.

The failure mode is a single steering-committee policy that treats all three as “the agent program.” It sets one reviewer SLA, one model, one logging rule. Then a federated workflow fails in the gap between two firms, and each side points at the other’s acceptable-use page. Banning every tool that leaves the tenancy fails in the familiar way: staff reconnect them.

The false comfort of “we govern our agents”

You govern the agents you can reach. That is the whole point of the Australian map.

Singular controls such as structured handoffs, model diversity, orchestration, and rollback still belong on Tier 1 systems. They do not follow the agent onto a partner platform. Federated work needs a participation agreement: what the other agent may read, what it may write, how disputes are logged, and who eats the defect. The report’s analogy is aviation: a flight from Sydney to Singapore involves two regulators and two air-traffic systems and stays routine because a shared framework spans both. Open work needs a default deny on identity, payment, and outbound merge, plus a rule for which public counterparties are even eligible.

Last week’s eval story and this week’s tier story are the same argument from two ends. An eval with the internet on grants no write permission. A policy written for agents you own does not cover agents you meet.

DNLA Playbook for Multi-Agent Tiers

• Inventory agents by tier, not by vendor. Singular, federated, or open is the first field on the register.
• Do not promote a Tier 1 assistant into Tier 2 by adding a connector until the participation rules exist.
• Replace free-text handoffs with structured messages wherever two agents pass work.
• Diversify models where agents check each other’s work. A monoculture shares its blind spots.
• Isolate context per task and per counterparty. Shared memory across organisations is a leak with a logo on it.
• Name who can stop which agent. If the answer is “their admin,” you are no longer in Tier 1.
• For open-environment tools, default deny identity creation, unsolicited messages, and public writes. Put residual cross-organisation risk in the contract: if their agent writes into your system, the statement of work has to say who owns the defect.

DNLA Take