When agents cross company lines

A2A lets one company's agent hand work to another's. Why the record has to travel with the work, and the three small additions in OWG v0.93 that make it do so.

October 2026 · About the v0.93 draft

Follow one localized episode through a production today. The studio licenses a title into a new territory. A production company takes on the localization. A dubbing house records the French track, and a post facility conforms it to picture and packages the delivery. Every handoff is a turnover: files move, an email confirms, and someone updates a spreadsheet so the next person knows where things stand.

Over the next year, more of those handoffs will happen between agents. The studio's agent will hand the job to the production company's agent, and that agent will hand the dub to the dubbing house's agent. The people stay accountable, but they will not be retyping instructions at each step.

The plumbing for this now exists. What it does not carry yet is the record.

A2A moves the job

The Agent2Agent protocol (A2A) reached v1.0 in April 2026. It is an open standard, governed alongside the Model Context Protocol, and the major cloud agent platforms already support it. An agent publishes an Agent Card at a well-known address on its domain, listing its skills and how to reach it. Another agent reads the card, sends a task and follows it to completion: submitted, working, perhaps paused waiting for someone's approval, then completed, failed, canceled or rejected. Results come back as artifacts.

The design keeps each agent private. You learn what the other agent produced and nothing about how. For work that crosses company lines, that is the right call: a dubbing house's methods are its business.

What the protocol leaves out

That same privacy leaves three questions unanswered, and a production cannot do without the answers.

What does the task mean? A2A carries a message. It does not say that "localize-dub" means a French track, conformed to a particular edit of a particular master, for a particular territory, due on a particular date.

Who allowed it? Each hop checks its own caller. Nothing records that the dubbing house's agent may read the masters because the production company's agent said so, and that the production company was allowed to say so because a named person at the studio delegated the job. Nothing says when that permission ends.

What happened across the whole chain? Each organization sees its own tasks. Nobody holds the line from the delivered French track back to the person who approved the deal. Rights tracking, AI disclosure and every "who touched this?" question depend on that line.

These questions are not new. OWG already answers them for turnovers between people, through tasks, participants, operated_by and run records. The job in v0.93 was to make the same answers hold when the other side is an agent.

Three small additions

The draft adds three optional fields.

{
  "id": "localize_audio",
  "executor": { "type": "a2a", "ref": "localize-dub" },
  "performed_by": "vendor_dub_agent",
  "delegation": { "by": "ops_lead", "scope": ["read:masters"], "expires_at": "2026-12-31T23:59:59Z" },
  "used": ["masters"],
  "produced": ["dub_tracks"]
}

a2a as an executor type. The task is handed to another party's agent, and ref names the skill on its card. A dubbing house reached this way sits in the same graph as one reached through an API or an MCP tool. Only the executor differs.
agent_card on the participant. The remote agent is a participant like any other, with the address of its card. The card identifies it. It grants it nothing.
delegation on the task. This field records who on the sending side handed the work across, what the receiver may do with it, and when that lapses.

One rule makes the third field matter. Authority only narrows. If the production company was given read:masters, it cannot hand on write:deliverables as well. The validator rejects the wider grant. Follow the delegation fields back from any output and you reach a person at the company where the work began, with the scope getting smaller, never larger, at each step.

How it gets used

Publishing a workflow as an agent

A post facility that has a delivery workflow written in OWG can offer it to other companies' agents. The card comes straight from the definition: its identifier names the skill, its objective describes it, and its parameters list what a caller must send. The card describes the capability only, never the tools or suppliers behind it. This needed no schema change.

Using a partner's agent as one step

A media operations team runs a delivery with one vendor called through an API, one through an MCP tool, and one through its agent over A2A. Everything those vendors produce lands in the same archive step and the same lineage.

A partner's approval in the run record

When the partner's agent pauses for its own producer's sign-off, the attempt in the run record shows "running, input required", with the partner's task id. A refusal and a breakdown are both recorded as failures, with different codes, because they are different events.

The chain across three companies

Studio to production company to dubbing house becomes three tasks, each with a delegation. The French track traces back to the studio executive through document fields alone, with no shared database and no reconciliation by file name.

How we checked it

We wrote each use case as an OWG document and validated it twice, against v0.92 and against the v0.93 draft. That shows which use cases already worked and which needed something new:

Use case	What it needed
Publishing a workflow as an agent	Nothing new
A partner's approval, shown in the run record	Nothing in the schema; a mapping in the run record
A step performed by a partner's agent	The `a2a` executor and `agent_card`
A failed QC check routed to the partner's agent	The `a2a` executor
A turnover delivered over A2A	The `a2a` executor; the turnover itself unchanged
Hundreds of titles fanned out to one partner	The `a2a` executor; fan-out unchanged
One record across studio, production company and vendor	`delegation`

Every v0.92 document is still valid under v0.93. The reference workflow, a2a-deal-to-delivery, runs a closed licensing deal through API, MCP and A2A vendors and confirms delivery back to the sales team that closed it.

What it does not do

OWG declares authority. It does not enforce it. A document can say the dubbing house may only read the masters, but the systems on each side still have to check that. Standard delegated credentials for agents are being worked on at the IETF, and delegation is where such a credential would be recorded once one exists. Scope names like read:masters are not yet a shared vocabulary either, and agreeing on one is work for the industry, not a single specification.

Review it

v0.93 is a draft. The A2A binding has the full mapping, the changelog lists every change, and the schema is published. If you run delivery, localization or post across company lines, the useful question to ask of it is whether the record it keeps is the one your rights, compliance and operations teams would need to find later.