In the Loop with Anoop is a monthly series where Anoop Mohan, Chief Product & Technology Officer at Augury, shares his perspective on Industrial AI, the future of manufacturing work, and what it actually takes to build technology that serves the people on the plant floor. Subscribe on LinkedIn to get each new post delivered directly to you.
Every customer conversation I have starts the same place: what’s your biggest business problem? Not agentic AI, not the roadmap. Just the business problem.
Then I listen. The response I receive tells me more about what actually needs to happen than anything I could have opened with.
What I hear back
Workforce challenges come up constantly. Tribal knowledge comes up constantly. And underneath both of those, something more specific: too many point solutions, none of them talking to each other, and someone stuck trying to make sense of all of it.
The problem underneath the problem
If you’ve read my earlier thinking on the Agency Gap, this is the same gap wearing a different face. An APM here, a CMMS there, a historian somewhere else, an EPM bolted on top. Each system does its job. None of them were built to talk to the others. Somewhere in the middle sits a person who has quietly become the translator, the one holding all of it together in their head.
That person is getting harder to find. The workforce that grew up running these systems is retiring, and the skill it takes to stitch ten screens into one coherent picture doesn’t transfer easily to whoever steps in next. When I name this out loud, nobody argues with me. They’ve been living it long before I showed up.
A technology they already trust
Once that problem is on the table, I ask a different kind of question: how many of you have used Gemini or ChatGPT? To draft a note to your manager. To make sense of a training manual. To think through how to prioritize today’s work orders.
Every hand in the room goes up.
That same intelligence, the kind that just helped someone write a note or make sense of a training manual, is capable of far more once it’s grounded in the right data. Point it at an actual fault, and it can work through whether one from three months ago is about to happen again. Nothing about the technology changed in that thirty seconds. What changed is that the room can finally see where it fits.
Proof, not a pitch
Talk gets you so far. What actually moves a room is watching it work. I’ve sat in meetings where we’ve shown an agent pull from a couple dozen data sources, run a full root cause analysis, and land on an answer in about a minute. The same work done by hand takes a skilled person weeks. Sometimes months.
That’s the moment nobody’s asking me to explain AI anymore. They’re asking when they can start using it.
The real finish line
Getting a customer to yes is the easy part of this whole process, and I mean that without any irony.
A while back, we ran a hands-on engagement with an early design partner. Ninety days, a small team, one specific problem. Everyone involved already believed AI could help before we started. That belief was never the obstacle. What took ninety days was something else entirely: making the technology work for this customer, with this customer’s data, this customer’s quirks, this customer’s version of the problem.
That gap between believing and delivering has a phrase attached to it that took me the better part of a year to actually understand.
Model is half the product, and context is the other half
I picked this phrase up at Google: model is the product. I’ve modified it with a little addition: the model is half the product, and context is the other half. Together, they’re the core of applying AI well.
Most people’s instinct, when they hear AI can solve a problem, is to start thinking about what they need to build. That instinct runs backward. If you start from the assumption that the model is half of the product, the intelligence already exists. Your job is to instruct it: here’s the problem, here’s the data, stay grounded, don’t guess, answer this. Once you let go of the urge to build around the model and learn to instruct it instead, something like 70 to 80 percent of the work is already done for you.
Here’s what that actually means for a company like ours: we didn’t need to build the foundation model. Our job is to bring the context, this customer’s data, this customer’s quirks, this customer’s version of the problem, and put it in front of the model in a way it can act on. The model is half the product. Context is the other half. And context is king.
The last stretch: hill climbing
Instructing the model well gets you most of the way there, and that part is the easy climb. The remaining 20 to 30 percent is a different kind of hard, and I think about it the way I think about my son studying for the SAT. Getting a score from 1450 to 1500 takes real effort, but it’s a manageable climb. Getting from 1500 to 1550 is steeper. From 1550 to 1600, steeper still. Every additional point costs more than the one before it.
Getting a model to generally work is the 1450-to-1500 stretch. Getting it to be consistent and reliable for one specific customer, with that customer’s specific data and specific edge cases, is the steep part. That’s what our ninety days actually went toward, and it’s created an entirely new role built around closing exactly that gap.
The forward deployed engineer
The industry has started calling this role the forward deployed engineer, or FDE. It didn’t exist as a job title a couple of years ago, and it doesn’t map cleanly onto anything that came before it.
It isn’t a software engineer in the traditional sense, and it isn’t a services consultant writing custom integrations line by line. It’s a hybrid: part consultant, part translator, part engineer. The FDE sits with the customer and asks the same question I ask in that first conversation, what’s your problem, then keeps going. What are your data sources? How often does this happen? Is the impact big enough to matter?
That conversation turns out to be one of the most valuable data sources there is. What lives in a plant manager’s or process engineer’s head after twenty years on the floor is worth more than almost any sensor reading, because it carries context no machine captures on its own. Once the FDE has that context, the job becomes translation: taking what was gathered from the customer and instructing the model in plain language. This is who the customer is. This is how their process works. This is the problem. Now help us solve it.
It’s a genuinely new talent profile, part sales instinct, part consulting mindset, part technical fluency, and it’s in short supply. That’s exactly why Amazon committed a billion dollars this year to its own forward deployed engineering unit, and Microsoft followed two days later with $2.5 billion of its own. OpenAI and Anthropic, the very companies building the models, have each backed multi-billion dollar ventures to do this same kind of work. If the model itself were enough, none of them would be spending this kind of money on what comes after it.
Not the old kind of custom work
There’s a word people reach for when something is built specifically for one customer: custom, one-off, hand-built. I’d push back on that instinct.
The old version of closing that consistency gap required a person to sit down and write custom software for each customer, line by line. Slow, expensive, hard to scale, which is exactly how the industry ended up with the alphabet soup of point solutions I described earlier. The new version looks similar on the surface, deeply specific to one customer’s problem, but the mechanism underneath is completely different. The model does the customization now, guided by the FDE, instead of a person writing code from scratch. Same specificity. A fraction of the cost and time.
Why proximity wins
The competitive landscape has shifted here. The traditional players in industrial monitoring, built around assets and sensors, aren’t setting the pace anymore. The new competition is agentic from the ground up.
AI models will keep improving, and plenty of capable teams can build a capable model. Our advantage is where we already sit, at the plant floor, working directly with the people doing the job, instead of pitching a strategy at the corporate level and hoping it gets pushed down through the organization. The kind of customization our design partner needed only works if you’re already standing next to the person who needs it.
Why it compounds
There’s a reason nobody wants to switch which AI assistant they use once they’ve been using one for a while. Mine knows my travel schedule. It knows when my son gets out of school. Switch tomorrow, and I start over with something that knows nothing about me.
That isn’t about which model is technically better. It’s about history, and the same logic applies here. Being first to build that relationship with a customer’s plant floor, first to accumulate the context that makes an agent genuinely useful to that specific team, creates a kind of stickiness that’s hard for a competitor to unwind later, no matter how good their model looks on paper.
Ninety days in, our design partner didn’t just have a working model. They had a model that knew them. That’s what applying AI actually looks like: not the model alone, and not the problem alone, but the discipline of putting the two together for one specific customer.
Explore the Industrial AI Workforce and see how the model + context makes a difference for your operations.
