The most visible part of an AI project is usually the model or agent. The less visible part is everything the agent must connect to if it is going to do useful work.
A customer-service agent may need customer records, order history, policies and the ability to create a support action. An operations agent may need to read a queue, inspect a database, update a CRM and notify a team. A finance workflow may need to extract information from documents, compare it with system records and route exceptions for approval.
None of those jobs is solved by language generation alone.
An agent can only operate as well as the environment it is allowed to see, understand and change.
Why AI demos look easier than AI operations
A demonstration can work with a clean prompt, a small set of documents and a carefully prepared path. Production operations are different. Data exists across multiple systems. Records conflict. permissions matter. APIs fail. business rules contain exceptions. Actions need owners and audit trails.
McKinsey's 2026 research on agentic AI architecture makes the same underlying point: agents increasingly operate across systems and platforms and therefore depend on interoperable architecture, governed data and clear knowledge of dependencies, ownership and failure modes.
That makes integration a central part of AI strategy, not an implementation detail to solve later.
AI needs access, but access needs architecture
When an AI agent needs business context, there are several ways to provide it: APIs, databases, retrieval layers, documents, application connectors, tool calls or other agents. The technology choice matters, but the more fundamental questions are architectural.
- Which system is authoritative for this information?
- How current does the data need to be?
- What should the agent be allowed to read?
- What should it be allowed to change?
- What happens when two systems disagree?
- Which actions require human approval?
- How are failures recorded and recovered?
If those questions have no clear answers, adding an agent does not remove the ambiguity. It gives the ambiguity a new execution layer.
Fragmented data becomes an AI constraint
Businesses have always been able to survive some degree of fragmented data because people compensate. A staff member knows which spreadsheet is current. A manager recognises which CRM field is unreliable. Someone remembers that a customer record has an exception.
AI systems cannot safely rely on undocumented institutional memory in the same way. They need explicit context, permissions, definitions and reliable access paths.
McKinsey reported in 2026 that data limitations remain a major obstacle to scaling agentic AI and argued for reusable, governed data foundations, stable interfaces and continuous visibility into quality and behaviour.
The lesson for ordinary businesses is not that they need a massive data transformation before using AI. It is that they should stop treating data quality, systems ownership and integration as separate from the AI initiative.
The workflow still matters
Even perfect integration does not answer what the agent should do.
Take a simple request: “automate customer refunds.” That instruction hides a process. Which refunds qualify? What limits apply? Which system holds the payment record? What if the order has already shipped? Who approves exceptions? What customer communication follows? What happens if the payment API fails after the CRM has been updated?
An agent can help execute that workflow, but the workflow still needs to exist as a coherent operating model.
This is why Mellorca treats Business Automation as dependent on Digital Infrastructure and Digital Operations. The three layers are connected.
Five foundations to check before scaling an agent
1. Systems of record
Know which platforms own customer, transaction, product and operational data. If several systems claim authority over the same facts, resolve that first.
2. Stable interfaces
Agents need reliable ways to retrieve information and trigger actions. APIs, connectors and controlled data access should be designed as reusable capabilities rather than one-off shortcuts.
3. Data quality and meaning
The agent needs more than access to data. It needs consistent definitions and enough context to interpret it correctly.
4. Workflow boundaries
Define what the agent may do autonomously, what requires deterministic rules and what requires a person.
5. Operational visibility
Once the agent is acting, the business needs to know what it did, which systems it touched, where it failed and what the outcome was.
Do not rebuild everything just to use AI
Integration readiness does not necessarily mean replacing the existing stack. McKinsey's 2026 enterprise-architecture work describes an incremental path in which agents can extend existing systems through APIs and other integration patterns rather than forcing wholesale replacement.
That is often the sensible route for established businesses. Preserve systems that reliably hold important business logic and records. Improve the interfaces around them. Clean up the worst data and workflow issues. Then introduce AI where autonomy or language capability creates real value.
What better looks like
A business that is ready to scale AI can answer basic operating questions without a large investigation. It knows where important data lives. Systems have defined roles. Permissions are explicit. workflows have owners. Integrations are observable. exceptions have a path. Agent activity can be traced.
At that point AI is no longer an isolated experiment sitting beside the business. It becomes another capability operating through a controlled digital environment.
When to act
If AI pilots repeatedly stall because data is scattered, the same information appears differently across tools, employees have to manually prepare context for the agent, or the proposed agent needs to jump between applications nobody has mapped, the problem may not be the model.
The business may need integration and systems architecture before it needs another AI product.