Nyyon · Blog

Six checks to run on a forward-deployed AI consultancy before you sign

Six checks end in something you can hold: a reference call, a named team, a working slice, a handoff list, an adoption number and a contract clause.

Six checks separate a forward-deployed AI consultancy that ships from one that relabels ordinary consulting, and each check ends in something you can hold: a reference call, a named person, a working system, a document or a clause. Nyyon is a forward-deployed AI consultancy, so apply every check below to us first. A provider that welcomes the checks has already answered half of them.

This guide covers what to ask, what a strong answer looks like and what to put in the contract. Our comparison of five provider types covers who to put on the shortlist. This page covers how to examine the ones that make it.

Why diligence a forward-deployed AI consultancy now?

Two Gartner forecasts set the backdrop. In June 2025 Gartner predicted that over 40 percent of agentic AI projects will be canceled by the end of 2027. On 29 September 2026 Gartner published a forecast under the headline that 70 percent of enterprises will abandon agentic AI built by vendor forward-deployed engineering by 2028. Both are forecasts. We cite the second one by its headline, because the headline is the part we have read in full.

A buyer can respond to a forecast like that with a procedure. If a provider's work is likely to be abandoned, the purchase decision should rest on evidence that the system will be used and that your team can run it. The six checks collect that evidence before the signature.

What counts as evidence? The four rungs

Every claim a provider makes stands on one of four rungs. Ask which rung each claim stands on.

Four ascending rungs of evidence: a demo, a staging system, a production system, and a production system in daily use.
  1. A demo. It shows what is possible.
  2. A staging system. It shows the build works in a test environment.
  3. A production system. It shows the work survived real data and real users.
  4. A production system in daily use by people outside the build team. It shows adoption, which is the finish line for this kind of work.

A provider can answer with rung four for a company of your size, or can say honestly which rung its best example reaches. Both answers are useful. A provider that blurs the rungs has told you something as well.

Check 1: Can you speak to the team that runs a delivered system?

Ask for one production reference at a company of your size, and ask to speak to a person who uses the system as well as the sponsor who bought it. The sponsor can tell you about the project. The user can tell you about the Tuesday afternoon after launch.

Put these questions to the reference:

  • What does the system do each day, and how many people use it each week?
  • What broke in the first month, and who fixed it?
  • Who maintains it today?
  • Which part of the original plan changed once people started using it?
  • Would you hire the provider again for the next project?

Strong answers name numbers, names and dates. Weak answers describe the provider's process.

Check 2: Who writes the code, and are they named?

Ask for the names and seniority of the people who will build your system, and have those names written into the agreement. Ask whether any part of the work goes to subcontractors and who they are. Ask what happens when a named person leaves the engagement: who replaces them, how fast, and who pays for the ramp-up.

Then ask to see work. A walk through a real repository or a real workflow, with the person who built it, shows more than a slide deck can. Our view: a forward-deployed consultancy employs senior people who write production code, so the code review is the check that separates the label from the practice.

Check 3: What exists after the first week?

Ask what you can look at after five working days. A strong answer is a working slice on your own data, even a narrow one: one workflow, one report, one screen that does a real task. A weak answer is a requirements document or a plan.

This check pays for itself fast. A provider that can build a slice in a week has the access, the people and the habits to keep building. A provider that needs a month to produce a document has told you its pace.

Describe your project and we will show you what we would build first on a 30-minute call.

Check 4: What does your team hold on the last day?

Write the handoff list into the agreement before kickoff, as a list of objects with names:

  • The source code, in a repository under your organization.
  • The infrastructure, running in cloud accounts you own.
  • The credentials and API keys, stored in your vault with your administrators.
  • A runbook that a person on your team can follow to restart, update and monitor the system.
  • A decision log that records why each major choice was made.
  • A recorded walkthrough, and a live session for the people who will operate it.
  • A set of test cases with expected results, so your team can tell when a change breaks something.
  • A named owner inside your company.

Then schedule a dry run before final acceptance. Ask one of your people to follow the runbook and restart the system in a staging environment while the provider watches and stays quiet. Whatever stalls the person goes into the runbook that week. The dry run converts a promise about handoff into an observed result.

Check 5: How will adoption be measured?

Agree the measure before the build starts. Pick a number your business already tracks, such as cases handled per week, hours spent on a task or time from request to answer. Record the baseline today. Name the person who reads the number and the date of the first reading.

Define done as the system in daily use against that number. A provider whose definition of done is delivery of the build is selling you a build. Our post on why a weekly build finds what a scoping document guesses explains why we tie the work to use from the first week.

Check 6: Which contract terms protect the handoff?

Have your counsel review the agreement. This list tells you which clauses to ask for:

  • Ownership. The work product is assigned to you on creation.
  • Accounts. Model-provider, cloud and tool accounts sit in your name from day one.
  • Data. The agreement states what data the provider can access, where it is stored and when it is deleted.
  • Key people. Named individuals stay on the work, with a replacement clause.
  • Subcontractors. Each one is disclosed and bound by the same terms.
  • Acceptance. Acceptance is tied to the adoption measure and the handoff dry run.
  • Exit. On termination the provider delivers the handoff package within a stated number of days.

What are the red flags?

Six patterns should slow the signature:

A table contrasting weak and strong answers on reference, team, code ownership and definition of success.
  • A demo offered where a production reference was requested.
  • A team that will be named after signing.
  • Code that lives in the provider's repository.
  • Credentials held in the provider's accounts.
  • Success defined as shipping the build.
  • A reference limited to the executive sponsor.

Any one of them can be fixed in negotiation. Several together describe a provider whose model depends on staying in the building.

How do you run the diligence in two weeks?

A schedule that fits inside a procurement cycle:

  1. Days 1 to 3. Send the six checks to two or three providers as written questions and ask for written answers.
  2. Days 4 to 8. Hold the reference calls and the code walkthrough.
  3. Days 9 to 12. Ask each finalist to scope the first week and the handoff list.
  4. Days 13 to 14. Compare the answers on the six checks and mark each rung of evidence.

A scorecard with six rows and one column per provider is enough. Give each row one of three marks: evidence in hand, a promise, or a gap.

Put the checks to Nyyon

Book a 30-minute strategy call and bring the six checks. We will answer each one with specifics, and we will tell you if your project fits a different kind of provider. For the role itself, read what a forward-deployed AI consultant does. For the build-or-hire decision, read why to hire a consultancy before a Head of AI.

About Nyyon

Nyyon is a forward-deployed AI consultancy, also described as an AI execution partner. It takes the important operational project nobody has time to own and hands it back as a working system the team runs. Nyyon works with founder-led companies in North America and with department leaders who hold an AI mandate and lack the capacity to execute. Engagements run as a Skip-the-spec Retainer, a Project Sprint, or a Forward Deployed AI Expert engagement.


← All articles