Narrowing across organisations: why bilateral agent integrations do not scale

Two companies want their agents to work together. A buyer's planning agent needs a quote from a supplier's quoting agent. Today that is done the way APIs were integrated ten years ago: someone issues a key, someone signs a contract, and everyone hopes. This post is about why that stops working at the second supplier, and what authorising agents across two organisations needs instead.

Every integration is a bespoke agreement

Look at how a cross-company agent integration is built today. The supplier issues the buyer a credential. The two legal teams agree what the buyer's agents may do with it. An engineer on each side wires up the calls and writes the limits in a README. The credential is long-lived, because rotating it means another call between the two teams.

Three things are wrong with this, and none of them is the engineers.

The credential is wider than the job. It was issued once for every job the buyer might ever run, so it has to allow all of them. The planner asking for one quote holds the same key as the agent that reconciles invoices.

The limit lives in a document. The contract says what the agent may do. The code does not check the contract. If the buyer's agent asks for more than it should, the supplier finds out in the monthly review, if at all.

Neither side has a record the other accepts. Each company has its own log. When something goes wrong, the two logs disagree, and the dispute is settled by whoever has the better lawyer.

n companies, n squared agreements

Now count. One buyer and one supplier is one agreement. Add a second supplier: two. Add a second buyer who uses both suppliers: four. Every company that joins has to agree with every company it will ever call, pairwise. Ten companies that all trade with each other is forty-five agreements, each with its own key, its own contract and its own README.

This is the bilateral problem, and it is the reason agent-to-agent commerce is mostly demos. Each pair works. The network does not. Every analyst writing about cross-company agents this year says the same thing in different words: the integrations are bespoke, and bespoke does not scale.

The fix is not a better contract template. It is to stop making the permission a bilateral artefact.

A permission that narrows at the boundary

Here is the alternative. The buyer's planner starts a job with a badge issued by the buyer's own directory. The badge says what this agent may do for this job: read this order, request a quote for these line items, nothing else. When the planner calls the supplier's quoting agent, the badge crosses the company boundary. At the boundary it is narrowed to what the supplier's agent is allowed to serve. The result is a new badge for this one exchange, and it can only be smaller than either input.

Neither company sees the other's directory. The buyer does not learn what else the supplier's agent may do. The supplier does not learn what else the planner holds. Each side keeps its own identities, its own rules, its own directory. What crosses is the overlap, and the overlap is enforced at the supplier's door on every call, not read from a contract once a month.

The market term for this is constrained delegation: each hop may hold at most what the hop before it held, and the check is done by the infrastructure, not by a policy document. Across a company boundary, that is the whole difference. The supplier does not have to trust the buyer's agent to behave. It only has to trust its own door.

The order case

A buyer's planner is assembling a purchase order. It calls the supplier's quoting agent and asks for a quote on four part numbers. The badge that crosses the boundary allows exactly that: quote these four. The supplier's door checks the badge, allows the call, and the quote comes back. Both sides write it down.

Then the planner, working from a prompt that said "get the best price", decides it would help to see the supplier's full bill of materials for the assembly. It asks. The badge does not allow it. The request is refused at the supplier's door. The refusal is written down. The buyer's copy and the supplier's copy of the record say the same thing: this agent, this job, this request, refused, outside badge.

No engineer on either side wrote a rule for this case. The supplier never anticipated the planner asking for the bill of materials. It did not have to. The badge only ever said quote these four, and anything else is outside it.

1# before the boundary: issued by the buyer's directory for this job2holder: buyer/planner3job: po-draft4allows:5  - read:order6  - request:quote7  - read:supplier-catalogue8  - write:order-draft9
10# after the boundary: narrowed to what the supplier's quote agent serves11holder: buyer/planner12job: po-draft13counterparty: supplier/quote14allows:15  - request:quote16# read:order, read:supplier-catalogue, write:order-draft: not served here, dropped17# read:bill-of-materials: never held, refused

Two records that agree

The record is the part that replaces the lawyer. Each decision at the boundary, allowed or refused, is confirmed by both sides before it is written, and each side keeps a copy. When the buyer asks why the quote was late, or the supplier asks what the planner tried to read, both open the same record and see the same thing.

This is what makes the network scale. The agreement between two companies shrinks to: we both run a door, we both narrow at the boundary, we both keep the record. That agreement is the same for every pair. Ten companies is one agreement, adopted ten times, not forty-five written once each.

What to take with you

• A shared key and a contract is a bilateral agreement. n companies need n squared of them.
• The permission that crosses a company boundary should be issued per job and narrowed at the boundary. Never a standing key.
• Each side keeps its own directory. What crosses is the overlap, nothing more.
• The refused request nobody anticipated is the point. The badge handles it. The contract never would.
• One record, two copies, both parties confirm. That replaces the dispute with a lookup.

The across-organisations page walks through this with the planner and the quoting agent side by side.