Using Multiple AI Vendors at Once: Boundaries and Handoffs

Using multiple AI vendors in a company works when each vendor owns a clearly named system, dataset and class of incident, and when every point where their work meets is written down as a handoff. Overlap and blame appear when ownership is assumed instead of recorded. Settle the map before the first incident, not during it.

Key takeaways

• Assign ownership by system, data, identity and incident, not by contract title or vendor reputation.
• Every boundary between vendors needs a named handoff: what crosses, in what form, and who confirms it arrived.
• Keep one internal owner who decides when vendors disagree. Vendors should not have to arbitrate each other.
• Agree on shared evidence (logs, timestamps, request identifiers) so incidents are diagnosed from facts, not from each side's account.
• Review the map whenever scope, tools or permissions change, and on a regular rhythm even when nothing seems to have changed.

Why do two AI vendors cause problems that one does not?

With one vendor, a failure has one place to go. With two, every failure first raises a question: whose is this? While that question is being argued, the problem stays open, and the people affected (customers, staff, finance) keep waiting.

Three patterns show up again and again. The first is a gap: a task sits between two vendors and each reasonably believes the other covers it, such as rotating a credential or rebuilding an index after a source changes. The second is an overlap: both vendors can change the same setting, and each change surprises the other. The third is a collision of fixes: one vendor repairs a symptom in its layer and breaks an assumption in the other's.

There are good reasons to have two vendors. One may supply a platform or a model while another builds and operates the agent. Your IT provider may run identity, devices and networks while an AI provider operates the agents on top. A specialist tool for one department may sit beside a company-wide agent. If you are unsure which work belongs to which kind of provider, managed AI services or your IT provider covers how to split it.

The point is not to avoid a second vendor. It is to make sure the seam between them is a designed thing, with an owner, and not an accident.

What exactly needs an owner?

Ownership is easiest to assign when you break the work into categories that can each have exactly one answer. Use these as rows in your map:

• Systems: each runtime, integration, connector and scheduled job that makes the agent work.
• Data: each source, each copy, each index built from it, where it is stored, and who may change or delete it.
• Identity and permissions: accounts, tokens and service identities, and who grants, narrows and revokes them. Standard authorization guidance favors least privilege and checking access on every request, which only works if someone is accountable for the grants.
• Behavior and configuration: instructions, rules, model choices and the settings that change how the agent acts.
• Monitoring and logs: what is recorded, where it is kept, and who reads it.
• Changes and releases: who may change what, who must be told first, and who approves.
• Incidents and communication: who triages, who informs staff or customers, and who closes the matter.
• Exit: who can export, hand over and delete, if either relationship ends.

Each row gets one accountable owner. That owner can be a vendor or someone inside your company. Where a component is truly shared, split it by verb: one party may operate it, the other may only read from it. Never write that two parties jointly own something. Joint ownership is how nobody ends up owning it.

If you have not yet drawn the stack these rows describe, start with a one-page architecture map. Every box on that page should end up with an owner's name next to it.

How do you build the ownership map?

The following plan works for two vendors and scales to more. Do it in a single working session with both vendors present, plus the person inside your company who will make the final call.

• List every component, including the unglamorous ones: credentials, scheduled exports, email forwarding, webhooks, spreadsheets that feed an index.
• Name one accountable owner per component. If you cannot choose between two candidates, that is the finding, and the internal owner decides.
• Mark the data each component reads, writes or copies, and note where the copy lives.
• Write each boundary as a sentence: this party delivers this thing, in this form, to that party, on this trigger.
• Agree on shared evidence: which logs exist, how long they are kept, and which identifier lets both sides trace one request across both systems.
• Put the map into the contracts. A statement of work should reference it so that scope, responsibilities and handoffs are not only in a slide deck.
• Walk through one failure on paper. Pick a plausible incident, such as the agent giving wrong information from a stale source, and trace who notices, who triages and who fixes.
• Set a review date and a trigger list: new tool, new data source, new permission, new vendor contact, changed scope.

The walkthrough is the step people skip, and it is the one that exposes the most. A map that has never been tested against a failure is a hypothesis.

What should a handoff contain?

A handoff is any point where work, data or responsibility moves from one party to another. It can be a file delivered each morning, an API call, a ticket raised by an agent to a human team, or a change notice. Each one needs the same few facts written down:

• What crosses: the exact content, not a general description.
• Format and structure: field names, file layout, expected ranges. Structure changes are the most common silent cause of breakage.
• Trigger and timing: what causes the handoff and how often.
• Confirmation: how the receiver acknowledges it, and what the sender does if no acknowledgment comes.
• Failure behavior: what each side does when the handoff is late, partial or malformed. The default should be safe, for example the agent says it cannot confirm rather than guessing.
• Named people: one contact on each side, plus a backup, so the handoff does not depend on one inbox.

One rule covers most of the damage: no change to anything that crosses a boundary without prior notice to the other side. Field renames, new permissions, altered instructions and different models are all boundary changes in disguise. Treat them as such, and use a lightweight request and approval path so that notice is routine and not an event. The approach in how to request and approve changes to a managed AI agent is a good model for the paperwork.

What does this look like in practice? An illustrative scenario

Illustrative scenario: a distribution company has an AI vendor operating an agent that drafts replies to customer questions about order status. The company's IT provider runs the order system and the identity directory. A nightly export from the order system feeds an index the agent reads.

One week, customers start receiving delivery information that is out of date. The AI vendor says the agent is behaving correctly and the data it reads is stale. The IT provider says the export ran on schedule and shows no errors. Each is telling the truth from its own side, and without a shared map, two days go by in message threads.

With a map in place, the same incident reads differently. The export is a documented handoff: IT owns producing it, the AI vendor owns the index built from it, and both log a timestamp. Comparing timestamps shows the export arrived, but the index rebuild skipped most records because a field had been renamed in the order system. The rename was a routine IT change that nobody had flagged as crossing a boundary.

The resolution is simple and, importantly, unargued. The AI vendor rebuilds the index and adds a check that fails loudly when the expected structure changes. IT agrees to announce changes to exported fields before they ship. The internal owner updates the map to say so. Nobody was blamed, because the map had already said where to look.

How should incidents work when two vendors are involved?

Incidents are where unclear ownership costs the most. A few rules, agreed in advance, keep them short.

First, one internal incident lead. This person belongs to your company, has authority to make decisions, and does not take either vendor's side. Their job is to keep the timeline, not to diagnose.

Second, contain before you find the cause. The company should hold the right to pause the agent, narrow its permissions or switch off a specific tool immediately, without waiting for vendors to agree on fault. Containment is reversible. A long dispute is not. The step-by-step permission review helps you decide in advance which permissions can be narrowed quickly.

Third, a first responder owns triage. Whoever receives the report first answers one question: which side of the boundary does this appear to be on? They hand it over with the evidence attached. A wrong guess is acceptable. Silence is not.

Fourth, rely on shared evidence. Common observability practice, traces and logs that carry the same identifier across components, lets both vendors read the same sequence of events. If each vendor can only see its own half, you are back to competing accounts.

Fifth, a short review after each incident that changes the map, not just the fix. If the cause was a gap, name an owner. If it was an overlap, remove one party's access. Frameworks such as the NIST AI Risk Management Framework treat clear roles and accountability as a core part of governing AI systems, and an incident review is the cheapest time to practice that.

How does Be Human handle this?

Be Human often works alongside another provider, such as an IT firm, a software vendor or a platform supplier. A first engagement defines one useful role for the agent, the memory and tools it needs, the approval boundaries and an observable success criterion. In the same exercise, Be Human documents what the agent reads from and writes to, who owns each of those systems, and which changes need notice. Managed operations then cover monitoring, recurring evaluations, integration maintenance, permission review, incident response and controlled improvements, with the agent's identity, memory and permissions kept under the client's control. Where a problem lies in the other vendor's system, Be Human supplies the evidence from its side and works to the agreed handoff, leaving final decisions with the client's internal owner. Service is remote, in English and Portuguese.

When should the map be reviewed?

A map decays when the setup changes and the document does not. Review it at a regular rhythm, and also whenever one of these happens: a new data source or tool is connected, a vendor changes staff or support arrangements, a permission is widened, the agent's role grows, or a contract is renewed. Renewal is an especially good moment, because it is when you can write corrections into the paper that governs the relationship.

Also review after any incident, even a small one. Small incidents are cheap evidence about where the map is vague. And keep the exit rows current: if you ever needed to move a function from one vendor to the other, the export and deletion responsibilities should already be written down.

Frequently asked questions

Is it better to use one AI vendor instead of two? Not necessarily. One vendor reduces the number of seams, but it can concentrate risk and may not cover everything you need. Two vendors are fine when each has a defined role and the boundaries are documented. The risk comes from unclear ownership, not from the number of vendors.

Who should be the single point of contact between the vendors? An internal owner at your company, ideally someone with enough authority to decide and to approve changes. Vendors should each have a named contact, but neither should act as the other's manager. Without an internal owner, disputes default to whichever vendor is louder.

What should contracts say about incidents that involve both vendors? They should state that each vendor will cooperate in diagnosis, share the relevant logs and evidence, and follow the agreed handoffs and triage rules. They should also confirm that your company can pause or restrict the agent without penalty. Referencing the ownership map in the scope of work keeps those commitments concrete.

How often should we review the ownership map? On a regular rhythm that fits your pace of change, and any time a trigger occurs: a new tool, data source, permission or contract renewal. After every incident, review the relevant rows as well. If the map has not been touched for a long time, assume it has drifted and test it with a paper walkthrough.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.