For decades, we designed architectures to make machines communicate. Artificial intelligence is forcing us to confront a more difficult problem: how machines, knowledge, decisions and people act together inside an organisation.
Yesterday, while listening to a presentation on Amazon Bedrock, I found myself thinking about something that was only partially related to Bedrock itself.
The presentation was naturally about technology: foundation models, enterprise data, security, applications, agents, integration. But as the different components appeared on the screen, I had the strange feeling that I had seen this story before.
Not these technologies, obviously. Something more fundamental.
At the beginning of my career, computing was full of architectures and protocols. We needed them because computers could do extraordinary things individually, but making different systems communicate reliably was another matter entirely. One of the intellectual tools we used to make sense of that complexity was the OSI model.
Seven layers. Physical, data link, network, transport, session, presentation, application.
Few people today designing an AI application need to think explicitly about all seven layers, and the internet did not ultimately develop as a literal implementation of the OSI model. But that is not the important part of the story.
The important contribution of the model was conceptual.
It taught us to separate complexity into layers, to establish responsibilities and, above all, to create interfaces between things built independently. A network did not need to understand the meaning of the application running above it. Each layer performed its function and communicated through defined interfaces.
That separation helped us connect machines.
Looking at the emerging enterprise AI architecture, I wonder whether we are approaching another such moment.
Except that this time the problem is much bigger.
We are no longer merely connecting computers.
We are beginning to connect intelligence to organisations.
Fig. 1 – From connecting machines to connecting intelligence: the emerging AI stack extends beyond technology into knowledge, governance, organisational processes and people.
An enterprise AI architecture can still be drawn as a technology stack.
At the bottom there is infrastructure: compute, storage, networks and cloud platforms. Then data: databases, documents, metadata, vector stores, knowledge graphs and the enormous quantity of structured and unstructured information accumulated by an organisation.
Above this we can place foundation models and AI platforms. Amazon Bedrock is one example; Microsoft, Google and others provide their own environments. Then come applications, copilots and, increasingly, agents: software capable not simply of generating an answer but of planning, selecting tools and performing actions.
But there is another problem.
How does all of this connect?
If every AI application requires a bespoke integration with every database, repository, business application and tool it might need, we reproduce a problem that computing has encountered repeatedly during its history.
And this is where MCP — the Model Context Protocol — becomes particularly interesting.
MCP is not an AWS technology.
It was introduced by Anthropic as an open protocol for connecting AI applications to external tools, resources and contextual information.
Its significance is interoperability.
Conceptually, MCP gives an AI application or agent a standardised way of discovering what capabilities are available and interacting with them. Instead of every combination of agent and tool requiring its own conceptual language, the protocol provides a common mechanism through which capabilities and context can be exposed.
There is something almost reassuringly familiar about this.
We invented protocols to allow computers to communicate.
Now we are developing protocols to allow AI systems to interact with the environments in which they operate.
But the similarity with previous generations of computing ends at an important point.
The things being connected are no longer merely passive technical components.
An AI system may retrieve a document, query a database, inspect a customer record, combine information from different sources, invoke a business service, initiate a workflow and eventually recommend — or execute — an action.
This is also where the relationship with platforms such as Amazon Bedrock becomes clearer.
Bedrock and MCP are not alternatives and MCP is not a component invented for Bedrock. Bedrock provides an environment in which models and agentic capabilities can be deployed. Within the wider AWS agentic architecture, services such as Amazon Bedrock AgentCore Gateway can provide controlled access between agents and enterprise tools, APIs and services, including through MCP.
The distinction matters.
MCP provides a language of connection.
The surrounding enterprise architecture must still provide identity, authorisation, security, credentials, observability and governance.
And the organisation must answer an even more difficult question:
Who has the authority to allow the AI to act?
Fig. 2 – MCP provides a common protocol through which AI applications and agents can interact with tools, data and resources. Platforms such as Amazon Bedrock can participate in this ecosystem, while identity, security, authorisation and governance remain responsibilities of the surrounding enterprise architecture.
This is precisely where a seemingly technical protocol begins to have organisational consequences.
The traditional interaction with generative AI was relatively simple:
human → prompt → model → answer
The emerging agentic environment looks increasingly different:
human → agent → model → knowledge → tool → process → decision → action
And at that point we have crossed an important boundary.
We are no longer designing only an information system.
We are designing part of the organisation.
This becomes particularly visible when we think about security.
In traditional computing environments, security has largely been concerned with questions that we have learned to formalise extremely well.
- Who are you?
- What system can you access?
- Which data can you read?
- Which transaction can you execute?
- What happens when you cross a network boundary?
Those questions remain essential. AI does not make identity management, API gateways, access controls, encryption, logging or cybersecurity obsolete. Quite the opposite.
But an agent introduces another dimension.
- Suppose an AI system has legitimate access to two pieces of information. Does that necessarily mean it should be allowed to combine them?
- Suppose it can call a particular tool. Under what circumstances should it be allowed to use it?
- Suppose an employee asks an agent to perform an action. Is the agent acting with the employee’s authority, its own delegated authority, or the authority of the process in which it operates?
- Suppose the system can infer something that nobody explicitly stored in a database. Who owns that inference?
And if a sequence of individually authorised actions produces an undesirable outcome, where exactly does accountability reside?
This is why I increasingly think that the interesting new perimeter in enterprise AI is not simply the perimeter around data.
It is the perimeter around agency.
Security traditionally asks what a system is allowed to access.
Agency forces us also to ask what a system is allowed to understand, combine, decide and do.
That is a profound change because these are not exclusively cybersecurity questions. They are simultaneously questions of technology, governance, organisational design, management and human responsibility.
And our organisations are not particularly well structured for questions that belong everywhere and nowhere at the same time.
Something similar happens with knowledge.
For decades we have talked about knowledge management. Organisations have accumulated extraordinary quantities of information: documents, databases, presentations, procedures, emails, project repositories, collaboration platforms and intranets.
Yet possessing information has never meant being able to use it.
Some of the most valuable knowledge in an organisation may not be in a database at all. It resides in relationships, experience, institutional memory and in the minds of people who know why something is done in a particular way even when nobody remembers where that decision was documented.
Generative AI changes this equation.
It can make previously inaccessible information searchable through natural language. It can connect fragments from different repositories. It can reconstruct context. It can allow somebody who does not know where information is stored to nevertheless discover and use it.
This is potentially transformative.
But it also exposes something technology could previously conceal.
If the knowledge is wrong, obsolete, contradictory, inaccessible or poorly governed, AI will encounter that weakness.
If two departments maintain different versions of reality, connecting an AI system to both does not magically produce organisational truth.
If expertise has never been captured because an organisation has systematically treated people as executors rather than repositories of knowledge, a language model cannot recover knowledge that was never made available.
AI therefore does something rather interesting to organisations.
It makes their knowledge architecture visible.
And once knowledge becomes directly available to systems capable of reasoning and acting, knowledge management stops being a peripheral corporate function.
Knowledge becomes infrastructure.
This is where I think the discussion becomes much more interesting than the technology itself.
Look at how most organisations are structured.
IT manages technology. Cybersecurity manages security. Data teams manage data. HR manages people. Legal manages compliance. Business units manage processes. Management defines objectives and allocates resources.
These divisions made sense because specialisation made complex organisations manageable.
But an AI agent does not respect the organisational chart.
Consider something apparently simple: an AI agent supporting procurement.
It needs technology infrastructure. It may need supplier data. It needs access to contracts. It has to understand procurement rules. It must comply with security policies. It may encounter commercially sensitive information. It interacts with employees. It may recommend decisions affecting suppliers. Eventually, it might be permitted to perform some actions autonomously.
Who owns that system?
- IT?
- Procurement?
- Cybersecurity?
- Legal?
- The data office?
- HR, because the work of procurement professionals is changing?
- Senior management, because part of the organisation’s decision-making capability is being delegated?
All of these answers are simultaneously correct and incomplete.
And that is precisely the problem.
We have specialists for almost every component of the emerging AI organisation.
What we often lack are people capable of understanding the relationships between the components.
Fig 3 – As AI moves from answering questions to accessing knowledge, using tools and taking actions, the boundaries between technology, management and organisational roles become increasingly blurred. The emerging capability is the ability to connect these layers.
For a long time we maintained a convenient distinction between “the technology” and “the business”.
Technology people understood systems. Business people understood the organisation.
Even when the distinction was artificial, it gave us a useful division of labour.
AI is making that boundary increasingly difficult to defend.
The person designing an agent needs to understand something about the process in which it operates. The person responsible for the process needs to understand something about what an agent can actually do. The security specialist needs to understand the consequences of AI reasoning across different information sources. Management needs to understand what kind of authority is being delegated. HR needs to understand how expertise and responsibility are changing.
And somebody needs to understand how all these things fit together.
This is why I suspect one of the most important professional profiles of the AI era may not yet have a stable name.
- It is not simply the AI engineer.
- It is not simply the CIO.
- It is not the management consultant, organisational designer, knowledge manager or HR professional either.
Perhaps it is some combination of all of them.
We need people who understand enough of the technology stack to have meaningful conversations about models, agents, APIs, MCP, identity, data and security.
But they must also understand the organisational stack: processes, governance, incentives, decision rights, institutional structures and accountability.
And increasingly they must understand what I would call the people stack: expertise, trust, motivation, culture, collaboration and the mechanisms through which human beings create and transmit knowledge.
These people do not need to be the world’s greatest specialist in every layer.
Their value comes from seeing between the layers.
They are the people capable of asking not only:
Can we build it?
but:
What happens to the organisation when we build it?
Not only:
Can this agent access the information?
but:
What new knowledge can it construct by combining that information?
Not only:
Can we automate this decision?
but:
What happens to expertise and accountability when we do?
And not only:
Where should we put the human in the loop?
but:
Does that human actually possess the knowledge, time and authority necessary to exercise judgement?
That last question is particularly important.
We speak constantly about “human-in-the-loop” as though the physical presence of a person somewhere in a workflow automatically guaranteed meaningful oversight.
It does not.
A person clicking approve on an AI-generated recommendation without sufficient information, authority or time is technically in the loop but institutionally almost irrelevant.
Meaningful human oversight requires an organisation capable of supporting disagreement, interruption and judgement.
Perhaps, therefore, what we really need is not simply a human in the loop.
We need the organisation in the loop.
- Governance must be in the loop.
- Knowledge must be in the loop.
- Accountability must be in the loop.
- Authority must be in the loop.
And human judgement must be there not as a ceremonial final click, but as a genuine organisational capability.
This brings me back to MCP.
MCP will evolve. Other protocols and architectural patterns will emerge. Some of today’s terminology will almost certainly disappear. That is normal in technology.
The deeper transition will remain.
AI is moving from something we consult towards something that participates.
- From answering questions to retrieving knowledge.
- From retrieving knowledge to using tools.
- From using tools to executing processes.
And, in some contexts, from executing processes to exercising a degree of delegated agency.
Every step makes the technology more useful.
Every step also embeds it more deeply into the organisation.
That is why looking at enterprise AI purely as another technology transformation misses the point.
Cloud computing changed where we ran our systems.
Mobile changed where and how we interacted with them.
The Internet changed how systems and people connected.
AI may change something more fundamental:
how organisations transform knowledge into action.
And once that happens, the distinction between technical architecture and organisational architecture begins to dissolve.
The architecture of AI becomes partly the architecture of authority.
The architecture of data becomes partly the architecture of knowledge.
The architecture of agents becomes partly the architecture of work.
And the architecture of security becomes partly the architecture of trust.
This is why the people capable of connecting these worlds may become so important.
Not because specialists will disappear. We will need excellent engineers, cybersecurity professionals, data scientists, lawyers, organisational experts and managers more than ever.
But specialisation alone will not solve a problem whose defining characteristic is the interaction between specialities.
The OSI model helped a previous generation understand how independently designed technical layers could work together.
Perhaps the challenge now is to develop the equivalent intellectual architecture for the intelligent organisation.
One that connects technology, knowledge, governance and people without pretending that they are separate systems.
We spent decades learning how to connect machines.
We are now learning how to connect machines to knowledge, knowledge to decisions, decisions to actions, and actions back to human purpose.
That is no longer simply an IT problem.
It is organisational design for an age in which intelligence itself is becoming part of the infrastructure.
