Five engineering competencies that separate a production AI agent from a demo

Notes from shipping AI agents into live environments, not slide decks.

Last week I posted on LinkedIn that most of what is being sold to enterprises as “agentic AI” right now is a drag-and-drop canvas with an LLM dropped into one of the steps - a workflow in an agentic costume. Sierra reached a $15.8 billion valuation, Decagon reached $4.5 billion. Lindy and Gumloop are also competing on the depth of their connector libraries. The bigger the library and the smoother the canvas, the bigger the financing round. It’s RPA 2.0, or automation pretending to be agentic AI.

The diagnosis is the easy part but the harder question, and the one that I try to address in this article, is what actually engineering a real agent should look like and how it’s different from dragging and dropping steps on a beautiful canvas.

Demo works, pilot works… production doesn’t. The post-mortem usually ends with the word “hallucination.” That word does a lot of unhelpful work, because it makes the failure sound like it was the fault of LLMs. In reality, it is the lack of LLMs in the right places and missing engineering decisions.

That is the topic of this post - the engineering decisions nobody is making, and why the easy drag and drop “agentic” platforms are not going to make them for you.

The democratization that nobody warns about

In 2019 I wrote an article about risks of AI democratization titled “Why are progressing AI democratization and data-first approach not necessarily good things?” (https://medium.com/data-science/why-are-progressing-ai-democratization-and-data-first-approach-not-necessarily-good-things-50220607c453). At that time we were not even talking about Generative AI and its risks…

And today, the situation with democratization is even stranger - Microsoft Copilot Studio shipped voice agents last year, Salesforce Agentforce 3 is in market, ServiceNow finished its Knowledge 2026 conference in May 2026 telling its audience that every Now Assist workflow is an agent now, HubSpot ships Breeze, SAP ships Joule, Workday ships Illuminate.

The barrier to assembling an agent has fallen through the floor. That is good news but it also is the source of the trap.

However, it’s worth pointing out that what got democratized is the assembly layer.

The architecture, the governance, the evaluation, the production engineering - none of that got democratized.

That work still has to be done by humans who understand how a language model actually breaks, what a tool call’s failure modes are, and what “permissioned” means when an autonomous process is acting in your CRM at 3am without your involvement.

When the assembly is easy and the engineering is hard, you get a market saturated with people who can configure an agent and a real shortage of people who can engineer one.

That gap is the single most expensive mistake I am watching enterprises make this year.

The work that didn’t get democratized

The agent platform vendors will keep making assembly easier. Copilot Studio will keep adding orchestration primitives, Agentforce will keep adding workflow types, and startups like Sierra will keep raising.

The bottleneck is the gap between people who can assemble an agent and people who can engineer one. It determines who ships and who pauses.

It determines which Microsoft and Salesforce partners actually deliver enterprise value and which ones generate beautiful slideware. And it determines, in our own market, which Dynamics 365 implementations move from “Copilot-enabled” to “agent-mediated”, which is the move every executive reading this should be planning for.

The platform is necessary but it’s the discipline that is often missing. Most teams will keep buying platforms and skipping the discipline, because the platform is what gets sold and the discipline is what needs to get done quietly and it’s not sexy.

Five engineering competencies that are needed to build an AI agent

I have been arguing this for months - what separates the partner who ships a production agent from the partner who ships a brilliant demo is not the model, not the platform, and not the prompt. It is five concrete engineering competencies that have to be present in the building team:

1. Fundamentals

Fundamentals include knowing what an autoregressive model actually does, what context rot looks like in a 200k-token window, what the difference between a hallucination born of insufficient retrieval and one born of conflicting tool outputs is. Also, knowing which reasoning pattern (eg. ReAct, plan-and-execute, reflection) your workflow actually needs. Without this, every architectural decision downstream is cargo cult.

2. Architectural choices

Anthropic’s December 2024 essay “Building Effective Agents” is the best piece of writing in the field on this point and remains required reading. Its central, unfashionable claim is that in the large majority of cases, a single well-tooled agent beats a multi-agent system. Most enterprise AI architecture decks I see right now assume the opposite. Consultants draw seven boxes connected by arrows because seven boxes look serious. And those seven boxes are usually seven failure modes you have not thought about yet.

3. Governance and safety

Permission models that follow least-privilege for the agent’s tool surface. Human-in-the-loop checkpoints at the points where the agent’s actions become irreversible. Audit trails that are forensic, not decorative. Rate limits, cost limits, and a kill switch that someone actually knows how to use. This is the single biggest gap in every enterprise project I have reviewed this year. Most teams think governance is something the legal team writes. In a production agent system, governance is code.

4. Understanding evals and eval-driven development

Hamel Husain has done more than anyone to make this its own discipline, and his insistence that you cannot improve what you do not measure is the right insistence. Real evals for real and useful AI agents are hard and they might require:

• golden datasets

• LLM-as-judge with calibrated rubrics

• regression tests on every prompt change

• A/B in production with task success, cost per task, human-intervention rate as three most important metrics

Without this you are building in the dark and shipping by vibes. Ask any “agent builder” in a random enterprise and you’ll be surprised that they don’t even know what these things are. The fact is that most enterprises right now are shipping by vibes.

5. Production engineering

Apart from proper CI/CD for agent deployment there are also tasks needed where an agent is ahead in production. These are hard tasks that very few current agent builders have a clue about:

• idempotency on every tool call that mutates state

• retry logic that distinguishes a transient failure from a logically failed step

• state persistence and checkpointing so that an agent run can resume rather than restart

• observability through Langfuse, LangSmith, Arize, or whatever your stack chooses, but observability that actually answers the question “What was in the agent’s context when it made that decision?”

This is the boring layer that determines whether your agent survives its first incident and will be useful in production or it will end up as a nice demo for the board.

A word on protocols

The five competencies above assume a stack where tool calls, memory, and agent-to-agent handoffs can actually be made to work in production. That stack is finally getting standards. MCP, Anthropic’s Model Context Protocol, has reached critical mass as the interop layer between agents and the tools, data sources, and resources they need to act. Microsoft shipped MCP support across many products and platforms last year. Google’s A2A (Agent2Agent) is the emerging protocol for agent-to-agent coordination.

This matters more than it sounds. It is the difference between an agent locked into one vendor’s connector library and an agent that can speak to your whole stack without a separate integration each time. It is the difference between a multi-agent system whose handoffs you have to invent and one whose handoffs follow a protocol your governance team can audit.

The real life cases

We have been in intelligent automation for a long time, mostly working within the CRM space, where automation touches either customers directly or processes involved in how companies manage their customers. In 2023 one of our projects (a natural language bot for insurance) was selected by Microsoft as one of the most transformational globally and was featured at their conferences and on Microsoft product websites.

We do not ship intelligent automations, bots and AI agents because the platform let us. We ship them because we ran the five competencies listed above for months before our agents touch any process.

In our work we also learnt the following lessons:

1. Governance is harder than the model. Building the permission model so that the agent could not touch records the user or customer was not entitled to was the longest single piece of work in the project, and the most consequential.

2. Evals are what made improvement compound. Every prompt change ran against a golden set before it merged.

3. The architecture starts single-agent on purpose. We tested a multi-agent version and watched coordination overhead consume the latency budget. We ship the simplest architectures possible in terms of governance, multi-agency and observability.

Conclusion and suggestions

So when your board asks where the AI agents are, and which platform you're buying, point them to a better question:

"Who on this team can engineer an agent, not just assemble one?"

The discipline is the part that gets skipped, because it's quiet, unglamorous, and invisible on a slide. That's exactly why it's the new moat. The teams closing the gap between assembling an agent and engineering one aren't waiting for a better canvas. They're doing the unglamorous work behind the UI that the SaaS “agentic” platforms will never do for them.