Why Agentic AI Stalls at the Team Layer in Mid-Market Manufacturing

Large enterprises have depth: overlapping roles, dedicated data teams, and budgets to absorb a failed pilot. Mid-market manufacturers don’t have the same luxury. High stakes, smaller budgets, but more nimble. That last part is an advantage if you use it. Being nimble becomes a liability when someone treats the plant like a Fortune 500 IT program.

While I have 30 years in enterprise, helping household names (think Disney, Toyota, Verizon, etc.) with the full stack from ERP to CRM and now AI, my team and I are doing more with smaller organizations, the ones that aren’t household names but keep America running. We are clearly seeing that the mid-market version of the AI stall is less about model capability and more about thin benches. One person often owns several systems or key production components and now ‘the AI project.’ When something breaks, there is no bench to absorb it. AI hits the back burner, not just until the crisis is averted, but until all the follow-up questions are answered and measures to avoid future issues are put in place.

Enterprises can hide a bad handoff behind process theater and another meeting. The mid-market feels it on today’s ship date. So agentic AI has to earn trust faster, on messier data, with fewer people. And it has to keep humans in the loop without disrupting the business.

The useful conversation is why agentic workflows stall at the team layer: what has to change in process and accountability, not whether the model can write a decent answer.

In practice, a mid-market manufacturer stood up an agent to triage exceptions across orders, inventory, and customer notes. The demo looked great. Then it hit reality. Sales owned CRM fields one way. Operations trusted a spreadsheet that wasn’t in the system of record. Finance closed the month on a third definition of ‘available.’ Nobody owned the handoff when the agent was wrong. The previous hand-built reports relied on insights and understanding held in people’s heads. So the AI report became worthless, not because the model failed, but because the team couldn’t agree on who was accountable when it acted, what the real logic was, or where all the data needed to come from.

That is the team layer. Process and ownership. Until those are clear, agentic AI becomes another dashboard people ignore.

What actually blocks deployment:

• Conflicting definitions of the same business object (what is an “open order”? What is “available to promise”?).
• Undocumented tribal knowledge that only lives in one planner’s head.
• No owner for the exception path when the agent is wrong.
• Security and access models that were never designed for a non-human actor.

What you can often work around:

• Ugly ERP customizations: treat them as constraints and design the agent around a few clean interfaces instead of boiling the ocean.
• Incomplete CRM: start where the data is trustworthy enough for a narrow use case.
• Spreadsheets: a temporary workaround, if you promote the few that matter into a governed source and phase out the rest over time.

My team knows how to make the technology work, but our focus is on being a SWAT team that addresses a business problem with a complete solution. That usually means narrowing the scope until the data and ownership are good enough, then expanding. Not waiting for a perfect data warehouse.

I ask three questions before we talk models.

First: can two people describe the handoff the same way? Trigger, inputs, decision, output, and who owns the exception. If not, you’re automating disagreement. It will fail, and it will fail fast.

Second: is the happy path boring and the exceptions documented? If the plant runs on heroics, an agent will either freeze or make a confident mistake.

Third: if the agent is wrong at 2 a.m., who gets woken up, and what do they reverse? If that answer is fuzzy, the process isn’t ready.

A practical test: walk one real work order end-to-end with the people who live it. Map where work waits, where data is retyped, and where trust breaks. If you can’t draw that on one page, you’re not ready to put an agent in the middle of it.

The first 30 days have nothing to do with technology. I’m meeting with leadership to align on what problems actually matter, running an employee survey to see where the AI enthusiasm and resistance really are, and mapping the workflows on the floor and in the back office where bottlenecks show up. That gives us a real picture of the people and the process before we touch anything technical. In days 30 to 60, we take that picture into department-level workshops and narrow it down to two or three use cases worth pursuing, each with a rough cost and ROI estimate attached. Only then do we start talking about which agentic AI tools might fit. Most manufacturers get this backwards: they buy the tool in week one and spend the next year forcing their people and processes to bend around it.

With our approach, by day 60, we have people aligned, the right processes targeted, and tools deployed for two or three use cases that we can see will work, or fail. We have made choices that reflect cost management, security guidelines, and real impact.

Humans stay in the loop anywhere the downside is irreversible or the outcome is customer-facing: shipping the wrong material, changing a price or promise date, writing to financials, altering quality disposition, or touching systems adjacent to OT/controls.

A simple rule we use: recommendations can be broad; actions that create an irreversible state need a named approver until the error rate and process maturity justify more autonomy. Start with “agent recommendations, human decisions.” Widen autonomy only where overrides are rare or near zero, and the failure mode is cheap to reverse.

Accountability does not move to the vendor or the model. It stays with the process owner. That is the same person who would own that decision if a junior employee made it. If you can’t name that person, you don’t have an agentic workflow; you have a liability.

Demos optimize for wow. Operations optimize for fewer issues and cleaner handoffs.

Before expanding, establish your baseline:

• Cycle time on the target workflow
• Exception/expedite volume
• Rework and scrap tied to the handoff
• Hours spent in status meetings or spreadsheet reconciliation
• Override rate and reason codes once the agent is live

Value looks like fewer escalations, faster resolution of the right exceptions, and people spending time on judgment instead of hunting data. If the only scoreboard is “accuracy on a sample set” or “executives liked the demo,” you’re not ready to scale. Also watch shadow work. If the floor is still running the old spreadsheet in parallel, the agent hasn’t earned trust yet.

Questions I’d insist on:

• Which system of record do you write to, and what is the rollback path?
• Show me a live reference in a plant our size, not a lab demo.
• Who is accountable in your model when the agent is wrong, and who is accountable on our side?
• What data do you need that we don’t cleanly have, and what happens when it’s messy?
• How do you keep humans in the loop on irreversible actions?
• What does year-two cost look like when we add a second workflow?
• Can you tell me exactly what our total cost of ownership is and how we will control costs outside your domain but driven by your tool?

Walk-away answers:

• “We’ll figure out integration after kickoff.”
• “Your data just needs to be mostly right.”
• “The model is the product; process change is optional.”
• No named customer reference willing to talk about failure modes.
• Pricing that only works if you buy the whole platform before one workflow is proven.

If they sell you a cockpit and can’t explain the handoff on your floor, they’re selling theater.

Agentic AI is the wrong answer when the problem is still a broken definition of work.

If two departments disagree on what “done” means, fix the process. If the ERP was configured for a business you no longer run, fix the config or the operating model. If people lack a clear view of inventory or open orders, a clean report or a better role-based screen often beats an agent. If the task is repetitive, physical, and stable, conventional automation may be cheaper and safer.

Use agents when the work involves judgment across messy systems: triage, prioritization, drafting the next best action. And when you already know who owns the outcome. Don’t use them to paper over a firefighting culture. That only automates the firefighting.

High stakes, smaller budgets, more nimble: the mid-market’s edge is choosing the smallest intervention that changes the operating model. Sometimes that’s agentic AI. Often it’s still people, process, and a cleaner system of record first.