An AI implementation consultant works out where AI can do useful work in your company, then builds that software and connects it to the systems you already run. When the work is done, you should have software your people use every day, a written record of what it can see and change, and code that belongs to you.
That is a different job from writing an AI strategy. A strategy engagement hands you a ranked list of ideas. An implementation engagement also builds the connection between an AI model and your ERP, has your security team review it, and puts it live. If you want AI built and running, ask every firm which of the two it is selling.
The Gnar Company does this work in two parts. Its AI strategy service defines where AI creates measurable impact before anything is built. Its enterprise AI integration service is the connecting part: U.S.-based senior engineers connect AI models, such as Claude, to the ERP, CRM, databases and files a company already uses. Gnar is a Claude Select Services Partner in Anthropic's Claude Partner Network.
What does an AI implementation consultant do?#
An AI implementation consultant takes an AI idea from a business problem to working software inside your systems. The work has four parts: find the tasks worth handing to AI, plan how the AI reaches each system, build those connections with rules about what the AI may touch, and put the result live.
Each part produces something you can check.
- The tasks. A short list of jobs your people do by hand today, each with what it costs and what changes if AI does it. For example, typing emailed purchase orders into the ERP.
- The plan. Which systems the AI needs to reach, what it may look up and what it may change in each one, and who signs off.
- The connections. Small programs that let an AI model use one system in the ways you allow. Gnar's integration page says most of its connections are small programs called MCP servers. MCP stands for Model Context Protocol, an open-source standard for connecting AI applications to external systems.
- The launch. The software running for real users, with the access rules and a log of what the AI looked up and changed, reviewed by your security team before it goes live.
If a firm's proposal stops after the plan, you are hiring a strategy firm. That can be the right call.
Strategy firm, build shop or implementation partner: which do you need?#
You need an implementation partner when you want AI running in daily work and have no engineers free to carry out a plan. You will meet three kinds of firm. The labels below are how this guide sorts them, by what you hold at the end. Whatever a firm calls itself, ask what it hands over.
| Kind of firm | What you hold at the end | When it fits |
|---|---|---|
| Strategy firm | A roadmap, a business case and a ranked list of ideas | You have engineers ready to build, and you need help choosing what they build |
| Build shop | The software you specified | You already know exactly what to build and how it should connect |
| Implementation partner | A plan, the software, the connections to your systems and a record of what the AI does | You want AI working in daily operations and have no engineers free to carry out a plan |
If you have engineers who can build, a strategy firm or a build shop can fill the gap you have. If you have nobody inside who can point at the work, hire a firm that plans and builds, so the people who wrote the plan are the ones who build it.
Gnar's AI strategy page says it this way: the team that wrote the strategy ships it.
Why do AI projects fail?#
In RAND's study of AI projects, the most common reason they failed was that stakeholders misunderstood, or miscommunicated, what problem the AI was meant to solve.
RAND's 2024 study of AI project failure interviewed 65 experienced data scientists and engineers, 50 of them in industry. Five root causes came out of the industry interviews: that one, lacking the data to train an effective model, chasing the newest technology over the real problem, weak infrastructure to manage data and deploy models, and problems too hard for AI. RAND also cites estimates that more than 80 percent of AI projects fail, twice the rate of IT projects without AI.
In McKinsey's 2026 State of AI survey, 37 percent of respondents attributed at least some EBIT impact to their company's AI use, about the same share as the year before. McKinsey says its AI high performers, about 6 percent of respondents, fundamentally redesign workflows that are enabled by AI rather than insert AI into existing ones.
For a buyer, that points to three things to check in any firm:
- They talk to the people who do the work before they design anything, so the problem is the real one. At the insulation distributor below, Gnar interviewed people across the branches first.
- They look at your data, your system access and where the software will run, early, and say what has to be fixed before the AI can use it. In Gnar Discovery and Design for AI integration, Gnar flags messy data or access settings that would block the build.
- They change the workflow along with the tool. If a rep still retypes an order after the AI reads it, the work is the same as before.
What should the first engagement produce?#
The first engagement should end with a written build plan and a fixed price for the build. You should be free to take that plan to another firm. The plan and the build are best done by the same team, and taking the plan elsewhere is your fallback. If a firm will not put a fixed price on the build until you have signed for the build, you have nothing to compare its price against.
A useful first engagement hands over:
- A map of the systems the AI must reach, and what it may see and change in each one.
- The blockers, such as messy data or access settings, that would stop the build.
- An architecture your own engineers could read and build from.
- A build plan in phases, each with a fixed price.
At The Gnar Company this is Gnar Discovery and Design. On the enterprise AI integration page, it starts from two weeks and $15,000, and you leave with a build plan that has a fixed price on it. The Discovery page sets out three depths, at two, four and six weeks, and says the Build phase these plans scope is typically $150K to $300K+.
Gnar's answer to "do I have to build with you" is: "No. Start with a discovery sprint that ends in a guaranteed price, whether or not you build with us." The Discovery page also says you are free to take your deliverables to an internal team or another partner.
What should you own when the work is done?#
You should own the code, the connections, the rules about what the AI may do, and the record of what it has done. Ask for all four in writing before the build starts, so a change of firm, a new hire or a retired AI model does not leave you starting over.
| What to own | What to ask for |
|---|---|
| The code | It lives in your company's own accounts, with documentation your engineers can follow |
| The access rules | Each system lists what the AI may look up and what it may change, set one system at a time |
| The record | A log of who asked, what the AI looked up and what it changed, that your security team can review |
| The connections | Connectors that are not tied to one AI model, so the next model can use the same ones |
On Gnar's AI integration work, these are spelled out on the service page. You choose what the AI can see and change, and every lookup and change is recorded. A read-only connector lets the AI find an order or a customer but not change anything through it. Where the AI may change records, every change passes one checkpoint you control, which checks permission first, and a person can approve it before it lands.
Gnar also builds the connections apart from the model: AI models get replaced, and the connections are not tied to one model. Before launch, your security team gets the access rules and the request log to review. After launch, your team runs it, or Gnar keeps it working on Maintain, its monthly support plan. You own what gets built, and Gnar keeps no ownership of it.
Questions to ask before you sign#
Before you sign, ask every firm the same eight questions about the plan, the builders, your systems and who owns the result. Write down each firm's answers so you can compare them side by side.
- What will I hold at the end of the first engagement? Look for a build plan with a fixed price. At Gnar, Discovery ends with one.
- Can I take that plan to another firm? The answer should be yes, in writing.
- Who will build it, and did they write the plan? Ask for the names of the people.
- Which of my systems will the AI reach, and what may it change in each one? Look for a list, one system at a time.
- How is every lookup and change recorded, and who reviews it? Your security team should see it before launch.
- Where does the code live, and who owns it? Your accounts, and your company. At Gnar, you own what gets built.
- What happens when the AI model we use is retired? The connections should stay.
- Can you show me software you built that is in use today? Ask to see software that is in use today and what the firm's part in it was. A roadmap does not answer this question.
What the work looked like at two distributors#
The first case below is an order and delivery system built alongside a distributor's ERP, where $280K a year in software was replaced. It shows how Gnar diagnoses a client's systems before building. The second is a Gnar training cohort in which MCP connectors brought a client's systems into the loop.
A US insulation distributor was paying for two tools on top of its ERP. One tool planned delivery routes and the other sent customer messages. Neither matched how the team worked, and staff covered the gaps by hand.
Gnar started with a diagnosis. The team interviewed people across the distributor's branches. Then Gnar replaced both tools with one system for orders and deliveries. It pulls sales, transfer and purchase orders from the ERP, so salespeople do not have to work in the ERP directly. Before an order saves, it now passes a five-step check, and one of those checks is a minimum margin. The distributor replaced $280K a year in software. The case is on Gnar's order management page.
GSC Enterprises, the wholesale distributor behind Grocery Supply Company, shows a different kind of work: a team learning to build with AI itself. Gnar ran a four-week cohort of its Immerse program on GSC's own production code, led by a senior Gnar mentor. During the cohort, the team used MCP connectors for Snowflake, Atlassian, Microsoft 365 and GitHub, which brought GSC's real systems into the loop.
GSC runs an independent code review agent against every pull request. Over the four weeks, the share of pull requests with review-agent comments fell from roughly 100 percent to under 10 percent, with no change to the agent. The case study credits better up-front specification and tighter context discipline by the engineers.
Blake Macek, GSC's Business Application Manager, said of the sessions with Alex, the Gnar mentor who ran the cohort: "The one-on-ones with Alex turned general knowledge into progress on our own projects. We came away with working changes, not just notes."
When should you not hire one?#
Do not hire an AI implementation consultant when your own engineers have the capacity and the direction to do the work. Do it internally. Outside help makes sense when you have no engineers free to point at the project, or when the people you have are busy with other work.
Gnar's own service page answers the question the same way. Asked whether a company's own engineers should build this instead, it says: often they should. If your own engineers have the capacity and the direction, do it internally, and Gnar will say so on the call.
If you are not sure yet where AI fits, start with how to build an AI roadmap the board will fund. If you want engineers working inside your operations day to day, read when your company needs a forward deployed engineer.
