How to tell a real AI partner from a script-reader

Six questions a script-reader can't answer well

1. "What would you tell us not to do?"

A script-reader sells you everything you ask for, because every yes is revenue. A real partner has a list of things they will talk you out of, and they will start saying no in the first meeting. If the firm agrees with every idea you float, that is not enthusiasm, it is a sales motion. Ask them what they would refuse to build for you and why. The good ones have a ready answer.

2. "Show me something you built and run yourself."

Builders operate their own systems in production and can show you one. Script-readers show you a diagram of someone else's. There is a tell in how they talk about it: a builder will volunteer what broke, what it costs to run, and what they would do differently. A firm that has only ever specified and handed off cannot do that, because they were never on the hook when it ran at 2 a.m.

3. "What is the operating-model change here, not just the tool?"

This is the whole series in one question. A script-reader leads with the platform: the model, the copilot, the integration. A real partner leads with the work: which process changes, which behaviors change, who does what differently on Monday. If the answer is mostly product names, you are buying a bolt-on. If the answer is mostly about how the work gets redesigned, you are buying the thing that actually pays off.

4. "What does this cost per unit at scale, and when would you kill it?"

Ask for unit economics and a kill threshold. A real partner can talk about cost per task or per interaction and will propose a number that ends a pilot if it does not perform. A script-reader talks about ROI in vague multiples and has no kill criteria, because their incentive is for the engagement to continue, not to end on a clean decision. The willingness to name a number that could end the work is one of the most reliable signals you will get.

5. "Who owns it when you leave?"

A real partner builds for handoff: your team learns the system, gets the runbook, and can operate it without them. A script-reader builds for dependency, the deliverable is a black box that only they can maintain, and the maintenance retainer is the actual business model. Ask directly what your team will be able to do on their own after the engagement ends. Vague answers here are expensive later.

6. "Can my team see the prompts, the code, and the reasoning?"

Transparency is a proxy for confidence. A real partner hands over the prompts, the code, and the logic, and is comfortable having your security and engineering people pull it apart. A script-reader gets cagey about the "proprietary methodology," which often means there is less underneath than the deck implies. If you cannot inspect it, you cannot trust it, and you certainly cannot own it.

The one that breaks the script

If you only ask one, ask this: "What did your last engagement get wrong, and what did you change because of it?"

A builder answers immediately, because building means being wrong in public and fixing it. A script-reader cannot answer, because admitting a miss is off-script and because, often, they were never close enough to the running system to know what went wrong. The pause after that question tells you most of what you need to know.

Test us with these too

I am giving you these questions knowing they get pointed back at us, and that is the point. Ask SDS what we would tell you not to build. Ask us what we run in production and what it costs us. Ask us who owns it when we leave, the answer is you, every time. We would rather lose a deal to these questions than win one we should not have, because the engagements that go wrong are the ones that should have failed the test at the start and did not get asked.

That is also why we turn down bolt-on work. Not as a principle to put on a slide, but because we have watched what happens downstream when a firm says yes to a bolt-on it knew was wrong, and we would rather not be the firm in that story.

What this is not

This is not a claim that every large firm is a script-reader or that only small shops can build. Plenty of big firms have real builders inside them, and plenty of small ones are running a script. Size is not the signal. The answers are. And it is not a claim that you should never buy a scoped, well-understood thing off a playbook, sometimes the work really is standard and a playbook is the efficient way to do it. The test is whether the firm knows the difference and tells you honestly which one you are buying.

One-sentence takeaway

You cannot tell a real AI partner from a script-reader by the pitch, you tell them apart by whether they will say no, show you what they run, name a kill threshold, hand it to your team, and tell you what they got wrong last time.