AI in 2026: Architectures for a World of Agents 

In 2026, the AI and data stack looks fundamentally different from just a few years ago. The focus has shifted from training individual models to building AI systems – multiple models, retrieval components, agents and orchestration logic working together. Data platforms now serve both traditional analytics and AI workloads, with more emphasis on unstructured data. 

These changes create a new set of architectural challenges. This article reflects the perspective of DAIN Studios on how to design AI architecture and agents in 2026, supported by insights from our Chief Data & AI Officer, Hugo Gävert. 

Adaptability and flexibility as a design principle 

Not every part of the architecture changes at the same pace, and design decisions should reflect this. The AI infrastructure layer – foundation models, vector databases, orchestration frameworks – evolves rapidly. What you build today may be commoditized in 12-18 months. This argues for buying where possible and designing for portability across providers. 

Domain-specific components are different. The way you process insurance claims or analyze geological data doesn’t change every quarter. Building here is safer, and it’s often where your differentiation lives. 

“The technical stack has to be flexible. Model versions change, frameworks evolve, and what works today may not be the right choice next year. The architecture should make component changes routine, not painful.” 

– Hugo Gävert, Chief Data & AI Officer, DAIN Studios 

The practical implication: favour modularity and clean interfaces at the model layer, but don’t mistake that for a mandate to make everything swappable. Some parts of your architecture should be stable and deeply owned. 

Agents as the new execution layer 

One of the clearest shifts is the move from single-turn assistants to multi-step agents. Instead of answering one question at a time, systems are now being designed to plan, call tools, take actions and collaborate with humans. 

“An agent is an entity that has an LLM as a brain and tools with which it can access data and perform actions. The distinction from a simple assistant is a loop: it decides what to do next based on the context and it may iterate. It is still built for a specific task or role, rather than being a general purpose intelligence. Typically part of an agentic system or a team.” 

In practice, agents might place orders, update records, draft and send messages, or trigger workflows across several systems. They can also call other agents specialised in narrow tasks. This creates a new execution layer in the organisation: a mix of humans, agents and traditional automation working together on the same processes. 
 
Where do agents work reliably today? Customer support triage and resolution—looking up accounts, processing refunds, escalating appropriately. Code generation workflows where tests provide immediate feedback. Document processing where varied formats require adaptive approaches. 

“The successful cases share common traits: constrained action spaces, clear feedback signals, recoverable failures, and human oversight on consequential actions. The useful question isn’t, should we build agents? but where does adding a decision loop actually help, and where does it just add failure modes?” 
– Hugo Gävert, Chief Data & AI Officer, DAIN Studios 

For this to work, the architecture has to give agents a safe but powerful way to act. That includes robust tool interfaces, clear boundaries around what they are allowed to do, and observability into what they actually did. It also means designing user experiences where humans stay in control of outcomes without needing to micromanage every step. 

Connecting AI to enterprise systems 

 
A key part of this architecture is how AI systems connect to enterprise applications – CRMs, ERPs, databases, workflow tools. Several patterns matter here. 
 

First, a gateway for model access. Don’t let every application call LLM APIs directly. Route through a central gateway that handles authentication, rate limiting, cost tracking, and logging. This gives you one place to enforce policies, switch providers, and monitor usage. Without it, you get shadow AI and no visibility. 

 
Second, abstraction between the model and backend systems. The agent shouldn’t need to know whether customer data lives in Salesforce or SAP. Build a semantic tool layer that exposes capabilities like “get customer orders” or “update contract status” regardless of the underlying system. This lets you swap backends without rewriting prompts and agents. 

 
Third, read-heavy, write-careful. Most successful integrations start with read-only access. Let the agent query systems, but don’t let it update records autonomously—at least not initially. When you do enable writes, use a queue-and-approve pattern: the agent proposes changes, a human or rule-based system approves, then the write executes. 

 
“The model layer and the enterprise layer need clean separation. A gateway for governance, abstractions for flexibility, and caution around write access until you’ve earned trust in the system.”  
– Hugo Gävert, Chief Data & AI Officer, DAIN Studios 

Security and identity in an agent world 

As agents gain access to more systems and data, security becomes a central architectural concern. Identity is more complicated than it looks. When an agent acts on behalf of a user, whose permissions apply? The answer should be the user’s, butimplementing this requires propagating identity through the entire chain – from user to agent to every tool and data source. Most systems weren’t built for this delegation model. Each agent should also have its own credentials with minimal necessary permissions. 
 

Fine-grained access rights are genuinely hard. Indexing content into vector databases is needed for performance, but source systems like SharePoint often don’t expose permissions via API. You cannot replicate what you cannot see. And when permissions change at the source, how do you reflect that in the index? This remains a real bottleneck for enterprise AI. 

Prompt injection is a real attack surface. When agents consume external data – emails, documents, web pages – that data can contain instructions that hijack the agent’s behavior. This isn’t theoretical. Defenses include input sanitization, separating instructions from data, and output validation. None are complete solutions. 
 

This is one reason why guardrails matter at multiple layers. Input guardrails catch problematic requests before they reach the model. Output guardrails catch problematic responses before they reach users or downstream systems. Action guardrails prevent the agent from executing dangerous operations. You need all three – defense in depth, not a single gate. 

 
Finally, every action an agent takes must be logged with who initiated it, why the agent decided to take it, what the action was, and what happened. This isn’t optional for regulated industries, and it’s wise practice regardless. 

Build what differentiates, buy the rest 

Where does your differentiation actually come from? It’s unlikely to come from running your own vector database or building a custom gateway. It comes from your data, your domain logic, your workflows, and your understanding of your customers’ problems. 

Some things should almost always be bought: foundation models and basic infrastructure like vector databases, API gateways, and monitoring tools. These are mature categories with good options, and you benefit from the vendor’s continued investment. 

Some things should almost always be built: your evaluation framework, because no vendor knows what “good” means for your use case; domain-specific tools that connect AI to your systems with your business logic; and the data pipelines that prepare your proprietary data for AI consumption. This is where your data advantage gets operationalised. 

Some things are of course case-by-case: orchestration frameworks, RAG infrastructure, and whether to fine-tune models. Fine-tuning is sometimes worth it, but often prompting and few-shot learning are enough – start there before investing in training. 

“Buy” isn’t free – you pay for integration, customisation, and vendor constraints. “Build” isn’t just engineering time – it’s ongoing maintenance and opportunity cost. The goal is clear: own what makes you different, buy what doesn’t. 

What leadership should focus on in 2026 

Some technical decisions are hard to reverse and should be made now. Design for flexibility at the model layer – don’t lock yourself into a single provider or framework. Invest in organizing your unstructured data – documents, emails, recordings – so AI systems can actually use it. Establish logging and evaluation infrastructure early; the organisations that start capturing this data now will have the ability to measure and improve by 2026. And standardize on clean tool interfaces; how your AI systems connect to enterprise applications will become deeply embedded. 

But the real bottleneck by 2026 won’t be technology. It will be people who understand how to apply it. 

Organisations that treat AI as a specialist function will be slower than those where product managers, analysts, and domain experts can work effectively with AI tools. The shift requires product thinking, not project thinking – AI capabilities owned and iterated on, not delivered and forgotten. It requires business people who can specify what they need, not just request “something with AI”. And it requires teams with shared accountability for outcomes, not handoffs between business, IT, and data. 

The architecture matters. But architecture without the right people and ways of working will sit unused.