These aren't case studies. They're engagements we built and ran ourselves. We went back through 32,000+ of our own emails, meetings, and messages with clients. The difference was rarely the code. It was how each engagement was set up, owned, and run.
The AI engagements that worked did not win on code, on any single metric, or on any one use case. They won because the engagement itself was set up, owned, governed, and resourced on both sides before the build began.
These aren't case studies we read about. We built and ran every one of these engagements ourselves, and we were in the meetings. For this report we went back through more than 32,000 of our own emails, meeting transcripts, and messages with mid-market clients, more than 3.5 million words in all, along with every agreement and project log, from the first conversation to today. We compared a successful group, where the project was built, launched, and put in the hands of the client's staff, with a stalled group that ran long, narrowed, or never reached everyday use. The companies ranged from about 10 to 400 employees across defense manufacturing, specialty chemicals, energy field services, building technology, and media.
The technology was similar across both groups. What differed was the operating model around it: who owned the program, who set priorities, what "done" meant, how much ran at once, how decisions got made, whether the organization could test and absorb what was built, and whether the commercial terms matched how the work actually happened. In every successful engagement, the core of that model was in place at kickoff. In every stalled engagement, most of it was missing or arrived months late.
Each finding is a condition the successful engagements put in place early and the stalled ones did not. Together they describe the operating model that decides whether an AI program reaches the people it was built for. The chart shows how fully each condition was in place in the first 90 days; the cards give the evidence behind each one.
Scored from the engagement records for the first 90 days: present counts fully, partial or late counts half. Sorted by the size of the gap. Reply speed separated the groups least. See the full scorecard
Who runs it, who decides, and how often
Every successful program had an operator-owner running it week to week and an executive locking priorities on a fixed rhythm.
A weekly working session plus a monthly executive scope review turned contact into decisions.
Fast replies helped, but decisions made, tests run, and access granted set the real pace.
What gets built, and how much at once
Scope, success criteria, and acceptance were agreed before the build, not discovered during it.
Sequenced work shipped. When one stalled module narrowed to phases, verification rates nearly doubled within about a week.
Whether the organization can absorb it
Adoption followed high-volume workflows with a real user group waiting. Convenience tools went unused.
Systems replaced mid-build and undocumented data definitions cost months. Credentials rarely did.
Trust comes from the client's own experts testing real cases, so those hours have to be planned and named.
How the deal and the delivery stay honest
One statement of work, one payer who also decides, and every scope or price change in writing.
The vendor's half: honest status, monitored systems, and nothing called live until staff use it unaided.
Treat an AI program as a joint operating model with two halves, and staff both before the build starts. The client's half is sponsorship, ownership, a definition of done, focus, readiness, and testing time. The vendor's half is build quality, honest status, and reliable operations. Put both in the agreement, and the technology usually takes care of itself.
nBrain builds private, owned AI platforms for mid-market companies. We call them Centralized AI Brains: one platform, connected to the company's own systems, with purpose-built agents on top. Over the past year we have run enough of these engagements to see a pattern we couldn't explain with engineering alone. Similar technology, similar teams, similar budgets led to very different outcomes.
So we did what we would do for a client: we pulled all the data and looked. Our starting hypothesis was that success depended on the relationship. That meant how often we met, how quickly the client responded, whether they had a dedicated point of contact, and how organized they were technologically. Some of that held up. Some of it didn't, and the parts that didn't turned out to be the most useful.
"Successful AI adoption is 50% vendor, 50% client. What we're proving is what the two halves look like when they're both all-in."
VP of Operations, defense electronics manufacturer (Engagement A), writing to his executive team at month five, echoing a line from our co-founderThis report is about both halves. We name our own mistakes as plainly as the structural issues on the client side, because the prospective clients reading this deserve an accurate picture of what a successful engagement takes from both parties.
We didn't observe these engagements from the outside. We ran them. Every email, call, and message in this study is one we sent, received, or sat in on, which gave us something an outside analyst rarely has: the full record, including our own mistakes.
More than 32,000 of our own interactions with clients: unique emails, chat messages, calendar events, and every substantive speaker turn in about 190 hours of recorded meetings. In total we reviewed more than 3.5 million words. That count includes the quoted history carried inside email reply threads, so some wording is counted more than once. We also read every signed agreement, proposal, kickoff plan, weekly status log, and code history. The window runs from the first conversation (October 2025 at the earliest) to September 2026.
Median client reply time, share of our messages that got a reply, meeting cadence and gaps, number of distinct client participants, who owned each action item, days to each access grant and first working deliverable, and how many workstreams were open at once. We then read each engagement's full narrative to find the turning points.
Plainly: the project was built, launched, and in the hands of the client's staff. Engagements that ran long past their timeline, had no accepted deliverables, narrowed to a fraction of the original scope, or never reached everyday staff use were classed as stalled.
Raw metrics mislead. Multi-mailbox sync duplicated up to a third of email records. One client worked almost entirely in chat, so email looked slow. Newsletters and calendar notices inflated "client-started" threads. Some meetings were never recorded. Every figure in this report is the corrected one.
nBrain is a small company with a focused client base. This isn't a statistical survey, and we don't claim statistical significance. It is practitioner evidence from inside our own engagements: the record of work we did ourselves, read end to end. The data confirmed, with real numbers and real conversations, patterns our team had already lived through in the field. We are publishing it because those patterns held up under scrutiny, and because every company starting an AI program can use them.
Anonymity: every company is described by industry and size only. People are identified by role. Quotes come from meetings and correspondence with nBrain. They are lightly edited for readability, with filler words, names, and identifying details removed. No client's internal-only material is quoted.
The profiles below are representative engagements drawn from the study, labeled A through E and used throughout this report to illustrate each finding. Each had the same basic shape: a fixed-fee build of a client-owned AI platform connected to the client's systems of record, with agents targeted at specific workflows. The companies, and the way each engagement was set up, differed a great deal.
About 120 employees, ITAR-regulated, owner-led. Legacy ERP and factory-floor systems, a government-cloud tenant, and a small finance team buried in manual invoice matching.
Founder-led and mid-sized, with 50–75 staff. Mid-market cloud ERP, a sales CRM, and a regional sales force.
Six operating companies under one owner. The anchor is a ~400-person energy field-services contractor; the others are franchise, retail, defense-supply, and property businesses. Each runs its own stack, and several were replacing their core systems during the build.
Founder-led, 10–20 people, running managed networks in commercial real estate. The founder was a heavy AI user, content-driven, and the sole decision-maker.
About 20 people, founder-led, serving healthcare and higher-education clients. A clean marketing-data warehouse and a strong analytics lead. It had already been through one AI consultant that didn't deliver.
We scored each representative engagement on the ten conditions that came up most often in the evidence. Scores reflect the first 90 days, when the trajectory was set, not how things were eventually repaired.
| Condition | A · Defense mfgSuccessful | B · ChemicalsSuccessful | C · Holding groupStalled | D · Building techStalled | E · Media agencyStalled |
|---|---|---|---|---|---|
| Named operator-owner at kickoffOne person accountable, with time and authority | |||||
| Executive sponsor on a fixed rhythmLocks priorities; available for decisions | |||||
| Written scope and definition of doneBefore the build, not after | |||||
| Sequenced focusOne or two modules in build at once | |||||
| Two-tier cadenceWeekly working session plus monthly executive review | |||||
| First use case is a daily, painful workflowWith a real user group waiting | |||||
| Stable systems of recordNo core system replaced mid-build | |||||
| Client validation time committedNamed testers with hours set aside | |||||
| Payer, decider, and user alignedClean commercial frame and change control | |||||
| Fast client repliesMedian reply within a few hours |
A = defense manufacturer, B = chemicals (both successful, shaded green). C = holding group, D = building tech, E = media agency (stalled).
The highlighted row is the one we expected to explain everything. It turned out to separate the groups least. The top four rows separated them completely.
This was the strongest single difference in the data. In the successful engagements, two roles were filled on day one: an operator-owner who ran the program week to week, and an executive sponsor who set priorities on a fixed rhythm and made decisions quickly when asked.
"In just about every AI use case, the only person that it's their full-time job is [the vendor's lead]. Everybody else there, they have another job that they have consumed their entire work life for years anyway."
Owner, multi-entity holding group (Engagement C), month sixA fast coordinator doesn't replace an owner. In Engagement C the coordinator was diligent and quick, but she was a router, not a decision-maker. Everything she routed still needed an owner at the other end, and for most of the six companies there wasn't one. The only workstream in that group that produced real staff adoption was the one with a strong, named owner: a billing and payroll lead who eventually took charge of the scope herself.
Meeting count on its own didn't predict anything. The holding group met about eight times a month, nearly as often as Engagement A. What mattered was what each meeting was for.
Short sessions per module, triggered when readiness stalls. Stops when it is fixed.
60 minutes, owner-led. Status, blockers, access, decisions, deployments.
With the sponsor. Scope vs delivered, priorities, change control.
Decisions, owners, dates, sent within 24 hours.
Engagement A ran exactly this: 23 weekly syncs, a monthly scope review with the CEO (one of them on-site), and a switch to daily module check-ins when adoption stalled in month four. In Engagement B, the client set up the weekly standup itself, ran its own recorded feedback sessions between our meetings, and sent structured written critiques.
The stalled engagements had frequent contact but no governance. The media agency had no standing cadence for its first five months; the weekly session began only after an escalation. The golf-entertainment company inside the holding group never had a recurring meeting at all, and after kickoff there was a 106-day gap before the next working session. In the holding group, the client weekly was cancelled six times in seven weeks as the calendar filled with other business. In the building-technology engagement, our own team went silent over the holidays in month two and again in the final three months. That is where that relationship was lost.
The successful clients were quick. Engagement A's team answered our emails in a median of 42 minutes, and its IT lead once granted cloud admin rights and mailbox consent within about an hour of the request. Engagement B's median was under an hour and a half.
But the building-technology founder (D) answered chat messages in a median of eight minutes, with 96% of replies inside a day. The media agency (E) answered within about two hours. The holding group's coordinator (C) replied in a median of 26 minutes, and one of its affiliates answered in as little as 11. All of them stalled.
Shorter bar means faster. Green = successful engagement. Corrected for duplicates and channel (chat vs email).
Fast replies helped. What reply speed couldn't measure was throughput: how quickly a decision got made, a test got run, or a third party got moved. In the holding group, the coordinator answered within minutes, but anything that needed the principal waited on his travel, and anything that needed an outside IT or ERP partner waited weeks. At the media agency, emails came back the same day while module testing took two weeks or never happened, because the people who knew the workflow had no time set aside for it.
The successful engagements had defined their scope before the first line of code. Engagement B's CEO wrote all four use cases himself, sent a detailed forecasting specification before signing, and drafted a contract addendum covering acceptance windows and the handoff to his own team.
"This is not an exploratory AI build. It is the implementation of a defined, best-practice forecasting framework."
CEO, specialty chemicals manufacturer (Engagement B), before signingEngagement A's proposal and agreement named three modules, listed measurable targets (surface every material shortage before release to the floor, cut invoice search time from 5–10 minutes to near zero, replace a three-hour weekly production meeting), and required a monthly scope review with written change control. When scope grew, the add-ons were raised in that meeting, and the largest one got its own statement of work.
None of the stalled engagements had this. The media agency's agreement listed eight modules and left seven "to be chosen later," and a follow-up addendum made the timelines non-binding. The client's finance lead saw the gap before signing:
"Can you better define the criteria and what 'done' is, then have a sign off procedure for each deliverable?"
Finance and contracts lead, media agency (Engagement E), before signingThat request was never turned into practice, and at month nine no module had been signed off. In the holding group, one agreement covered six companies with no sequence and no acceptance criteria, and more than 20 workstreams were opened under it without a change order. The building-technology engagement swapped a CRM integration for a custom CRM build at signing with no change in price, and never defined the "completion" that triggered the final payment.
The successful engagements sequenced their work. Engagement A started with accounts payable because it had the most frustrated owner and the least regulated data, so it could run on a commercial cloud while the government-cloud work for the controlled modules continued in parallel. Engagement B built its two sales use cases first, then the two forecasting use cases, and locked each specification before building it.
The stalled engagements ran wide. In the holding group, the vendor offered on day three to take the companies one or two at a time. The client expected it to be easy, so all six started at once, and every weekly meeting added a new idea. Six months in, the principal diagnosed the problem himself:
"We have so many different things going on across the area and across the people that it's getting confusing."
Owner, multi-entity holding group (Engagement C), month sixThe best evidence came from inside that same group. The energy contractor's billing module had struggled for months across seven parallel threads. Then its billing lead wrote, "I think we need to start treating this project in defined phases," and narrowed phase one to two checks. Within about a week, the share of field tickets passing automated verification rose from the 40–50% range to 86–95%. Two months later, 90% of 687 tickets cleared with no human touch. The team and the technology were the same; the only change was focus.
Other stalled engagements show the same thing. A defense-supply affiliate went through at least ten overlapping planning schemes and marked 149 of 163 tasks top priority. The media agency had five to eight live threads for a 20-person company with one technical contact.
Adoption followed pain. Engagement A's first module went to a finance team with a daily, high-volume problem and an owner who said so on the first call:
"Today we just focus on AP, which is my biggest headache right now. We are a very small team. I just have one accountant and one AP, and currently I'm actually missing an AP person."
VP of Finance, defense electronics manufacturer (Engagement A), day two of discoveryShe uploaded 195 sample invoices the same day she was asked. In month six, the module sorted 535 incoming items into its automated queue, and her team moved the recovered time into reconciliation and vendor-statement review. The energy contractor's billing module, a painful monthly payroll and billing process with a team of users, became the only staff-level success in the holding group.
The contrast is the golf-entertainment company. It had the friendliest, fastest-responding owner in the study, but its use case was convenience reporting. Of 57 staff accounts provisioned, none but the owner's has ever been used. The media agency had real pain (five people spending five hours on each client report), and its team liked the first report they saw. But usage in month five was 120 minutes across a whole month, because the module wasn't yet part of anyone's routine. Its founder put it simply: "nobody knows that they can use it."
We expected "technologically organized" to mean fast credentials. Credentials were rarely the issue. Engagement A's IT lead had government-cloud accounts running within about five days and granted mailbox consent within an hour. The media agency's outsourced IT administrator turned around its request in four to eight days. The real long poles were of two kinds.
In Engagement A, the ERP took 82 days to become reliably usable for matching, and the factory-floor system was only 11% mapped after six months, because the knowledge of what each table meant lived in people's heads. At the media agency, the "report number disputes" turned out to be undocumented metric definitions: view-through versus click-through attribution, and a 100% versus midpoint video-completion threshold. Once those were written down, the numbers matched.
Third-party gatekeepers were a pattern too. Specific requests got fast answers, and open-ended ones stalled. The same outside ERP partner took 53 days on an open-ended access request and 21 minutes on a precisely specified one.
"I feel like we get going, and then we get roadblocks. Oh, we switched with them, so now we're here."
Billing and payroll lead, energy field-services contractor (Engagement C), month tenAn AI module isn't done when it runs. It's done when the people who own the workflow trust the output. That trust comes from testing against real cases, and the testing can only be done by the client's own experts. Every engagement in the study underestimated those hours, including the most successful one.
"The team didn't understand the initial amount of QC verification and validation. Initially, I think I was allocated 10% of my time to be on the project, maybe 20%."
VP of Operations, defense electronics manufacturer (Engagement A), month fiveEngagement A absorbed this by moving an internal program lead to full time and adding daily check-ins. Engagement B's validators (the Controller and VP of Operations) had sign-off roles written into the use-case specifications. At the media agency, the two strategists who knew the workflow were buried in fiscal-year planning, vacations, and their largest account. The request for at least three hours a week of testing first appeared in month nine.
We didn't expect commercial terms to show up in an adoption study. They showed up in every stalled engagement.
This finding is about us. In most of the engagements we studied, our status reporting got ahead of reality at some point, and every time the client noticed. The most important moment in the most successful engagement was when the client's program manager told us so directly:
"I give [the CEO] weekly updates, and lately I don't feel like I'm being truthful. We kept using the term 'live' loosely. And even [our finance lead] came into my office yesterday and said the AP module, I just can't use it."
VP of Operations, defense electronics manufacturer (Engagement A), month fourThat conversation reset the engagement. We redefined "live" as "the owner can use it unaided," moved to daily module check-ins, and wrote cheat sheets showing where to verify each number. Five weeks later, the client's executives announced the first module in production to the whole company, in their own name.
Elsewhere, the same pattern did more damage. One weekly report called 25 test questions a "100% success rate" when the client hadn't tested them yet. A build was reported as largely complete days before a test run got only 14 of 92 records through. Another was described as ready while it still sat on a developer's laptop, so the client tested an old version. Separately from status reporting, some failures went unnoticed: a transcript feed broke for two months, an ERP sync went stale for six weeks, a nightly job failed every night for a month, and a system ran against a test database for about ten weeks. In each case the client found the problem first.
Nothing is called live until its owner has used it unaided on real work.
Freshness alarms on every data source, visible to the client.
Every credential and environment is confirmed as production before building on it.
Written by the engagement lead and reconciled against the internal tracker, not generated.
A named backup lead covers every engagement, so holidays and travel never stop the cadence.
We build platforms that clients own: their code, their cloud, their data. Several clients in this study ended up building on the platform themselves. How it happened decided whether it counted as a success.
The handoff was written into the contract before work began. Code and infrastructure lived in the client's accounts from day one. At term end, the client's technical owner cloned the platform, hired developers, and grew it from four use cases to about 55 modules, which he later presented to his board. The relationship ended amicably, with a monthly knowledge-sharing call and an offered testimonial.
A defense-supply affiliate and a building-technology founder each started using AI coding tools mid-engagement. The client wrote most of the code from then on (in one case more than 90% of commits), while our role narrowed and the scope, costs, and ownership boundaries stayed undefined. The platforms work, but with more sprawl and cost than planned, and without a clean handoff.
The lesson isn't to stop clients from building. An owned platform should let them. The lesson is to plan graduation: decide in the agreement what the client will run, what we'll run, when control transfers, and what our role is afterward (architecture, governance, operations, and the core Brain layer). Graduating a client this way is a success.
Everything above turns into a standard operating model, based on what the successful engagements did, often before we asked. These are the roles, rhythms, and commitments we now put in place before the build starts.
Owns the business outcome and the budget. Chairs the monthly scope review and makes priority and data-classification calls within one business day of a request.
Runs the program day to day with a stated time commitment (plan on 20–30% during active build). Leads the weekly sync, owns the backlog, and announces launches internally.
IT lead or partner contact with authority to grant access. Handles every system-of-record and vendor request against a written data map, with a target of ten business days per system.
One or two people per module who do the work today. They supply real examples, test each release, and sign off on the acceptance criteria. Weekly validation hours are set aside in advance.
Accountable for delivery, truthful status, and operations. Writes every recap and weekly status personally. A named backup keeps the cadence running through travel and holidays.
One page per module: business KPI and baseline, users, data sources, acceptance tests, who signs off, and what "live" means. Signed by the operator-owner before the build starts.
Score readiness with the checklist below. Name the five roles. Map every system of record and flag anything changing in the next six months. Write the first module charter together.
JointAn interactive prototype on the client's real workflow within about two weeks (Engagement A's took 14 days), reviewed at the desk of the person who does the work. Production environments verified, and connector monitoring switched on.
nBrain leadsThe module runs on live data. Process champions test against the acceptance criteria within five business days of each release. Daily check-ins start if readiness stalls.
Client validatesWritten sign-off against the charter. The client announces the launch to its own people. The KPI is measured against its baseline. Only then does the next module move into build.
Joint| Commitment | Client | nBrain |
|---|---|---|
| Blocking decisions | Answered within 1 business day by the sponsor or owner | Every decision request framed as a choice between options, with a recommendation |
| Access and data | Each system in the data map granted within 10 business days, or escalated at the monthly review | Specific, pre-written access requests; production verified on day one |
| Testing | Named testers, 3–5 hours a week each during active build, feedback within 5 business days | Test scripts and "where to verify" guides with every release |
| Cadence | Owner at every weekly sync; sponsor at every monthly review | Written recap within 24 hours; weekly status reconciled to reality |
| Scope | New ideas go to the backlog; changes approved in the monthly review | No more than two modules in build; every change estimated and priced in writing |
| Operations | Tell us about upcoming system changes and vendor migrations early | Monitoring and freshness alarms on every connector; we find failures before you do |
| Ownership | Accounts, cloud, and code held in the client's name from day one | A documented graduation path: what you run, what we run, and when that changes |
Score your organization before you sign with any AI partner, including us. Give each item 2 points if it is fully true, 1 if partly true, and 0 if not.
Each question maps to a finding in this report.
Not a coordinator who routes requests, but an operator who can decide.
And make priority calls within a day when asked?
If you can't measure it today, you won't be able to prove it improved.
The strongest single predictor of time to value in this study.
Convenience tools rarely get adopted. Painful, recurring workflows do.
If yes, start with a use case on a system that won't.
Including any outside ERP partner or SaaS vendor.
Plan on three to five hours a week per tester during active build.
If a parent company pays and a subsidiary decides, write down who has the final say.
Plan the graduation up front.
A router is not an owner. Ask who decides, and bring that person into the weekly sync.
Every stalled multi-workstream engagement started this way. Agree on the first two modules and put the rest in a written backlog.
Undefined scope becomes the prioritization problem six months later. Write the first charter before signing.
An ERP, booking, or email migration during the build means building the integration twice. Start somewhere stable.
This is almost always a testing-capacity problem, not a quality problem. Name testers and set aside their hours.
Three cancellations in a row predicted every drift in this study. Escalate to the sponsor.
Believe the users. Redefine "live," add daily check-ins, and don't report anything as done until it is used.
About this study: every engagement in this study was delivered by nBrain between October 2025 and September 2026. Company descriptions are generalized to protect client confidentiality, and figures are drawn from engagement records, corrected for duplicate and channel artifacts as described in the methodology. Outcomes describe engagement delivery, not the performance of any client's business.
Every nBrain engagement now starts with a readiness review and a module charter, before any build. If you are planning an AI program and want to see how your organization scores, we'll walk through it with you.
Talk to the founders: Danny DeMichele, danny@nbrain.ai · Cary Johnson, cary@nbrain.ai