Key AI Insights from AWS Summit Madrid 2026

I had the privilege of attending AWS Summit Madrid 2026, and I wanted to take the time to share my impressions of what I saw: where the short-term future of AI is heading, and how organisations are beginning to use it in ways that are changing how systems are built and operated.

There was a clear shift toward pragmatism this year. Conversations moved beyond speculative AI potential to focus on current, reliable implementations. Whether in keynotes or breakout sessions, a consistent theme emerged: the transition from basic Large Language Model (LLM) use cases to robust, production-grade agentic systems.

New models continue to attract attention, and AWS had their usual announcements around Nova and the broader Bedrock portfolio. But the most valuable discussions weren’t about which model is best. They were about architecture, orchestration, governance, memory, and what it actually takes to operate AI systems at scale.

The Shift from Single Agents to Multi-Agent Systems

Multi-agent architectures were one of the most present and important topics of the event, not as an exotic future concept, but as a practical necessity that teams are actively grappling with today. The conversation has matured considerably. We’ve moved past “can we build an agent that does X?” and into “how do we build agents that work together reliably at scale?“

The framing that resonated most with me was the shift from short-lived, stateless agents to long-running, stateful workflows with distributed responsibilities. In enterprise environments, the tasks worth automating are rarely simple enough for a single agent operating in isolation. They involve coordinating information from multiple domains, executing multi-step processes over time, and handling failures gracefully.

One of the recurring problems with traditional supervisor-agent architectures is that the main agent eventually becomes overloaded with information coming from multiple subagents. Every completed task, every intermediate result, every error message gets routed back to a central coordinator that must process all of it. This creates two compounding problems:

1. The context window fills rapidly with noise.
2. The central agent becomes a bottleneck.

The more promising architectural patterns showcased on the ground centred on eliminating that bottleneck. Instead of a hub-and-spoke model where everything flows through the orchestrator, the focus shifts to a shared state.

As illustrated above, this involves a shared task list that subagents can write to and claim from, shared memory systems that persist relevant context without flooding any individual agent, and intermediate coordination layers that broker communication between specialised workers. Agents communicate through structured state rather than conversational history. The orchestrator spawns work and defines success criteria; it doesn’t need to receive a full transcript of every intermediate step.

“These patterns don’t just perform better, they scale better. And for enterprise environments where agent workflows will eventually touch thousands of users and dozens of internal systems, scalability is the ballgame.”

What I found compelling about this approach is that it mirrors how effective engineering teams actually work. A tech lead doesn’t need to read every line of code written by every engineer. They define the task, set the standard, and review the output. Designing agent systems with that same principle in mind, preserving coordinator attention for what actually requires coordination, is, in my view, the right direction.

AgentCore and the Operational Layer of Agents

If there was a single announcement that felt most strategically significant from AWS’s perspective, it was the depth of investment behind Amazon Bedrock AgentCore. The technical presentations made clear that AgentCore represents AWS’s answer to a question that enterprises are starting to ask loudly: how do you actually run agents in production?

The core capabilities: runtime, identity, gateway, memory, observability, and tools aren’t glamorous. They’re the underlying infrastructure that everything else is built on. In practice, every team building serious agent systems eventually has to implement these capabilities themselves, unless they’re provided as infrastructure. AgentCore is that infrastructure.

The observability story, in particular, was especially interesting. Anyone who has operated distributed systems knows that logs alone are not enough when something breaks, you need the full trace, the decision chain, and the context. Multi-agent workflows are no different. AgentCore’s step-by-step execution visibility, combined with CloudWatch’s GenAI-specific metrics, reflects a clear design intent: agents should be observable and debuggable the same way any other production system is. That’s the right standard to hold them to.

Twelve months ago, most engineering teams were still asking how to build an agent. The question dominating conversations at this summit was different and harder: how do you run one reliably, at scale, day after day? That shift in focus is meaningful, and AgentCore is squarely aimed at answering it.

Why AgentCore Gateway Could Become a Key Enterprise Pattern

Of all the AgentCore capabilities, the Gateway component generated the most interesting architectural discussion. The concept is straightforward in description but significant in implication: a unified access layer that sits between your agents and everything they need to interact with — internal APIs, external services, and Model Context Protocol (MPC) compatible tools.

One of the most practically valuable concepts discussed, and one that I think is underappreciated in current agent design, was the idea of semantic tool discovery. The default approach to building tool-using agents is to define a list of tools and pass them all to the model on every call. At a small scale this works fine. At enterprise scale, with agents that potentially have access to hundreds of tools across a gateway, it creates a twofold problem:

• Context bloat: Large tool lists consume significant context window space — space that could be used for reasoning, retrieved knowledge, or conversation history.
• Cognitive load: More subtly, model performance degrades with excessive tool options. The cognitive load on the model increases, tool selection quality drops, and the model becomes more likely to either choose the wrong tool or get confused by overlapping functionality.

The solution presented was semantic retrieval: before the model ever sees the tool list, an embedding-based search determines which tools are actually relevant to the current request. If the agent is trying to look up a flight status, it doesn’t need access to the restaurant recommendation API or the luggage policy tool. The gateway filters the tool set dynamically and presents only what’s contextually appropriate.

“Tool catalogues for agents need to be treated like search indexes, not static lists. The infrastructure that serves tools to agents should be as thoughtful as the infrastructure that serves data to applications. Building this well is a platform-level responsibility, not something individual agent implementations should be doing ad hoc.”

RAG is Becoming a Tool

A recurring theme across the technical tracks was a clear maturation of the industry narrative around Retrieval-Augmented Generation (RAG). A year ago, RAG felt like the default answer to every AI architecture question. Now, the framing has shifted in a more sensible direction: retrieval is increasingly just another tool available to agents, not the structural backbone of every architecture.

The new consensus? Avoid retrieval on every interaction, only retrieve when the task genuinely requires grounding in external knowledge. When you do retrieve, focus on relevance rather than volume. The consensus recommendation was 3–5 chunks for most use cases, not 20. More retrieved content doesn’t mean better answers; it often means more noise and worse signal-to-noise ratio in the model’s context.

What I appreciated about this approach is that it treats RAG as a design choice rather than a default. The agent asks: do I need to look something up? If yes, it invokes retrieval as a tool, retrieves focused and relevant content, and proceeds. If not, it doesn’t. This is more cost-efficient, faster, and produces cleaner reasoning chains than architectures that retrieve content into every prompt regardless of whether it’s needed.

For teams currently designing RAG pipelines as the primary architecture for their AI systems, I’d encourage a step back. The question isn’t “how do we build a better RAG?” It’s “what does the agent actually need to do, and is retrieval the right mechanism for each step?” Sometimes the answer is yes. Often it isn’t.

This is actually a problem we’ve tackled directly at Parser with several of our clients. Rather than committing upfront to a single retrieval strategy, we implemented an agent that first decides whether retrieval is needed at all. When it is, it selects the most appropriate approach based on the nature of the question.

As shown in our framework above, a straightforward factual query might call for naive RAG with a simple vector search. A question that requires understanding relationships between concepts or traversing connected data will route instead to a hybrid approach that combines vector retrieval with Graph RAG. Letting the agent make that decision dynamically, rather than baking a single retrieval strategy into the architecture, has consistently produced better results and lower costs for our clients. It’s a pattern I’d encourage any team operating at this level of complexity to consider seriously.

The Emerging AI Developer Experience

The summit also offered a meaningful look at Kiro and AWS Quick, AWS’s emerging AI-native developer tooling.

What stood out about Kiro in particular is its commitment to a spec-driven workflow. Rather than generating code directly from a natural language prompt, it first produces a structured specification, a human-readable, reviewable artifact that captures intent, constraints, and design decisions, and only then translates that spec into implementation.

This is a fundamentally different philosophy from the “AI as autocomplete” model that has dominated developer tooling so far, and in my view, a much sounder one. Specs are auditable. They can be versioned, reviewed, and challenged before a single line of code is written. That matters enormously in team environments and regulated contexts.

AWS Quick extends this thinking to the broader work context, pulling from files, messages, documents, and knowledge graphs to assemble the full picture an agent needs before acting. Together, both tools point toward the same shift: the software development workflow itself becoming a spec-driven agentic system, where the developer’s primary output is intent and structure, not raw code. That’s a meaningful change in how engineering teams will operate, and reviewing both tools in depth became an immediate follow-up action item after the summit. The implications for platform and developer tooling teams are significant.

That said, both tools come with caveats worth flagging before any team commits to them at scale.

• Token consumption: Kiro’s token consumption can add up quickly once specs and generated code start iterating back and forth. For teams used to thinking in terms of IDE licenses, the shift to usage-based AI costs takes some getting used to in budgeting conversations.
• Pricing & gaps: AWS Quick, similarly, carries a per-user cost that needs to be modelled carefully against the productivity gains it promises, especially for larger teams. And as of this summit, Quick is not yet integrated with the AWS-specific infrastructure knowledge that Q Developer has built up, so for teams deep in AWS-native development, there’s still a gap between the assistant that knows your cloud environment and the one that’s driving the broader agentic workflow.

None of this is disqualifying, but it’s the kind of detail that gets lost in a demo and shows up later in a procurement conversation.

Open Source Ecosystem: Strands and Platform Engineering

The open-source ecosystem deserves its own honest assessment, because the tooling choices made at the framework level have long-term consequences that are easy to underestimate in the early stages of an AI project.

Strands Agents, AWS’s open-source agent framework, appeared consistently across the technical sessions, and it’s worth taking seriously. The agent framework layer is where a lot of teams face difficult tradeoffs. LangChain has been the default starting point for many organisations over the past two years, and it has genuinely helped the ecosystem move fast and experiment broadly. But as teams move from prototype to production, the requirements change: you need finer control over execution, cleaner debugging, and the ability to reason about what your agent is actually doing at each step.

Strands takes a leaner, more composable approach that is better suited to that production context. The fact that it’s open-source while being designed to run on AWS-managed infrastructure is a sensible middle ground, you retain flexibility without taking on the full operational burden yourself.

The broader point here matters more than any specific framework choice: platform teams are no longer just managing infrastructure. In the AI era, they are responsible for model routing, governance, cost attribution, observability, and ensuring that every team in the organisation accesses models through patterns that are safe and auditable by default.

The organisations doing this well have stopped thinking of their internal AI platform as a provisioning layer and started treating it as a product with real users, real SLAs, and real consequences when it fails. That shift in mindset, from infrastructure team to platform product team, is, in my view, one of the most underrated organisational changes AI is forcing on engineering leaders right now.

Sovereign AI and European Cloud Strategy

At an event held in Madrid, it would have been surprising if Sovereign AI didn’t feature prominently — but the depth and urgency of the discussion exceeded my expectations. For European organisations operating in regulated industries, the question of where AI runs and who controls it has moved from a compliance checkbox to a core architectural constraint.

The conversation I observed has shifted notably. A year or two ago, enterprise AI discussions in Europe were dominated by model selection: which foundation model should we use? Today, the questions that matter most are different:

• Where does inference happen?
• Who has visibility over the data?
• What contractual guarantees exist around data residency?
• Can we demonstrate to our regulator that model weights and training data never left the EU?

These aren’t abstract concerns. For financial services, healthcare, and public sector organisations in particular, the answers to these questions determine whether a project can proceed at all.

The announcement that the AWS European Sovereign Cloud is now live, with fully isolated infrastructure operated by EU citizens and sovereign Local Zones coming to Belgium, The Netherlands, and Portugal — was well-received. Whether or not AWS is the right provider for a given organisation’s sovereign AI strategy, the infrastructure is increasingly there. What’s still developing is the organisational capability to design, procure, and govern AI systems within that infrastructure in a way that satisfies legal, security, and operational requirements simultaneously.

Final Thoughts

The future of enterprise AI is not about bigger models. It’s about better systems.

The models we have today are more capable than most organisations know how to use well. The limiting factor isn’t inference quality. It’s orchestration, governance, memory, tooling, observability, and the organisational muscle to operate AI systems the same way we operate any other production system, with rigorous engineering discipline, clear ownership, and the infrastructure to detect and respond to failures.

The most important innovations happening in our industry right now are not in foundation model benchmarks. They’re in runtime platforms like AgentCore, in patterns for multi-agent coordination, in governance frameworks that can satisfy European regulators, and in the emerging tooling that helps developers work with AI at the architectural level rather than the prompt level.

The next 12 to 24 months will likely determine which organisations successfully operationalise AI agents at scale, and which ones accumulate a pile of impressive demos that never made it to production. The difference will come down to whether engineering leaders treat AI infrastructure with the same seriousness they’ve brought to cloud infrastructure, data platforms, and developer tooling over the past decade. The technical building blocks are there. The engineering culture and platform discipline are still catching up.

At Parser, we are helping organisations navigate this transition by drawing on experience gained across multiple cloud providers, technology stacks, industries, and AI adoption journeys. This cross-functional perspective provides visibility into recurring challenges, proven architectural patterns, and practical approaches for moving from experimentation to production. As the ecosystem evolves, the ability to apply lessons learned across domains is becoming a key differentiator in building AI systems that are scalable, governable, and capable of delivering sustained business value.

If you’re exploring how to operationalise AI within your organisation, feel free to reach out to us at Parser. We’d be happy to share our experience, discuss your challenges, and help identify the architectural and organisational patterns that can accelerate your path from prototype to production.

References

• Amazon Web Services: Amazon Bedrock Agent Core Service Page
• Amazon Web Services: AWS Quick Core Product Overview
• AWS Europe: AWS European Sovereign Cloud & Compliance Infrastructure
• AWS Industries Blog: From Spec to Production: A Three-Week Drug Discovery Agent Using Kiro
• AWS Machine Learning Blog: Introducing Amazon Bedrock AgentCore Gateway: Transforming Enterprise AI Agent Tool Development
• AWS Open Source Blog: Introducing Strands Agents: An Open-Source AI Agents SDK
• AWS Solutions Library: Guidance for Multi-Agent Orchestration Using Bedrock AgentCore on AWS
• Kiro Developer Platform: Kiro Spec-Driven AI Development
• LangChain Framework: LangChain Official Documentation