The one question that separates a real agent consultant from a demo
Ask the consultant sitting across from you: "When the agent is wrong on a Tuesday afternoon, what happens?" A copilot vendor will say the user just ignores the bad suggestion. That answer is fine for a copilot. It is disqualifying for an agent. An agent does not suggest — it acts. It updates the CRM, it routes the ticket, it kicks off the approval, it reconciles the exception. The gap between those two answers is the entire job you are hiring for.
This matters more in a growing B2B technology company than almost anywhere else, because your systems are dense and your headcount is thin. You probably have a CRM, a billing platform, a support desk, a product database, and three or four integrations holding them together with duct tape. An agent that "writes" touches all of them. A 60-person SaaS shop that lets a support agent auto-apply credits has just handed a piece of its revenue recognition to software that nobody on payroll fully understands yet. That is not a reason to avoid it. It is the reason the consultant's first deliverable is almost never an agent.
The first deliverable is usually a map. Before anyone writes a line of agent logic, a serious consultant documents the workflow, the decision rules, the data sources feeding it, the permissions each step requires, the handoffs to humans, and the path back when something breaks. If your renewal process lives in one person's head, that is the first thing they hand you in writing. The research from McKinsey's State of AI work, IBM's Institute for Business Value, and PwC's responsible AI research keeps landing on the same point: the value comes from redesigning how the work flows, not from buying access to a model.
Make them draw the permission grid in front of you
Here is a working exercise that exposes a weak consultant in about ten minutes. Take one candidate workflow — say, a support agent that handles tier-one tickets — and ask them to sort every action it might take into four columns: read freely, write freely, recommend but wait for a human, and never touch. For that support agent, reading the customer's plan and history is column one. Drafting a reply is column two. Issuing a refund over $200 or changing a contract term is column three. Editing the customer's payment method is column four — never. A consultant who can populate that grid quickly has built agents before. One who waves it off as "we'll figure out guardrails during the build" is selling you a chatbot with extra steps.
The failure modes are specific, and they rhyme with your business. A sales agent applies a discount tier it misread from a stale pricing doc, and now your deal desk is unwinding quotes. A support agent confidently cites a returns policy that changed two quarters ago. A finance agent miscategorizes a one-off credit as recurring, and the ARR number you take to your board is quietly wrong. None of these are exotic AI risks — they are ordinary process risks that an agent commits at machine speed, across hundreds of records, before a human notices. The control system is what keeps a small mistake from becoming a reconciliation project.
So beyond the permission grid, ask how the agent gets watched. Where do its actions get logged? What accuracy threshold trips an escalation? Who reviews the permission scope after the workflow drifts — because it will drift? This is the difference between a pilot and production. A pilot answers "can this agent do the task." Production answers "can this company monitor it, maintain it, and catch it when it slips." The pilot-to-production gap is where most agent projects quietly die, and a consultant who cannot describe the production control model has only ever shipped demos.
What you should walk away holding
By the end of a real engagement you should be able to point to artifacts, not enthusiasm: a documented workflow, a data-readiness read on the systems the agent will touch, the permission grid, a defined scope ("this agent does X tickets, not Y"), the list of integrations it depends on, the metrics the pilot has to hit, a register of what could go wrong, an adoption plan for the humans whose jobs change, and a production-readiness checklist. The tell that it is working: your leadership team gets more precise about what the agent does and refuses to do, not vaguer and more excited.
Price should track that complexity honestly. A short diagnostic to identify which workflows are even candidates is one thing. A scoped sprint to build and govern the first one is another. Ongoing support should be priced against monitoring, maintenance, and improvement — the unglamorous work of keeping an agent trustworthy as your data and policies shift — not against a retainer for vague "AI expertise." If the proposal cannot tell you which line item buys the monitoring, that work is not happening.
If you want to do something Monday: take your single most repetitive cross-system workflow and try sorting its actions into those four columns yourself. The ones that all land in "recommend but wait for a human" are your safest first candidates. Run that workflow through the AI Opportunity Score to gauge value against readiness, and when you are ready to build one that has to be governed and integrated, the AI agents and internal copilots work picks up there.
