Everything in this series so far has been written from the vendor’s chair. Flip it. If your organisation is going to run agents that call your vendors’ tools, then the questions you ask during evaluation, and the terms you insist on, decide how much of the resulting value you keep. Most procurement processes are still asking about seats, uptime and roadmap. The questions that will matter in three years are different, and almost nobody is asking them yet.
Demand outcome-level tools, not CRUD
Ask to see the vendor’s tool surface before you sign, and look at what the tools actually do. If the surface is a thin wrapper over their database — create, read, update, list — then every piece of domain judgment has to be supplied by your agents, written by your teams, and maintained by you forever. You are buying storage and inheriting the hard part.
A vendor exposing genuine outcomes — settle this, validate that, run the check — is doing the work you would otherwise have to encode yourself. That difference is worth more than most line items you currently negotiate, and it never appears in a feature comparison.
Put the accountability surface in the contract
When an agent acts through a vendor’s tool and something goes wrong, you will need to answer three questions: what happened, on whose authority, and can it be undone. Establish before signing that the vendor exposes all three — a replayable record of the call and its result, an approval mechanism that captures a named human where one is required, and a reversal path that is a real operation rather than a support ticket.
This is not a nice-to-have in regulated work; it is the thing your auditor will ask for. It is also, conveniently, the capability that separates serious vendors from ones that shipped a server to answer an RFP question.
Refuse per-seat for agent traffic
Per-seat pricing made sense when a seat meant a person doing a person’s amount of work. Agent traffic breaks that arithmetic, and for a while the break runs in your favour. Expect vendors to correct it — the smart ones will move to metered or outcome pricing, and you would rather negotiate that transition deliberately than absorb it at renewal.
Push for a model where the price tracks delivered value: a predictable platform floor plus metered usage. Insist the meter is something you can independently observe and reconcile. A number only the vendor can calculate is not a price, it is a trust exercise.
Negotiate portability while you have leverage
The protocol makes substitution technically easy, which vendors know and which makes contract terms the real battleground. Get explicit rights on the way in: bulk export of your data in a usable form, on a defined timetable, without a professional services engagement. Clarity on who owns the configuration, the mappings and any rules your teams built inside their system. And a clear position on the schema — if the vendor’s entity model is becoming your organisation’s vocabulary, understand that this is a switching cost accruing quietly against you.
Watch where the lock-in actually moves
This is the part most buyers miss. If protocols commoditise your vendors, the natural conclusion is that you gain power. You do — over the vendors. But the context, the memory, the accumulated record of how your organisation works, and eventually the workflows themselves start accumulating in the orchestration layer instead.
Whoever supplies that layer is acquiring the position your application vendors used to hold, with better information and less scrutiny, because it was procured as tooling rather than as a system of record. Apply the same four tests to your harness that you apply to your vendors, and be deliberate about whether that context is portable, exportable, and yours. The failure mode here is escaping vendor lock-in and walking into a deeper version of it without noticing.
Evaluate vendors by what survives being called
A practical reframing for the evaluation committee: assume the vendor’s interface is irrelevant, because for your agents it will be. Strike the demo from the scoring. What is left?
If what remains is an authoritative record, data you could not reconstruct, a network you need access to, or an accountability position you cannot take on yourself, you are buying something durable and should be willing to pay for it. If what remains is a well-designed screen over capabilities available in three other places, you are buying a component, and you should price and contract accordingly — short terms, strong exit rights, no deep vocabulary entanglement.
Five questions to put in the next RFP
Show us your tool surface — which of these tools performs a complete outcome rather than a data operation? · What does your audit trail record for an agent-initiated action, and can we replay it? · How does your pricing behave when calls grow but headcount doesn’t? · What exactly can we export, in what format, and how quickly, without your professional services? · Which parts of our configuration and vocabulary would we lose if we left?
None of these are hostile questions. A vendor that has thought seriously about being callable will have good answers ready, and the ones that do not will reveal it quickly — which is the entire purpose of asking.
When Your Product Becomes a Tool — a five-part series on MCP and incumbent strategy
- When Your Product Becomes a Tool
- What Dissolves When You Become Callable
- Substrate or Façade — Who Survives Being Called
- The Incumbent’s Playbook for an MCP World
- Buying in an MCP World — you are here
Related: Service-as-Software — What the Hypergrowth AI Startups Figured Out · Buy, Build, or Orchestrate — and Why Seat-Based Pricing Is the Fault Line.
Leave a Reply