The future of architecture is context engineering

Why architecture is the discipline that makes AI work

Most organisations don't have an AI problem. They have a coherence problem.


Context is where judgement lives

In the digital era, organisations were told to fix their data. Clean data. Better platforms. Stronger integration. Reliable reporting. Single sources of truth. That work still matters. AI does not remove the need for good data. It raises the bar.

AI systems need more than data. They need context, to understand how work gets done, the policy, risk, roles, service models, sector constraints, decision rights, operating rhythms, customer realities and organisational memory.

  • They need to know why something was done a certain way.

  • They need to know which trade-offs matter.

  • They need to know when a technically correct answer would be organisationally wrong.

That is the difference between information and judgement. Context engineering is the discipline of designing, capturing and maintaining the organisational, sector and role context that AI systems need to produce useful, safe and fit-for-purpose outputs. Put more simply, context is information with judgement.

+1 for ‘context engineering’ over ‘prompt engineering’. People associate prompts with short task descriptions you’d give an LLM in your day-to-day use. When in every industrial-strength LLM app, context engineering is the delicate art and science of filling the context window.
— Andrej Karpathy

The CIO's challenge has changed

For CIOs, the challenge is no longer just selecting the right AI tools. The harder question is how to make AI useful inside the actual organisation. That means asking:

  • What work should AI support?

  • What judgement must remain human?

  • What context does the system need?

  • Who owns that context?

  • How is it kept current?

  • How do we test whether the AI is still behaving properly?

  • How do we stop one team solving the same problem three different ways?

  • How do we turn individual productivity into team and organisational capability?

These questions are not tool questions. They are architecture questions. This is why architecture is moving back to the centre of the AI conversation, not architecture as diagrams and governance gates, but as the discipline that creates line of sight from strategy to capability, from capability to operating model, from operating model to workflow, and from workflow to the agents and systems that support it.


What we heard from leaders

We recently sat down with seven senior leaders working across complex public-sector environments to discuss the next phase of AI adoption. The conversation moved quickly past simple productivity. Faster summaries and better first drafts are useful, but they are not the main game. The stronger themes were more structural.

Leaders wanted the ability to move faster without losing control. They wanted safe ways to experiment. They wanted visibility of what people were already doing. They wanted a better way to prioritise use cases. They wanted governance that did not smother learning. They wanted AI capability to move from enthusiastic individuals into teams, functions and services.

The issue is no longer whether people will use AI. They already are. The question is whether we can bring that energy into a coherent system before the organisation fragments around it.
— Digital Exec, State Government

That is the moment many organisations are now in. The underground “shadow IT” will not stop. The vendor pressure will not slow down. The capability of the tools will keep changing. The answer is not to freeze the organisation until the perfect policy arrives. The answer is to design the right conditions for coherence.

From random acts to coherence

Coherence is the real value proposition. Coherence means AI activity points somewhere, use cases connect to strategy, experiments have a pathway to production, risk is assessed in context, people know what is safe to try, the organisation can see duplication before it becomes waste, and teams can reuse what works.

This is where context engineering becomes practical. A context-rich AI operating model needs several things working together:

  • A living view of organisational capability.

  • Clear decision rights for AI use cases.

  • A way to capture ideas without drowning teams in forms.

  • A triage model that brings business, technology, risk and delivery views together.

  • A context library that captures policy, patterns, examples, prompts, lessons and sector knowledge.

  • Testing and evaluation routines that keep agents safe as models change.

  • Human review points where judgement matters.

  • Roles that curate, maintain and improve context over time.

This is not bureaucracy. It is how you stop enthusiasm becoming entropy.

The new capability architecture

CIOs and architecture leaders need to think about 5 capability shifts.

1. From enterprise architecture to context architecture

Enterprise architecture has always been about coherence, connecting strategy, systems, people, processes and investment decisions. AI makes that work more immediate. Architecture now needs to describe the context agents operate within: the rules of the work, the knowledge needed to perform it, the judgement required, and the boundaries that protect people and the organisation. The architect's role expands from designing the system to designing the conditions in which human and AI work can happen safely.

2. From knowledge management to living context

Most knowledge management efforts fail because they capture artefacts, not judgement. The PPT gets saved, the reasoning disappears. The template gets stored, the trade-offs are forgotten. The decision gets recorded, the debate that shaped it is lost. AI changes the value of that missing layer. The tacit knowledge in people's heads becomes the fuel for better agents, better decisions and faster onboarding.

Organisations need new routines for capturing what happened, why it happened, what was learned, and what should be reused.

3. From pilots to pathways

Many AI pilots fail because nobody designs the path from experiment to production. A team proves something can work, then it hits funding, risk, ownership, support, data, security, procurement and operating model questions. The work slows. The energy disappears.

A mature AI capability needs pathways. Small experiments need a way to be assessed, improved, funded, governed, reused or stopped. Saying no matters as much as saying yes.

4. From tool adoption to work redesign

Most organisations start with tools because tools are visible. The deeper value comes from redesigning work, asking what the workflow should become when agents are part of the team, deciding where humans need more time for judgement, care, creativity, relationship and accountability, and designing the productivity dividend before the organisation simply fills the space with more work. AI adoption without work design creates a faster hamster wheel.

5. From central control to guided participation

AI capability will not live in one central team. The centre still matters, it sets guardrails, platforms, assurance patterns and reusable methods, but the energy is distributed. People close to the work will find the use cases. They will see the friction. They will know where a small change could save hours or improve service quality. The operating model has to harness that energy without pretending it can control every idea from the centre.


What practitioners should lean into

For architects, product leaders, business designers, delivery leads and transformation practitioners, this shift is an opportunity. The market does not need more people who can generate a slick AI demo. It needs people who can make AI work inside messy organisations. That requires new sensibilities:

  • Be fluent in the work, not just the tool.

  • Learn how to capture judgement, not just requirements.

  • Treat prompts as part of a larger context system.

  • Understand risk as a design input.

  • Build reusable patterns, not one-off artefacts.

  • Design human review where trust matters.

  • Think in life cycles, because context decays.

  • Stay close to the people doing the work.

The future practitioner will be part architect, part designer, part systems thinker, part coach, part context curator. That mix will become highly valuable.

You can have all the best agents and platforms, but if you can’t keep the context system tight and fit-for-purpose, the whole thing unravels.

This is the work we do as architects, now wearing its proper name.
— Hugh Evans, CEO, FromHereOn

The context layer is the moat

The agent market will commoditise quickly. Every platform will have agents. Every vendor will claim intelligence. Every workflow tool will add AI features. Many will look impressive in a demo. The strategic question is who owns the context.

If your vendor owns the context, they own a growing portion of your operational knowledge. If your organisation owns the context, you can switch tools, change models, improve agents, reuse knowledge and compound learning over time.

That is the moat. The model is rented. The context is yours.

 

From here on, the work changes

AI will not simply automate the old organisation. It will expose whether the old organisation knows itself well enough to change. The winners will be the organisations that can see their work clearly, encode their judgement carefully, and redesign their operating models around human and AI capability together. That is the work now.

  • From random acts to coherence.

  • From tools to capability.

  • From prompt engineering to context engineering.

  • From architecture as a planning function to architecture as the discipline that makes AI useful, safe and worth doing.

The next era belongs to the masters of context.

Next
Next

Designing your AI pipeline