Key takeaways
- Ask for evidence of systems running in production. A polished demo is weak evidence.
- A strong partner maps your workflow before quoting and writes the acceptance test down before the build starts.
- Human approval, exception paths and failure handling should be designed per action type, with limits and an audit trail.
- You should own the accounts, code, prompts and documentation, with access you can revoke.
- A sensible first engagement is small, paid, and ends in something you can use even if you stop there: a map, a written scope, an acceptance test and a fixed price.
Why is choosing a partner harder than it looks?
The market is crowded and the labels are loose. In June 2025 Gartner described "agent washing", the rebranding of existing assistants, RPA and chatbots as agentic AI, and estimated that only about 130 of the thousands of agentic AI vendors are real. Gartner also predicted that over 40% of agentic AI projects will be canceled by the end of 2027, citing escalating costs, unclear business value and inadequate risk controls.
None of that tells you whether a specific partner is good. It does mean a polished demo is weak evidence. The questions below test how a partner works, which is harder to fake.
Which 12 questions should you ask?
Group them into evidence, method, control and ownership. Ask all twelve before signing anything larger than a scoping engagement.
| # | Question | Good answer | Red flag |
|---|---|---|---|
| 1 | Can you show a system of yours running in production today? | A live walkthrough, with what it handles and what it does not | Only slides, mockups or a sandbox demo |
| 2 | Which parts of that evidence are client work and which are your own builds? | A clear label on each example | Blurred provenance or unnamed "clients" |
| 3 | What went wrong on a past project and what did you change? | A specific failure and a specific fix | No failures |
| 4 | What do you need to see before you can quote? | The workflow, records, owners and exceptions | A fixed price after one call |
| 5 | How do we define done? | A written acceptance test agreed before the build | "When you are happy with it" |
| 6 | How do you handle exceptions and failures? | Named exception paths, retries, alerts and a fallback to a person | Only the happy path is discussed |
| 7 | Which of our existing tools will you use? | Your current stack first, new tools only when needed | A mandatory platform they resell |
| 8 | Which actions will need human approval? | A list per action type, with limits and an audit trail | "The AI handles everything" |
| 9 | How do you test before launch? | Real cases run in review mode against the acceptance test | Testing only on sample data |
| 10 | How is our data handled and where is it processed? | Named processors, regions, retention and access | Vague or unwilling to put it in writing |
| 11 | Who owns the accounts, code, prompts and documentation? | You do, in your own accounts | Everything lives in the partner's accounts |
| 12 | What happens after launch? | A defined operate option and a documented handover option | Open-ended retainer with no handover path |
Which red flags are worth walking away from?
Some answers should end the conversation, whatever the price.
- Guaranteed savings, headcount reductions or revenue figures before anyone has seen your records.
- No written acceptance test, or a refusal to put one in the contract.
- Credentials, workflows and prompts kept in the partner's accounts with no export.
- Every problem solved by "an agent", including routine work that a rule would handle.
- Case studies that cannot be verified and are not labelled as client work or internal builds.
What does a sensible first engagement look like?
A good first engagement is small, paid and ends in something you can use even if you stop there: a map of the workflow, a written scope, an acceptance test and a fixed price for the install. The install follows, with review mode before any action is automated, and ends with either an operate agreement or a documented handover.
Outproduce starts with a free 20-minute call. An assessment is optional and depends on the engagement. We agree the written scope and acceptance cases before the build, including which actions need approval. Ongoing operation or handover is set out in the agreement. Whichever partner you choose, ask them to describe their path in the same concrete terms and say which stages are optional.
Frequently asked questions
Should a partner be tool-agnostic?
They should start from the tools you already run and explain why when they recommend something new. A partner who needs every client on the same platform is usually selling the platform.
Who should own the accounts and credentials?
Your company. The partner should work in accounts you own, with access you can revoke, so the system keeps running if the relationship ends.
How long should a first install take?
It depends on the systems and exception paths involved. Ask for a written timeline tied to the acceptance test rather than a general estimate, and check that review mode is included before anything runs unattended.
Who owns the system after launch?
Someone has to watch errors, renew credentials, adapt to tool changes and handle new exception types. The handover plan names who operates the system, and managed operation and documented handover are both valid outcomes.
What happens when the system gets something wrong?
When a consequential action is uncertain the system creates a visible exception instead of guessing. A queue that waits is cheaper than an automated mistake nobody sees until a customer does.
What if we want to hand the system to our own team?
Ownership, credentials, code, data, documentation, hosting and support responsibility are written into the engagement, so the system keeps running in accounts you own if the relationship ends.
What does the first engagement end with?
Agree the deliverable before work starts, including the written scope and acceptance cases. An assessment is optional at Outproduce and depends on the engagement; any assessment output and commercial terms belong in that agreement.
Sources
This article describes operating principles and public sources. It is not a client result. Build Records carry the basis for every Outproduce system claim.