In many companies, artificial intelligence left pilot status a long time ago. First chatbots are running in customer service, copilots support employees, and AI agents handle individual process steps.
Even so, many companies face the same problem: the pilot works, but the move into productive operation does not succeed.
That is rarely because the underlying AI model is not capable enough. Far more often, what is missing are the prerequisites around data, interfaces, permissions, monitoring, and accountability.
In 2026 the central question therefore shifts. No longer "What can our AI agent do?" but "How do we operate it reliably once it genuinely becomes part of our business process?"
From proof of concept to productive system
A proof of concept has one decisive advantage: it is small.
A team tests an agent with a limited amount of data, few users, and a clearly defined use case. If something does not work, a developer can step in.
In productive operation the situation looks different. An agent may access CRM, ERP, and support data. It communicates with customers. It creates tickets. It edits records. It may even trigger new processes.
That changes the risk profile as well. A mistake is then no longer just a poor answer in a test system. It can trigger incorrect customer communication, a faulty record, or an unwanted process action.
This is precisely why scaling up a successful pilot is not enough. The architecture has to grow with it.
The five hurdles on the way into production
1. Data access rather than model performance
A capable model can only work with the information available to it. That sounds trivial, but in companies it is one of the biggest challenges.
Customer data sits in the CRM. Contract information is in the ERP. Support cases are stored in a ticketing system. Documents sit in various repositories.
An agent that cannot reliably bring this information together stays superficial. Data architecture therefore becomes a decisive part of any agent strategy.
The question is not only "Which model do we use?" but "What information does the agent need in order to perform the task correctly?"
2. Tools and APIs become the actual interface
An agent becomes interesting as soon as it does not merely deliver information but can act. For that it needs tools.
For example, it has to be able to:
- read a customer record
- create a case
- check an order
- retrieve information from an ERP
- prepare an email
- start a workflow
API and integration architecture thus suddenly become an AI topic. The agent does not need unrestricted access to the company. It needs controlled access to exactly the capabilities its task requires.
The principle resembles classic least-privilege concepts, but it matters even more with agents, because such a system can chain decisions together dynamically.
3. Permissions have to work at the agent level
A common mistake in early agent projects is the question "Can the agent access Salesforce?"
The question should be "Which Salesforce data may this agent use, and for what purpose?"
A sales agent may need customer data and open opportunities. A support agent, by contrast, needs cases, contract information, and communication history. The two should not automatically receive the same rights.
This is not only about reading and writing, but also about actions that have to be controlled.
May an agent:
- contact a customer?
- grant a discount?
- cancel an order?
- delete a record?
- trigger an escalation?
The closer an agent gets to real business processes, the more important clear boundaries become.
4. Human-in-the-loop is not a sign of bad AI
Using agents productively does not mean people have to disappear from every process. Quite the opposite.
For certain actions, human approval can make more sense than full autonomy. An agent might draft a contract, for instance, while leaving final approval to an employee. Or it recognises an unusual customer request and escalates it automatically.
The goal should therefore not be 100% autonomy, but the right balance between automation and control.
5. Monitoring matters more than the pilot itself
With classic software, a company asks "Is the application working?" With agents, that question is no longer enough.
Companies additionally need to understand:
- Which tools does the agent use?
- Which data sources does it call?
- Which actions does it perform?
- How often does a task fail?
- When does it need human support?
- Which processes cause the most errors?
A productive agent therefore needs observability. Not only for the infrastructure, but for its behaviour.
The new architecture for AI agents
A production-ready agent architecture consists of several layers:
Model → Agent → Tools → APIs → Data → Governance → Monitoring
None of these layers can be considered in isolation.
A good model helps little if data quality is poor. Good data helps little if the agent has no interfaces. Secure interfaces help little if nobody defines what the agent is allowed to do at all. And good governance helps little if nobody can trace what actually happened.
What companies should do now
The path from pilot to production does not have to start with a bigger model. It should start with taking stock.
-
Define the use case Which concrete task should the agent take on?
-
Determine the data What information does it need for that?
-
Define the actions What may it read, change, or trigger?
-
Set the boundaries Which decisions require human approval?
-
Standardise the interfaces How does the agent get controlled access to the required systems?
-
Build monitoring How does what the agent does become visible?
-
Define accountability Who is responsible for the agent, both functionally and technically?
Conclusion
The next big step with AI agents is not the next pilot. It is the transition to an operational system.
Companies that want to scale agents successfully therefore have to think beyond the model. Data, APIs, permissions, governance, and monitoring become just as important as the AI itself.
The decisive competitive advantage does not come from building the most intelligent agent. It comes from controlling it safely and integrating it reliably into existing business processes.