When Your Agent Needs to Collaborate With a Vendor's Agent

You wired your agent into a vendor's agent last quarter. The handoff works, the integration tests pass, and then the vendor pushes a model update on a Tuesday afternoon. A week later someone on the support team asks why the resolution notes stopped making sense. You go to reconstruct the decision at the handoff and your trace ends at the request body. Whatever the other side decided, it decided somewhere you can't see.

That's the part nobody scopes for. Internal orchestration teaches you the wrong lesson about control, because everything you built for it assumed a single owner.

The controls you built assumed one owner

Budget is the clearest example. At AI Engineer New York, Anthropic's CJ Avilla and Harrison Stall described dynamic workflows, where a lead agent writes an orchestration program, launches sub-agents, and manages the information flow between them (Latent Space's write-up of the talk). They also said the model doesn't know its own budget while it runs, though developers can set a session budget, and that telling a model its budget might make it "a little bit anxious." The cap sits outside the agent, in whatever platform owns the session.

Cross an org boundary and there are two platforms. Your session budget caps what you spend on your side and says nothing about what the vendor's agent spawns when your request lands. Two control planes, one workflow, no shared ledger.

Context has the same problem. The stock-watchlist example in that talk split work across agents with isolated contexts, a scan phase fanning tickers out and a later review phase examining what came back. Isolation is a feature when you own both phases. Across a boundary it means the vendor's agent can't see the conversation that produced the request, so it fills the gap with assumptions you never get to inspect.

Review is the third version of this. Stall described flows completing "discrete, verifiable units of work without you having to manage any of the interconnections between these things," which holds up when the interconnection is a function call you wrote and fails when it's a request to somebody else's agent. Verification turns into a claim you're taking on faith. Visibility into sub-agent actions came up as an audience question at that same talk, so treat it as open rather than solved.

Specialists beat generalists, which is why you'd cross the boundary at all

Worth knowing what the upside is. A preprint on multi-developer agentic systems reports that on GAIA, a general assistant benchmark, a population of specialized developers whose individual agents don't exceed 35% accuracy reaches 70% when their agents are combined. That combined system lands 12 percentage points above the median general-purpose single-developer agent built with several times each specialist's development budget. The authors call it a preliminary case and it is one. The shape of the result still matters: the gain came from aggregation, so the interface between agents is where value gets created or destroyed.

In that study the developers cooperate on a shared benchmark and can agree on the interface. Across a vendor boundary the interface is a contract, and contracts move on a different clock than your release cycle. The preprint's own framing, developers with diverse capabilities and resources working collaboratively, describes a partnership well and a procurement relationship poorly.

So the research says the payoff is real. It says nothing about whether you can trust the other side. Two separate questions, and the first one doesn't answer the second.

Keep your workflow definition on your side of the line

Own the process, rent the capability. AI-DLC is a useful reference here: a workflow core that runs across coding harnesses including Claude Code, Codex CLI, Cursor, and opencode, configured per project with aidlc config --harness <name>, and stopping at approval gates before moving forward. The design decision worth copying is that the workflow lives outside any single vendor's runtime. Your process definition should be a file in your repo. If it lives as prompt text inside a vendor's console, changing vendors means rewriting the process.

Put the approval gate on your side. The vendor's agent proposes, and your system decides whether the proposal executes. That keeps a human at a checkpoint you control, with a transcript you keep.

There's a cost. A gate on your side adds a round trip, and if the vendor's agent runs its own internal approval steps you'll be waiting on decisions you can't observe. Ask what their gates look like before you promise a latency number to anyone.

Make the handoff artifact structured

Prose is the worst thing to send across the boundary. No schema, nothing to validate, and when it fails you can't tell whether the sender was wrong or the receiver misread it.

Define the artifact. Give it named fields and a version, and state what the receiving agent may do with it. Then record every handoff in both directions: the artifact and the decision that followed. Version that format too. When you're on v3 and the vendor is still sending v1, you want a validator that rejects instead of guessing.

Ask the vendor what their trace looks like and how long they retain it. A vendor who can't answer can still be a fine API provider. They shouldn't be an agent in your workflow.

The first move

Before any integration code, build the joint eval. Take twenty real cases where both agents have to act, run them against the vendor's agent as it exists today, and save the outputs. That set is your regression suite. When the vendor ships a model update, you rerun it and hear about the regression from your own numbers instead of from your support queue. An afternoon of work, and it changes what the next vendor update costs you.

What would change my mind

If vendors start exposing per-call budget accounting and a versioned trace schema for sub-agent activity, most of this gets easier. I'd also relax if I saw two teams running a shared eval suite on a shared cadence, since that's a reasonable test of whether a relationship can carry an agent-to-agent workflow. Until I see one of those two things, I'll keep designing for the boundary.