Reflections on the AWS Ambassador Summit

Introduction

This is the second year I’ve been able to attend the AWS Ambassador Summit in Seattle thanks to Logicalis Spain.

The AWS Ambassador Summit is a 3-day event where all AWS Ambassadors can go to learn and build community.

During these 3 days AWS tells us many things that are under NDA and that I can’t share, but there are others I can.

The event features different types of sessions, from more strategic talks for Partners (remember my company sponsors this), talks about new services or features (NDA), strategic talks about AWS (where we’re headed), roundtables with AWS Service Teams (lots of questions and roadmap), an agents workshop (based on the FIFA World Cup 2026), and several social events.

Additionally, during this event we get to enjoy the knowledge of many important AWS people who participate in the different sessions like Rahul Pathak, Rudy Chetty, Jigar Thakkar, Laura Grit, and this year we were even lucky enough to have Swami Sivasubramanian stop by to say hello.

But what’s the most important thing about the event? It’s not the talks or the roadmaps, not being at AWS offices in Seattle, not meeting Jeff Barr in person (although that’s pretty cool).

The most important thing is that over 120 Ambassadors from 40 different countries come together and we can share our points of view, our problems (which are very similar), and how we see things going forward.

This might seem counterproductive for our companies, but it’s actually the opposite, because in almost 95% of cases we don’t share the same business region and even if we do, we don’t usually compete directly. Obviously we don’t share our companies’ strategies, but we do discuss what we see out there.

I can tell you there’s no other place where I feel impostor syndrome as strongly as here, and this isn’t false humility — I know I’m exceptional at my job, but within this program you’ll find the best of the best. Being great is the bare minimum.

Agents, Agents, and More Agents.

I don’t think it’ll surprise you if I say that everything revolved around agents and all the new capabilities that are about to be unlocked.

Here’s something I suspected: one-year roadmaps are over. With the entire Agentic revolution, the industry has reached absurd speeds. So much so that thinking about what might come in a year has stopped making sense. We can sketch where we want to go, but we can’t plan revolutions a year out when everything can change in a few months.

But several things came up here that I’d like to discuss in more detail.

The importance of data.

It’s true that the industry moves very fast, but sometimes we need to stop and reflect. No matter how intelligent our agents are, how well coordinated they are with each other, how incredible their prompts are with MCP integrations connected to your APIs, databases, and internal tools — if the data they consume is bad or outdated, they’re useless and their responses will be bad.

For example, an agentic system for automating operations — if it’s pulling from outdated or overlapping procedures, or even ones that are missing steps (because the operator knows them by heart), it’s going to fail or do things we don’t want.

And speaking among ourselves, this is quite common. In many cases we’re finding that the step of improving, governing, and relying on data hasn’t been done, but we want to deploy agentic systems right now.

Many architectures are deficient.

When two architects get together, the dirty laundry always comes out — so imagine when over 100 of us get together.

That’s why the PocketSO case came up. It’s true it’s a very extreme case and the problem wasn’t the agent itself, not even that it had too many permissions (although that was part of the problem).

The main problem is that the solution’s architecture didn’t follow minimum best practices — environments weren’t separated, backups were on the same volumes and could be modified, etc.

It’s true that giving root permissions to an agent without defining limits is a problem, but there are very bad architectures in production. It’s something we all know, we all suffer from, and it’s not local — it happens worldwide.

And this is something we’re going to see a lot more of unfortunately. In fact, we sometimes see it without AI being involved at all.

Someone didn’t know they had to perform an arcane ritual before a production deployment and the entire environment went down for hours. It sounds like a joke, but many times we do things poorly simply because we’ve automated them in our context, and when someone without that context executes it, you get a 20-hour production outage (never happened to me…).

This was something that concerned everyone a lot — handing the keys to the dungeon to an agent without that context and without solving these problems can be very problematic.

The Gap between C-Level and the Technical Layer.

This also came up a lot in our conversations: there’s pressure from C-Level to use agentic systems that is disproportionate and in many cases absurd.

Don’t get me wrong — many of us have probably been using agents, assistants, and GenAI since the beginning of this revolution, but also because of this we know their limitations.

We know how to use prompts, add context to steering files, add Skills, figure out why the prompt is skipping an important instruction, know that a huge context is almost worse than a small one, learn to structure contexts to make them easier to use, etc. If you’ve wrestled with agents, you know what I’m talking about.

The problem is that we’re all suffering situations where someone with a minimal prompt (and probably a bad one) tries to tell you how to do your job, how to design an architecture, even challenging your decisions without being able to defend what the AI told them (the phrase “Claude told me” or “ChatGPT said so” is used way too much). This is creating a massive gap in agentic adoption.

In many cases the executive vision is very simple, when the implementation has many more edges than we think.

Something that’s been happening to me lately is receiving an AI-generated architecture to validate because it needs to be implemented now, and it turns out it’s completely unworkable. Nothing about the current context has been considered — if you ask about a data model or how they’ve thought about security, they look at you funny.

The problem isn’t using AI to explore ideas (that’s great), the problem is confusing a bad LLM output with a validated plan (mind you, a well-built agent CAN do this). And we’re stuck between a rock and a hard place: either we reject it and look resistant to change, or we accept it and sign up for technical debt we’ll be paying for years.

What is an Agent.

Agents are the future, but everything is an agent.

This may seem absurd, but we’re all seeing that in many cases people talk about agents when they’re using a plain old automation, or even worse — people converting existing automations into agents, making LLM calls just to justify that they’re using agents.

I’ve seen things no one would believe: an “agent” that calls an LLM to parse a JSON with a fixed schema, another that uses Claude to decide if a number is greater than another, and my personal favorite — one that invokes a language model to do a grep on a log file. That’s not an agent, that’s burning money in style.

Agents are essential when there’s ambiguity, when you need reasoning, when the path is non-deterministic. That’s where the stack makes sense: a model in Bedrock that reasons, Agent Core that provides identity and governance, Strands SDK to orchestrate the loop, and MCP to connect with the outside world. That’s an agent. But if your flow is “if A then B”, that’s a good old if statement and doesn’t need an LLM behind it.

I think we’ve all seen people use agents and LLM calls to do something that a script or tool that already exists can do, or that’s simple to implement. And the problem isn’t just cost (though that too), but that you’re adding complexity, non-determinism, and latency to something that was previously simple, instant, and predictable.

Using assistants at the project level.

This was one of the last topics, partly because it was something we saw on the last day with Laura Grit and how AWS had used a new approach for Project Mantle using teams integrated with agents.

I found this quite interesting, because today most projects use assistants and agents massively, but often without any control.

So I think it’s worth opening this debate and starting to manage teams with an agentic approach, knowing how we can improve and accelerate projects with adequate quality.

Something interesting was that the entire team shares a common steering and on the other hand, you need to review the code to know it, understand it, and be able to defend it. If you can’t do these 3 things, the quality of your projects will suffer.

Mind you, this doesn’t mean doing everything by hand, but being able to defend what you’re going to implement and not playing the “my AI agent messed it up” card.

Nobody’s thinking about the Juniors.

This is something that worries me quite a bit. Right now I wouldn’t want to be someone studying with what can be a bleak outlook — many of the tasks that Junior profiles used to do are being replaced by agents and we’re losing that knowledge.

If there are no Juniors now, we’re not going to have Seniors in the future, and it seems like in many cases we’re forgetting about this.

Before, a Junior learned through trial and error, wrestling with their code, understanding why something didn’t work. Those failures were part of the path to becoming a Senior. If we don’t allow Juniors to grow, we have a very big problem.

I don’t have a solution. Maybe the Junior role evolves toward knowing how to direct agents, validate outputs, and understand what the agent is doing. But that’s not simple and I think we’re very far from being prepared, besides the fact that we’re leaving them out of this equation entirely.

Conclusion.

I’m leaving Seattle with a feeling that everything is moving very fast, maybe too fast, and perhaps not everyone is ready.

On one hand, the speed at which everything is moving is exciting. Agents are no longer a promise — they’re a reality in production generating measurable value. And being surrounded by 120 people who live this firsthand, in contexts as different as Japan, India, Norway, or Brazil, gives you a perspective you can’t get anywhere else.

On the other hand, there’s a concerning disconnect between what technology can do and what organizations are prepared to absorb. Data remains ungoverned, architectures still don’t follow best practices, and the gap between what leadership asks for and what the technical layer can execute keeps growing.

And this isn’t just our impression. The 2026 data is devastating: according to MIT, 95% of generative AI pilots produce no measurable impact on the bottom line. Forrester confirms that 88% of agent pilots never reach production. And 54% of C-suite executives admit that adopting AI “is tearing their company apart” (Writer.com, 2026). The failure pattern isn’t technical — it’s operational: fragile data, non-existent governance, and zero feedback loop after launch.

We’ve been saying this for years with cloud migration, with the data-driven enterprise model, with the early days of Machine Learning, and it seems that with agents we’re going to repeat the same mistakes (running before learning to walk).

My main takeaway: it doesn’t matter how intelligent your agent is if you feed it garbage. And it doesn’t matter how many agents you deploy if your architecture is a house of cards.

The agentic revolution isn’t just a technology problem. It’s a problem of data, architecture, culture, and people. And that, no matter how much AI advances, remains our responsibility.

Now it’s time to apply what I’ve learned. But not everything in Seattle was overthinking — you also need to disconnect and remember why it’s worth crossing the pond. Here’s Mount Rainier as proof that it wasn’t all meeting rooms.