An AI agent gets from demo to production when it can do one real job every day, inside your own systems, on your real records, with rules about what it may change and a person who owns it. A demo shows the agent can do the job once. Production asks it to do the job on every case, including the messy ones, without anyone watching each step.
If your demo impressed the board and then stalled, look first at the parts a demo can skip: the data it reads, the tests that prove it works, the permissions, and the plan for who runs it. Each of those can be written down and checked.
The Gnar Company does this work as custom AI agent development for mid-sized companies on NetSuite or a similar system. Senior U.S. engineers build each agent in the company's own cloud account, and the company owns the code.
Why do AI agent demos stall before production?#
Gartner expects over 40 percent of agentic AI projects to be canceled by the end of 2027, because of escalating costs, unclear business value or inadequate risk controls. A demo can run without settling any of those three, so settle each one before you build further.
Gartner made that prediction in a June 2025 press release. Anushree Verma, a Senior Director Analyst at Gartner, said hype can blind organizations to the real cost and complexity of deploying AI agents at scale, stalling projects from moving into production.
Smaller companies report scaling agents less often. In McKinsey's 2026 State of AI survey, 40 percent of respondents from organizations with more than $1 billion in annual revenue reported scaling AI agents, up from 27 percent the year before. At smaller organizations the share stayed flat at 22 percent.
What a demo proves and what production needs#
A demo proves the agent can do the job on the cases it was shown. Production needs it to work on your real records, with tests, written permissions, a log and a named owner. Compare your demo with what daily use will ask of it, one area at a time. Each row below is a question you can answer about your own project this week.
| Area | Question to ask about your demo | What daily use needs |
|---|---|---|
| Data | Which records did it run on, and who picked them? | Your real records, including the messy and unusual ones |
| Testing | How many past cases has it been scored on? | Tests from your own past work, run again after every change |
| Permissions | What can it change, and who approves? | A written list per system, with approval on the changes you choose |
| Record | Can you see every action it took? | A log of every action in your systems that anyone can check |
| Ownership | Who fixes it when it breaks? | A named owner, code in your own account, and docs for whoever runs it |
The sections below take each area in turn.
What should the agent read, and is that data ready?#
An agent can only do the job as well as the records it reads allow, so check those records before you build further. List every system and file the agent reads, then ask whether each one is complete, current and owned by someone.
Gnar's agent page says an agent is only as good as what it reads. So Gnar Discovery and Design, Gnar's discovery sprint, checks those records first, and says what needs fixing and who fixes it.
Counter Culture Coffee shows why this comes first. In Gnar's AI strategy and roadmap work for Counter Culture, one finding was that governing a trusted set of NetSuite data, with agreed definitions and clear ownership, makes three complex builds possible at once: a plain-language query assistant, an executive scorecard and automated board reporting. In that roadmap, weak data readiness capped an opportunity's score regardless of its upside.
For your own agent, write down:
- Each source it reads. The ERP tables, the inbox, the shared folders.
- Who owns each source. The person who can fix a wrong record.
- What is missing or out of date. And who fixes it before launch.
How do you test an agent before it touches live records?#
Test the agent on cases from your own past work, including the odd ones, and score how often it gets each one right. Then run the same tests every time the agent or its AI model changes, so you see a drop in scores before it reaches live records.
Engineers call these tests evals. Our post on AI evals explains how they work like the software tests your team already writes.
This is how Gnar tests its agents, as its agent page describes it:
- Your own past cases first. Each agent is tested on your past cases, so you see it work before it touches live records.
- The odd cases too. The tests include the unusual ones.
- Every change. Each time the agent changes, the tests run again. If its scores drop, Gnar sees it before the change goes live.
- Every model switch. When a model is retired or you switch models, the tests run again before the new one goes live.
- Every mistake. When an agent gets a case wrong, that case is added to its tests, so the tests keep up with real work.
If your demo has no tests like these, build them before it touches live records, because no one can say whether a change made the agent better or worse without them.
What should the agent be allowed to change?#
Decide, one system at a time, what the agent may see, what it may change, and which changes wait for a person's approval. Write that list down before launch, and keep a log of every action the agent takes so anyone can check what it did.
A simple way to set it up:
- Start read-only. With read-only access, the agent sees records but never changes them. You can watch it on real work before it changes anything.
- Add changes one at a time. Choose which changes it may make, and which ones need a person's OK first.
- Send unclear cases to people. Requests the agent is not sure about go to your team.
- Log everything. Every action it takes in your systems is recorded, so a mistake can be traced.
Take the month-end example on Gnar's agent page. Someone is matching bank lines to the books by hand while the close waits. An agent matches the lines and updates the books, and your team handles only the lines it can't match. On Gnar's agents, you choose what the agent can touch and which changes need a person's OK, and every action it takes in your systems is logged.
Who owns and runs the agent after launch?#
Your company should own the agent and its code, and one named person should be responsible for it after launch. Decide before launch whether your team runs it or the builder keeps running it, and get the documents your team would need either way.
On Gnar's agent work:
- Where it lives. Senior U.S. engineers build the agent, its connections and its tests in your company's own cloud account, such as AWS.
- Who owns it. You own the agent and its code, and Gnar keeps no ownership.
- Who runs it. Gnar can keep it running and rerun the tests each time it changes. Or Gnar hands it to your team with the docs and walkthroughs they need.
- Bugs. If the agent itself has a bug, Gnar fixes it free for the first 12 months.
Gnar builds on Claude, made by Anthropic, by default. Gnar is a Claude Select Services Partner. If your company already chose a different AI platform, Gnar can build on that instead.
How Gnar takes a stalled prototype into daily use#
Gnar can start from the agent prototype your team already built and take it the rest of the way into daily use. In Gnar's words: "The prototype works. Getting it into production is a different job, and it is the one we do." If you have several prototypes, Gnar gets the first one into daily use and teaches your team to do the rest.
The work runs in three steps on Gnar's agent page:
- Map the job. In a discovery sprint, Gnar maps the job step by step: what the agent reads and which systems it works in. The sprint ends with a guaranteed price for each stage of the build, whether or not you build with Gnar. The sprint comes in three published sizes on the Discovery page.
- Build and test the agent. Senior U.S. engineers build the agent, its connections and its tests in your company's own cloud account.
- Run it, or hand it over. Gnar keeps it running, or hands it to your team with the docs and walkthroughs.
Gnar's guarantee, in its own words: "Three commitments on every build engagement: a fixed milestone price with any overage on us, a guaranteed outcome meaning the software works as specified or we fix it, and a twelve-month bug-free warranty. It covers Discovery, Build, Forge and Maintain. It does not cover Embed. On Compass, Immerse and Integrate, ask us."
When should you not ship the agent at all?#
Do not ship a custom agent when a product, plain automation or your own team can do the job well enough. Agents are for work that needs judgment calls inside your systems. Routine work that follows the same steps every time may need simpler software.
Gartner makes the same point. In the same press release, Verma said many use cases positioned as agentic today don't require agentic implementations. Gartner suggests agents when decisions are needed, automation for routine workflows and assistants for simple retrieval. Gartner also warns about agent washing, the rebranding of existing products such as AI assistants, robotic process automation and chatbots without substantial agentic capabilities. It estimates only about 130 of the thousands of agentic AI vendors are real.
If a product fits your job, buy it, and Gnar will say so. Before you sign for any product, test it on your own past cases. If the work is reading orders and requests and entering them the same way every time, Gnar's AI automation work may fit better than an agent.
