Opinion · The buying committee · Evaluation discipline for the agent eraAfter the dazzle
The vendor demo decides most MarTech procurement.
In the agent era, the dazzle is the least useful part of the evaluation.
Forty-two percent. That is the average MarTech stack's utilisation rate, the loudest signal a buying committee has of its own past performance, and the one most committees ignore. A typical procurement cycle runs eight months. Requirements, longlist, shortlist, demos, references, business case, negotiation, contract. Within thirty months, roughly one in three platforms procured this way is on the replacement list. The pattern has held for as long as MarTech has been a category. The agent era will not let it hold for another cycle. The people in the room when it stops holding are not procurement officers. They are the CFO, the CIO, the CRO and the CMO. Procurement runs the cycle. The buying committee owns the decision.
Why the demo no longer predicts behaviour
Three reasons the demo has lost predictive power.
Vendor demos run on curated data. The dataset is chosen to make the platform look right. The customer's actual data, integrated three months later, makes the platform look different. The agent era widens this gap, because agent behaviour is far more data-sensitive than the rule-based systems that came before.
Agent capabilities are non-linear. The same agent that runs a credit-decline conversation well may fail catastrophically on a fraud-block escalation. Enterprise pilots routinely report fifteen to twenty-five point accuracy drops between the demo environment and production data. The cases that matter to the regulator are typically the ones the vendor did not demo.
The regulatory context has changed faster than the deck. Five major regulatory drafts on agent accountability arrived inside an eighteen-month window: the RBI FREE-AI Framework, the EU AI Act high-risk provisions, the CBUAE Guidance Note, SAMA's annual revision and the Fed/OCC SR 11-7 rescission. By the time the buying committee reviews the vendor's reference deck, the references have not been audited under the regulations that apply to the customer.
The new buying question
The old buying question was does the platform match the requirements? The new one is does it hold up under the conditions the customer will actually face? That requires evidence the demo cannot provide.
Five questions the demo cannot answer
The buying committee for the agent era has five questions to ask. None are answered by the vendor's deck.
| The buying question | What the demo answers | What the customer actually needs to know |
|---|---|---|
| Does it work for me? | It works for the demo dataset. | Does it produce verified lift on a holdout cohort in the customer's own data, before go-live? |
| What is the actual TCO? | The license price. | The license plus integration, change management, ongoing operations and opportunity cost, over five years. |
| Is it audit-ready? | The vendor says yes. | Are reason-coded decision logs produced as a by-product of every decision, exportable in the customer's regulator's format? |
| Who carries the failure? | Read the indemnification clause. | What is the cost of failure to the operating model, and which line of the business absorbs it? |
| Can the customer leave? | The contract has an exit clause. | What is the actual cost of leaving, including the data, the models and the integrations? |
The dazzle is what the room remembers. The regulator reads the evidence.
The buying committee the agent era needs
The buying committee for the agent era is not a vendor-selection function. It is an architecture-selection function. The evaluation runs on the customer's own data, in the customer's own environment, against the customer's own regulator. The vendor demo is a screening step, not the decision. The decision is made on audit-grade evidence produced before the contract is signed.
The POC the agent era requires
The buying committee's instrument is the proof of concept. The word is familiar. Most buying functions have run one. Most have run something else: a vendor sandbox with the customer's logo and a curated dataset rebadged as a pilot. A POC, properly understood, is on the customer's terms. The customer's data. The customer's metric. The customer's cohort. The customer's regulator. A demo extended is not a POC. The agent era ends the polite ambiguity between the two.
The POC the buying committee owns has four properties. It runs on the customer's data, not a vendor sandbox. It tests a cohort defined by the committee, not by the vendor. It measures the customer's outcome metric, not the vendor's accuracy claim. It is signed off in writing, before contract. The first three define the test. The fourth defines who owns the decision.
What the surviving architecture looks like
The platforms that survive this POC are unlike most current MarTech. Their reasoning is produced as a by-product of every decision, exportable in the regulator's format, so the audit trail the POC tests is the audit trail the regulator audits. Their pricing aligns to decisions made, not to seats licensed, so the buying committee can hold the cost to the outcome. The customer's data and the audit trail stay with the operator, not the vendor, so the POC tests something the operator will still own at year five. These platforms were built for regulated enterprise from the start, so they arrive at the POC already audit-grade. The agent era turns this from wish-list into entry criterion, first on MarTech, then on every agent-driven platform the same committee will sign for.