What should I ask before paying someone to build an AI agent for my business?

This one is for a different reader than most of what I write. Not somebody whose app was built by AI, but somebody thinking about paying for AI to do actual work inside their business — reading support tickets and routing them, pulling data out of documents, drafting the weekly report, watching an inbox.

It is a reasonable thing to want and some of it genuinely works. It is also a market with a lot of confident selling in it, so what follows is a buyer's guide assembled from primary sources: specifications, vendor engineering write-ups, published research and disclosed incidents. Where a widely repeated number turns out not to mean what people think, I say so, including when the correction is inconvenient for somebody selling this work. I sell this work.

The three-part question that covers most of the security

There is a framing for agent security that is better than any checklist, articulated by Simon Willison in June 2025. He calls it the lethal trifecta. Three properties:

Access to private data. Your CRM, your inbox, your database, your files.

Exposure to untrusted content. Anything written by someone outside your organisation that the agent will read.

The ability to communicate outward. Send an email, post to a webhook, write to a public place, make a request to the internet.

Any two of these is an ordinary system with ordinary risks. All three together is the configuration where a stranger's text can instruct your agent to take your private data and send it somewhere they can read it.

Now hold your intended use case against it. A support triage agent reads your customer records — private data. It reads ticket bodies written by members of the public — untrusted content. It replies by email — outward channel. That is all three, in the most commonly requested agent build there is.

This does not mean do not build it. It means the design has to deliberately break one leg: the agent that reads tickets does not also hold the credentials to the customer database, or it can draft but not send, or the outward path goes through a person. The question to put to a supplier is not "is it secure" but "which of the three are you removing, and how". If the answer is that all three are present and it will be fine because of careful prompting, you have your answer about the supplier.

Untrusted content is wider than you think

People consistently underestimate this leg. Untrusted content is not just a form somebody filled in. It includes ticket and email bodies, any web page the agent fetches, documents and PDFs it is asked to read, issues and comments in a repository, and — the one that surprises everyone — the results returned by its own tools. If a tool call returns text from anywhere a stranger can write, that text is an instruction channel.

The clearest published demonstration involved a repository integration. A hidden instruction planted in a public issue caused an agent to retrieve contents from a private repository and place them into a public pull request. The researchers who published it were explicit that this was not a defect in the integration's code, and that the vendor could not fix it on their end — it is a property of the arrangement, not a bug in a component.

Keep that structure in mind, because it recurs: the individual pieces can each be working correctly while the system as a whole does something nobody wanted.

Prompt injection is not solved, and better models do not help

If a supplier tells you they have handled prompt injection, ask how, and listen for whether the answer is architecture or detection. Detection is not enough, and the numbers are not close.

A study published in August 2025 tested forty-five real, live integration servers exposing over three hundred genuine tools, with more than thirteen hundred malicious cases, across twenty different models. The highest attack success rate reached roughly seventy-three per cent. The highest refusal rate any model achieved was under three per cent.

The finding that matters most for a buyer is the counterintuitive one: more capable models were often more susceptible, not less. The attack works by riding instruction-following, which is the exact capability that makes a model useful. Safety training does not defend against a legitimate tool being used for an illegitimate purpose, because nothing about the request looks unsafe.

So "we will use a better model" is not a mitigation. Neither is a guardrail model that catches most attempts — Willison's line on this is worth repeating to anybody quoting a percentage at you: in security, catching ninety-five per cent of attacks is a failing grade.

The protocol most of these integrations are built on says the same thing about itself, which I found more persuasive than any third-party analysis. Its specification states that it cannot enforce its security principles at the protocol level, and advises that tool descriptions be treated as untrusted unless the server is trusted. There is no page in the specification about prompt injection. The people who wrote it are not claiming to have solved it.

The supply chain question

Ask which third-party integration servers the build depends on, who publishes each one, and what happens if one is compromised in a point release.

In September 2025 a package impersonating a well-known email service was found to have been backdoored in a minor version update, silently copying messages to an external server. The company whose name was on it confirmed it had never been theirs.

In April 2026 a systemic issue in how these servers launch subprocesses produced a batch of vulnerability disclosures spanning many unrelated products at once, because they all inherited the same pattern. One vendor published a genuinely good postmortem, and their fix is the pattern to ask for: an allowlist of the specific launcher commands permitted, rather than accepting whatever a configuration file says.

And a scan in mid-2025 found at least 1,862 of these servers publicly reachable and answering requests without any authentication at all. That is not a subtle failure. Ask whether any part of your build will be exposed to the internet, and what authenticates it.

The protocol was rewritten in July 2026

Worth knowing before you commission anything, because it has a cost attached.

A new revision of the specification landed on 28 July 2026, and it is a rewrite rather than a point release. Sessions are gone. The handshake that opened every connection is gone. Server-initiated requests — including the mechanism used for asking a human a question mid-task — have been replaced with a different pattern entirely. Several capabilities are deprecated under a new twelve-month clock.

Two consequences for a buyer. Anything built against the previous revision is facing rework, and if you are being quoted for maintenance of an existing agent system, that work should be named in the quote rather than discovered later. And if you are commissioning something new, ask which revision it targets. "The current one" should be a boring question with a boring answer.

On authorization the picture is better than it was. Authorization remains optional overall, but where it is implemented over the web the requirements are strict: modern OAuth, discovery metadata, and — the important one — a server must validate that a token was actually issued for it, and must not accept or pass along tokens issued for somebody else. That last rule exists because forwarding a token you were handed is the natural, obvious, wrong thing to build.

The operational questions, which will cost you more

Security failures make the news. Operational failures make the invoice.

Token economics. Anthropic's own engineering write-up gives the ratios: agents use roughly four times the tokens of ordinary chat, and multi-agent arrangements roughly fifteen times. That is not a criticism, it is a budgeting fact. Ask what the expected cost per run is, and ask why a multi-agent design is justified if one is proposed — the same write-up notes that the pattern suits parallel research and fits poorly where steps depend on each other, which is most business workflows.

Loops. The characteristic agent disaster is not a crash. One practitioner published an account of an agent that met repeated rate limits, re-planned, and retried around forty-eight hundred times an hour for sixty-three hours, at a cost of several thousand dollars — because the instruction was to keep trying until it worked and there was no ceiling of any kind. I will flag that this is a single-author account without published logs and I cannot independently confirm the figures. The failure shape is real regardless, and so is the fix: hard limits in money, tokens and wall-clock time, with escalation rather than retry when they trip.

Context degradation. Long-running agents accumulate context, and recall accuracy falls as they do — Anthropic's engineering team calls it context rot and frames context as a finite attention budget rather than a container to fill. So "give it more context" is not a fix, and a design that just keeps appending will get worse over a long task rather than better.

Non-determinism. Agents behave differently between runs with identical inputs. This breaks conventional debugging, because there is often no reproducible case to attach to a bug report. The practical requirement is tracing: if a supplier cannot show you the full trace of a failed run end to end, there is no way to diagnose anything later.

Statefulness. An agent holds state across many steps, so a small failure late in a run destroys everything before it unless there are checkpoints. Ask whether a failed run resumes or restarts.

The question nobody asks, and should

Not "does it work" but "does it work the same way twice".

Benchmark scores are single-run numbers, and single-run numbers systematically overstate production reliability. The metric that actually predicts whether a support-triage agent is deployable is whether it handles the same case correctly on the fifth and eighth attempt, not the first. There is a family of benchmarks built around exactly this idea, and while the published absolute figures are old enough now that quoting them would mislead you, the concept transfers cleanly.

Ask the supplier to run your twenty most representative cases repeatedly and show you the spread, not the best result.

The statistics you will be quoted

You will meet two numbers in every conversation about this, pointing in opposite directions. Both are weaker than they sound, and knowing why is useful in a sales meeting.

"Ninety-five per cent of AI projects fail." This comes from a report published in mid-2025. What it actually measured: fifty-two structured interviews and one hundred and fifty-three survey responses gathered from senior leaders at conferences, plus a review of publicly disclosed initiatives. The ninety-five per cent refers to organisations reporting zero measurable return on generative AI spending — not to agent projects failing. And the report's own funnel undermines the headline: around eighty per cent of the surveyed population never piloted a custom tool at all. A subsequent analysis put it well — this counts people who never went on a date as having failed marriages. It is also worth knowing that the document was not publicly downloadable when the figure went viral, and that its authors work on the class of technology it recommends as the remedy.

"Forty per cent of agent projects will be cancelled by 2027." That is an analyst forecast rather than a measurement, and the only underlying data disclosed is a poll of webinar attendees about their investment posture, which does not support the specific figure.

And the optimistic counter-number — a vendor survey of five hundred-odd technical leaders reporting that eighty per cent see measurable return — is a survey of buyers already committed, with return self-assessed and undefined.

The honest summary is the one nobody says out loud: there is no rigorous, independent, publicly readable study measuring what proportion of production agent deployments succeed. Anyone quoting you a number in either direction is quoting something that measured a different thing.

The one rigorous measurement, and it is about people

The most methodologically clean study in this entire area is not about agents at all, and it is the one I would most want a buyer to know.

In mid-2025, sixteen experienced open-source developers worked through two hundred and forty-six real issues in their own codebases, with AI assistance randomly assigned per issue. They were nineteen per cent slower with the tools. They had predicted a twenty-four per cent speedup beforehand, and afterwards — having just been measurably slower — they still believed they had been about twenty per cent faster.

The researchers were careful about the limits: a small sample, experienced developers on familiar code, and results that should not be generalised to everybody. Take the narrow finding and it is still the most useful thing in this article: self-reported productivity from AI systems is systematically unreliable, and every survey in the previous section depends entirely on self-reporting.

The practical implication is not cynicism. It is that you should insist on measuring the actual outcome — tickets resolved, minutes saved, errors caught — rather than asking your team whether it feels faster. They will say yes. They said yes when they were slower.

The questions, in one place

On security: what private data can it reach, what untrusted content will it read, where can its output go, and which of those three are we removing? Are tool results treated as untrusted input? Which third-party servers does this depend on and who publishes them? Is anything exposed to the internet, and what authenticates it? Do we ever forward a token that was issued to us for something else?

On the build: which protocol revision does this target, and what is the rework cost if we are on an older one? Show me the trace of a failed run.

On money: what are the hard ceilings in currency, tokens and time, per run and per agent, and what happens when one trips?

On quality: what is the evaluation set, who owns it, does it run before every prompt and model change, and what is the spread across repeated runs of the same case? How would we notice quality degrading three months from now?

On oversight: exactly which actions require a human, and on what trigger?

What agents are actually good at right now

I would rather end with the honest scope than a pitch.

They are genuinely good at reading unstructured text and deciding what it is about, at drafting things a person will review, at retrieval, at first-pass triage, and at the tedious middle of a process where the input is messy and the output is checked. That is a real category and there is real money in it.

They are not reliable for unattended irreversible actions. They are inconsistent across repeated runs in a way that ordinary software is not. They confabulate confidently — Anthropic's own report on a hostile use of its models notes that the attacker's agent invented findings and credentials that did not work, which is a strange kind of reassurance and a clear warning. And the cost failure mode is unbounded by default.

A supplier who says all of that to you before taking your money is more likely to build you something that works than one who does not.

If you want to talk it through

If you have a workflow in mind and you are not sure whether it is an agent problem, a plain automation problem, or a process problem wearing a technology costume, that is worth twenty minutes before it is worth a budget.

Send me a description of the workflow — what comes in, who touches it, what the output is, and what happens when it goes wrong today. I will tell you which of the three it is, and if the answer is that you do not need an agent I will tell you that too, at no charge and with nothing attached.

The agent and integration work I do is described on the Claude AI automation page. If the question underneath this is really about whether you need a person at all now that the tools are this good, that is do I still need a developer. If it is about choosing who to work with, the general version is in how to hire someone to fix an AI-built app. And the related question of what these systems can legitimately read once you connect them to your business is in who can read your code and your data.