AWS re:Invent 2025 - A leader's guide to advanced team structures in an agentic world (SNR307)

🦄 Making great presentations more accessible.
This project aims to enhances multilingual accessibility and discoverability while maintaining the integrity of original content. Detailed transcriptions and keyframes preserve the nuances and technical insights that make each session compelling.

Overview

📖 AWS re:Invent 2025 - A leader's guide to advanced team structures in an agentic world (SNR307)

In this video, AWS executives Jonathan Allen and Steven Brozovich discuss organizational transformation for agentic AI systems, drawing from work with over 1,000 customers. They address the mental shift from determinism to non-determinism, emphasizing that 95% of organizations see zero ROI from GenAI investments. Key insights include moving from "builders to orchestrators," the critical importance of data engineers (55% hiring difficulty reported), and the emergence of context engineering roles. They present Amazon's adaptive organizational model across five business maturity phases and asymmetric resource allocation across four work categories. Tools like Amazon Q Developer and Bedrock Agent Core enable spec-driven development with essential observability. Danske Bank CTO Richard Davis shares their journey achieving 50% reduction in change lead time and 75% faster triage through agents, while addressing change management across different employee generations.

; This article is entirely auto-generated while preserving the original presentation content as much as possible. Please note that there may be typos or inaccuracies.

Main Part

Introduction: From Cloud to Agentic AI - A CTO's Journey

Good afternoon. I think it is good afternoon by a few seconds. If you're in the walkup queue, congratulations on making it in. That was quite a line outside. Note to self for next year: we need a bigger room. My name is Jonathan Allen. I'm an executive in residence at Amazon Web Services. What on earth is an executive in residence? Well, I've been with AWS for over 8 years. Before that, I was actually a customer. I spent 8 years at Capital One Bank, and my final role was as a divisional Chief Technology Officer as Capital One moved everything into the cloud. I learned a lot of lessons running teams in the cloud during that time.

In the last 8.5 years, my colleague Stephen, who will introduce himself a little bit later on, and I have spent time working with over 1,000 different customers. Of course, in the last year in particular, the big conversation for us in our executive engagements has been about what is happening to our people. Because as a leader, which you all are since you're in this room, as senior leaders, understanding what is going to happen and how we are learning to build these agentic systems is absolutely crucial. Certainly, one of my biggest learnings as a CTO was that it is all about the people and where we're going on this journey.

It's no surprise for those of us who know the cloud that if cloud is peanut butter and agile is strawberry jam, then of course they go together. And of course AI is coming along to use this powerful mechanism to make this great sandwich. But there's a great deal more to it than that. All of us in this room, I'm sure, have used large language models by this point in time. We're well aware of the rise of the vibe coder. Certainly, the biggest epiphany I've had as I work with customers that are pre-cloud and those who are already in the cloud is this: the realization for those in the cloud is that large language models can instantly generate my CloudFormation or my Terraform script or however I want to instantiate my cloud setup. But I need to do this in a very disciplined way. So let's go all in on agentic systems and look at building our teams.

The Mental Model Challenge: Embracing Non-Determinism in Agentic Systems

Immediately, this comes with a challenge—a huge challenge for us as leaders. This is a mental model challenge. Certainly, all of us, and especially those like myself who come from regulated businesses such as banks or financial services industries, have optimized largely since the industrial revolution for determinism. We want a predictable output. While agile and cloud have enabled a completely different way of working, largely when I was running agile teams building on cloud, we were aiming to meet a business outcome or a goal. This changes. Now we have to deal with the fact that non-determinism in these agentic systems is a feature, not a bug.

The truth is, when I speak to executives like yourselves and other leaders, this is distinctly uncomfortable for us. This is not that different from managing any of our people who have really high agency—those folks where you agree a goal with them maybe at the start of the year, and you know they're going to find the right path to get through it. Certainly, we're used to moving ideally away from gates to guardrails. So we've put our teams together and we've got this hopefully straight road. It's never a straight road, as we know. But there are certain quality markers that we're looking to get through—toll booths is the analogy—through to these teams.

Now, where we've got agentic systems that have memory requirements—short-term, long-term—and context requirements, this is more akin to what I was looking for as the right mental model. It's like a river that busts its banks continually and reforms. How it's going to do that is a very different shape. But if we're really honest with ourselves as leaders, there's a quote here that I think is very poignant from one of the world's leading advertising executives who is really good at understanding how human psychology works. He says most business is probabilistic, but everybody in business wants to prove and pretend it's deterministic. So every spreadsheet is in some way an act of pretense because it is past information which you pretend has wonderful predictive value.

We have been doing that, and we do know what high agency looks like. But as I know, as a CTO who was booked from 8:00 a.m. to 8:00 p.m. running from crisis to fire because that's just the nature of the job, I am juggling a whole lot of balls in the air—from legal to scale, to ethics to control, to security and HR. Now I've got to deal with the emergence of agentic systems and my executive team, who is very determined that we're going to get value

Understanding AI Adoption: Research Data on Enterprise Investment and Usage Patterns

as appropriate for our business outcome, we look at the people. Those of you familiar with Professor Scott Galloway may have seen this quote: "AI won't take your job. Somebody using AI will." And then you read this analogy, and I sure wouldn't want to be the horse.

So how do we take control, both of ourselves as leaders and to help our folks who have delivered these business outcomes to be aware of this journey into the agentic world? One of the things that Stephen and I have been focusing on as we put this presentation together is to focus on what is really going on in the world and to use the research, not just hyperbole.

Those of you may have seen this report from MIT and NADA. This report contains a surprising result: despite thirty to forty billion dollars in enterprise investment into generative AI, the report uncovers that ninety-five percent of organizations are getting zero return. Now you can argue on sample size and methods used to correlate that data. We don't want to be in that ninety-five percent. We want to be in that five percent. So let's look even deeper at the data.

Let's look at this report. By the way, all of the reports used or referenced in this presentation are from 2025. There really is no point in this world using data that's older than that because its relevance, as we know, just changes continually. This one's a really interesting one: "Economic tasks performed with AI: Evidence from millions of Claude conversations." I don't expect you to read that, of course. I've summarized it here into visually stimulating content for you. From Anthropic, thirty-seven point two percent is used for computer and mathematical tasks. No great surprise for those of us that have used it. Ten point three percent for arts and media, seven point nine percent for office and administration, nine point three percent for education and library, six point five percent for life, physical, and social science, and five point nine percent for business and financial.

Now, I do not expect to talk about the next level of detail, but I know and I've been asked, having already done this a couple of times, that people want the next level of detail. So this is up there purely for you if you want to take a picture of it. So how does that translate into what's actually happening in the US jobs market, because that's where we have data? We can see here the representation relative to the US economy. Farming, fishing, and forestry are not really being disrupted. No great surprise there in the agentic world. Legal and services was lower than I actually thought when I looked at this, and so on and so forth through to computer and mathematical for our industry.

If you're coming here as a developer or a leader of developers, or a CIO or a CTO or even a CEO, we have many attend re:Invent, then yes, the disruption and usage is profound. Certainly for me, who used to be a hands-on coder for fifteen years, to be able to use Claude again to get back into coding without having to memorize all the individual syntax has been groundbreaking for me to actually produce business outcomes again. So when we look at this, yes, the disruption is real.

Breaking Down Silos: Why Change vs. Run Models Don't Work in an Agentic World

And the next epiphany as I work with customers is this: change versus run models don't make sense in a cloud world. The truth of the matter is many people still have a change versus run model. What do I mean by this metaphor? I normally have a part of my business that is for change, typically in a projects context, and people are there to do that. Then I have a run, and when something finishes in change, it moves over the fence to run. Largely, cloud has broken that model down completely. Agentic destroys the old model. Why does it change it? Because now we need observable systems. We need to be on top of what is going on. We need to be looking at the floor limits that are occurring. We need to understand the trust. We need the context area and engineering of these agentic systems.

So the big mental model to think about is if you're still in a change versus run, it is not going to work for you in an agentic world. Customers are now organizing around business outcomes, specifically. If you are really organized like this still, and I put this purely on the screen for how I see people organizing themselves who aren't on cloud yet and have put into silos, I've operated in this model. What you actually see in this model, by the way, is a lot of escalation and matrix management of resources. While it makes so much sense for us on one level to put skills into teams like this, I mean, I've used to be a network engineer, I've done software engineering, I've worked in the client-server team, and I was in a siloed team before cloud, and after cloud that changes completely. So you've really got to challenge yourself that this model will not get you to that agentic world,

because we're moving from that world in just 24 to 36 months from autocomplete all the way to agents. We're seeing that massive acceleration. Every 7 months, we're seeing the doubling of the size of the execution path of an agentic system at the present time. So that brings us down to around 5 questions that we're going to lean into in this presentation, and we're going to lean into the first one: What tooling do I need for the teams?

Essential Tooling: Quiro and Amazon Bedrock Agent Core for Production Systems

Now, this is not a tooling presentation, but the two tools we're seeing out there are absolutely addressing this problem. I don't know if you saw the little animation of the red eye on the Raven. It took a little time to do that. The proof of concept lasted 4 weeks, but you know what, it worked on my laptop. Right, we need to get away from that. If it works on your laptop, awesome, but production systems don't run on laptops. Production systems do take a team, and if you're on holiday and it doesn't work, somebody needs to be around to support it.

I think Quiro, which you'll hear a lot about at re:Invent, and I'm not deep diving into Quiro, but the epiphany for customers I've worked with that use this is that the drive to spec-driven development immediately gives discipline to the execution of how we're using these new systems to actually generate purposeful outcomes on the back end aligned to business outcomes that need reliability, that need to understand disaster recovery, that need to understand the element of determinism that we still strive for. We do want our system to be online, we do want it to meet requirements that we've thought about. So Quiro has absolutely changed the game. And of course, I'm sure you've already heard about Amazon Bedrock Agent Core. Everything you need for getting agents to production. The big thing for my customers is that final model on the right-hand side: observability. What is going on? Because of course we're striving for that determinism still. It's human nature that we want predictability, but we're dealing with a high agency system when we're building it. So that observability thing is really coming through very clearly.

So I've got Quiro. How do I structure my teams? Well, before we lean into that, again, another mental model: we're moving from builders to orchestrators. This is tough. I'm privileged to have worked in IT for 30 years. I started coding when I was 9 years old on a Commodore 64 in BASIC, for those of you that did that journey. I was very used to being a builder, to building software. We're now moving to a world with this tooling where we are orchestrators, and that's a tough mental shift for our techies. That's really tough because that fear of replacement drives through. But that Scott Galloway quote of "I actually want to be in control of this" is something as leaders that we've got to really double down with our folks to say it's far better to lean into this, not be a victim to change, but be in control of that change by being informed.

Restructuring Teams: From Builders to Orchestrators in Production Environments

And then people ask me, well, in the cloud and agile world, typically I've had this mental model where I've had different folks, whether they're FinOps experts or software development engineers or security or data or cloud developer DevOps or folks that are focused in UX and UI, which we've certainly seen since the rise of web apps and mobile apps. And then typically I've got product management and business analysts coming in at the side. Well, typically, no great surprise, when I had teams like this, I would structure them as the business outcome needed. There was no massive strict formula to how many SDEs were in a team, or data engineers, or cloud engineers. It was as the business problem required. Although I did take the liberty to put security engineers outside of the team because there's never enough security engineers to put one in every team, and typically they are a matrixed resource where you end up with a security engineer assigned to multiple teams to do app sec review.

And typically, yes, most teams now do have a person in a business outcome team running cloud and agile to focus on that. This isn't really massively changing for agentic systems. So when you look at this as a leader going, I've got all these teams, how do they work on agentic systems? Hey, I've got Quiro, I can do spec-driven development. Well, then you start going, hey, I can just have a small team now. I can just have maybe a product manager who might become a product strategist, a business analyst, maybe one or two software development engineers, and agentic software engineer seems to become a very emerging title for these folks. And then suddenly you hear things like, hold on, business analysis is now an agent, so actually a design lead in this small team, hey, now I can get to market. And I'm here to say, hold on, not quite so fast.

Those of us accustomed to running production systems at scale know that it takes more than basic infrastructure to run a team and more than that for a team to be on call looking after agentic systems. The really important thing when we look at production systems is that we actually need to think about 24/7 on-call support for these agentic systems. Right now, I don't see anybody putting in charge banking systems with asset-based transactions with agentic AI, but they're building agentic systems around fraud detection, customer service, and mobile applications. There's a lot of value there, but you still need to support this infrastructure.

The traditional on-call structure is changing. Previously, it was a human gets paid, human investigators, human fixes. Now we're seeing AI agents get alerted, AI investigates, and proposes maybe a root cause analysis with heavy language models, and then a human gets involved. I have not yet witnessed a customer fully passing over to allow that autonomously, but that is surely being challenged right now. We are seeing phenomenal usage of AI on log analysis, rapidly drawing logs in and helping engineers hypothesize on what is going on. This is having a dramatic positive impact on mean time to problem finding.

The Critical Role of Data: Engineers, Scientists, and Context in Agentic Systems

This is also shown from our own usage inside Amazon, this sort of dramatic analysis improvement in detecting signal from noise and then allowing humans to make that decision. Of course, when you transpose that to maybe your P0 and P1 matrix, I see most customers still doing this. We send leaders to the data. This is the area where I see real focus. Data not only remains an organizational challenge for most customers, but its importance increases exponentially in an agentic world. This isn't just about having databases in your operational data store or your warehouse or your data lake. It could be PDFs and typically is PDFs in my experience, and it's still in people's heads.

The truth is, and don't feel bad about this in any way, a lot of customers still struggle even to create a unified data catalog in their business. Quick bit of advice: if you're on that journey, business owner and technical owner for every bit of data you have is required. Put your data catalog back to the nomenclature you use every day, the parlance in your business. That's super important. But data engineers are where the real need is right now. Data engineers are becoming more important, and this is almost a critical missing layer I'm seeing.

When you look at the research, the North American IT leaders report from IDC shows leaders reporting 55% difficulty finding data engineer roles. This is always true in human history. When any general purpose technology gets to a position where we think it's going to displace jobs, it creates more jobs. There's always a painful learning curve. But data engineers are required to build the pipelines and manage those vector databases. Yes, of course, we're looking for self-managing vector database stores. S3 is a miracle service in my mind. But someone still has to make sure that the context of that data is understood.

I was talking to a customer recently and they had 18,000 tables in their warehouse. Goodness knows the actual line detail, the column, the table detail of all of those. But somebody needs to know what that value is and what it relates to. Typically, humans have done a really poor job of labeling those because the context of that data changes massively. So we still need humans to work alongside these agents to help understand that data. There's another paper which is really interesting to me, and small language models are the future of agentic AI. This one is from Nvidia, and I do see this playing out.

Large language models are incredibly sophisticated, and we've all used them. But when you're building an agentic system, there's tremendous use in having a small model. One of the customers I've worked with actually built a 20,000 parameter model. Now we're used to talking about trillions of parameters with these large language models, but a 20,000 parameter model to do something reasonably predictable for them that they trained in SageMaker AI was so efficient they could run it on a CPU, not a GPU. It did what they wanted it to do. This is the rise that we're seeing in customers. You're going to use a combination of agents created appropriately for you to solve a business outcome.

Actually, the real challenge for most customers is still a lot of locked-in legacy systems and complex ETL transformations. When I'm speaking to most of the really big FSI institutions, they have ETLs, or extract, transform, load jobs in the hundreds of thousands.

Typically, whatever product they're using to release their ETLs means that team is normally a bottleneck in their organization. When you look at the urgency of what's going on, this focus on data is still very legitimate. A lot of the data is still stored in incompatible formats and subject to data governance. We don't like sharing data very easily. Heaven forbid somebody gets access to my data and finds something useful that I didn't know about. So we've got to deal with that in organizations—how do we get over that? How do we set it up?

Yes, a lot of the principles in Data Mesh are valuable. I'm a huge fan of the approach from the author who originally came out of ThoughtWorks and proposed it, because a lot of it doesn't care about the technology. It cares about the human nature of sharing that data while still understanding the governance of it. Of course, we don't want to create duplicate copies of that data. It needs quality monitoring, and this is where the challenge still lies. So a lot of times when people are putting together these production agentic systems, data scientists need to understand how to create that small, if necessary, 20,000 parameter model to solve a task. It might just be a calculator that you want to do a particular calculation over and over without invoking a really large LLM each time, because that's a lot cheaper to invoke millions of times than a large LLM.

Data engineers have always been about getting that data from A to B, breaking down those human silos, and understanding how we release it. That's absolutely required. Data analysts—a lot of people say data analysts have gone away, but not really. Because context matters. And the rise of context engineering is super important in agentic systems. While LLMs can help us with this, we need the humans to truly understand who owns that data and what's going on with it. These 18,000 systems and 18,000 tables—a lot of customers are still struggling with ETL. So when you think about building your systems to solve that business outcome, data remains crucial. That's why for a number of years at Amazon, we've been focusing and investing heavily on this zero-ETL approach that's helping you get away from the ETL longest pole in the tent. A customer used that phrase for me the other day, which I thought was very poignant—longest pole in the tent—because it's always the slowest thing. It doesn't matter how much resource they seem to put at it. So moving away and simplifying that cost and resources to get near real-time insight is super important.

Emerging Roles and Team Structures: Expert Generalists and Context Engineering

Let's look at the next slide, and this comes with a health warning. It entirely depends on the business outcome. But what I do see, and Stephen and I have looked at this quite closely, is that we do see teams that are building agentic systems and supporting multiple agentic systems putting together teams that have a product manager, a business analyst, software developers, data engineers, and data scientists as required. Typically at Amazon, we will normally have a principal software engineer. We call these P engineers. We don't have architects inside of Amazon. We have solution architects who handle your interactions as an Amazon Web Services customer. But inside of Amazon, we actually have P-level engineers, which is a very senior role, and each team has a P-level engineer whose job is to ensure that the technical goals of that team are being met.

They also have a lot of responsibilities over making sure that new software development engineers coming into the team can ship code on the right problem. When we have a problem that requires multiple teams to interact, we actually get a bunch of pieces together and they solve that problem. Now, not everyone has that model. So it's probably far more familiar to people to have something like this, where at the end you've got an architect doing that. These job titles, by the way, are incredibly fungible at the moment. And of course, multiple agents are helping this team do their job. They're going to build and are already building agents to help.

Typically, I've talked about the delivery team. When you are touching an established process and bringing some agentic side to it, you'll absolutely have a sister or brother team coming alongside that, saying, well, what's my business process expertise? And if you're touching a really complex flow, that's going to occur. You're going to have business process experts, you're going to have an architect, and you're typically seeing every customer put a legal representative in there. A financial analyst, a data owner, and a software development lead who's interfacing and leading that technical side that I talked about in the previous slide. So it's almost like a two-in-the-box model for building these agentic systems, which is what's coming to the fore.

This model in particular is talking about an established product. My colleague Steven is going to talk to you about Amazon and how we think about different stages of product development and how we put different teams together. These teams are going to use different agents or create their own agents, absolutely. We're seeing that occur immediately because they're using agents and realizing they can build these small agents in SageMaker AI to solve things for them and to reduce their cognitive burden so that they can focus on what really matters. The world is changing really quickly.

I looked at a Venn diagram a while ago showing the congruence between software engineer, data engineer, data scientist, and data analyst. That middle section of the Venn diagram, the blue area where it talks about SQL, Python, cloud services, and NoSQL, I think a lot of us are seeing that become the top of the T-shape when you look at how you skill yourself. That bar of cross-functional knowledge is actually coming to the fore in context engineering. I need to understand the context of the agentic system. If you were at the presentation before where Ishit Bakranjani talked about a leader's guide to agentic AI, he talked about this in more detail. If you missed that presentation, it will be online, hopefully in the next 48 hours on YouTube. He talks a lot more about context engineering, and we absolutely see that role emerging right now.

These systems have got to understand that linkage for data. Data is becoming that critical, critical pole. A role is emerging, and it's interesting. I was looking at how thought works. Think about this. This is Martin Fowler, one of my heroes. He came up with the strangler pattern for deconstructing monoliths, and he talks about it like this. As computer systems get more sophisticated, we've seen a growing trend to value deep specialties, but we've found that our most effective colleagues have a skill in spanning many specialties. We're just starting to explicitly recognize this as a first-class skill of expert generalist. That is emerging, particularly for context engineering. You need to understand what is going on in the system.

If you want to look more at Martin's work, which I fundamentally always read when Martin has a blog, he talks about these expert generalists emerging. I think this for context engineering and agentic systems is another emerging role. Prompt engineering, I don't think any of us ever thought that was going to be a role. Context engineering absolutely is. With that, I will hand over to my colleague, Stephen.

Amazon's Organizational Evolution: Adaptive Models Across Business Lifecycle Phases

I'm Steven Brozovich. I joined Amazon in August of 1999, so that was a little while ago. The world has changed a ton since then. We've spent a little bit of time now thinking about how agentic AI is going to be impacting both the work and the roles in our teams. You might be sitting here as a leader going, but what does that mean for me? How is my role impacted by this work? I want to frame the question a little more clearly. As leaders, we all know we're trying to generate value, and we have a limited amount of time, attention, budget, and talent that we can allocate towards the work.

In his book The Day After Tomorrow, Peter Hinson talks about different categories of work. There's the work of today, which actually leads to current value. Then there's the work of tomorrow, which is going to lead to value in the future, and then there's the day after tomorrow. What's that thing that we're doing that contributes long-term value to the organization? As leaders, we know we're all supposed to be thinking about these and prioritizing appropriately. We've got to focus some on today, but we've got to make sure we take care of the day after tomorrow. Now reality is that today tends to insert itself uncomfortably. It's that pile of emails we wake up to that we weren't necessarily expecting or that next meeting. Today tends to dominate.

We know we're supposed to carve out time for tomorrow, so we take additional time to figure out how we write that three-year plan or work on next year's budget. We still intend to think about the day after tomorrow, but we know we spend far too little time actually doing those activities. That's when we're looking at that new technology or a shift in our business that could actually set us up for an entirely different direction in the long term. And that's not even taking into account the stuff of yesterday. That's a kind way to put it. But this is that shortcut we took three years ago, and the tech debt is rearing its ugly head today and is demanding to be paid. Reality is that all the time we intend to spend on tomorrow and the day after tomorrow often gets consumed by the stuff of today.

Are we getting depressed yet? Let me make it even more clear. We still have to remember all this stuff too, on top of the work that we're doing. At this point, we might be feeling a little bit like we're the only ones not enjoying the party, right? All the glossy ads make you think that every business in the world has this figured out but you.

The reality is that most businesses are figuring this out themselves. But the clock is ticking. Now the good news is that there are some patterns that we are seeing your peers use that are helping navigate these changes. If you were in Ishit Varjani's session a little bit ago, this will look a little bit familiar. Here are four mental model shifts that we see as key for organizations that are successfully managing these changes.

Now, as Jonathan mentioned, most of our organizations are set up to deal with a deterministic world, and in that sense, it makes sense for us to have this culture of operational execution. How do I do the job extremely well, right? Avoid deviation from known good processes, being focused on measurement and individual optimization. But leaders that are successfully navigating agentic AI actually see themselves and their organizations more like research labs. This attitude of continuous learning means that as continuous learners, our focus needs to be on shared experimentation, embracing adaptation, and providing psychological safety so that we can learn from failures.

This mental model shift in particular requires us to look at other areas of leadership when we need to adapt. The first of those, Jonathan already made a nod to, which is that in a deterministic world, it makes sense for us to govern through gates. Right? We can define the process, we can control each action, check for compliance through checklists, and audit for deviation. But agentic AI is making us confront reality. Since we live in a probabilistic world, we should probably be spending less time defining and refining the process and more time providing strategic direction. Defining guardrails and creating feedback loops that allow for rapid experimentation and continuous calibration.

When we live in a deterministic world, it makes sense to manage the business like a factory floor because we can set finite limits and measure and calculate against those limits. But successful organizations in this space are operating more like trading floors. How do I provide enough autonomy to the teams? But I need to have real-time risk visibility. And I even need to have adaptive circuit breakers that can respond quickly to emerging risk patterns.

And then finally, it makes sense to organize in functional silos when we live in a deterministic world, when we have a known set of problems and a known set of solutions that we can deploy against those problems, because those functional silos allow us to be incredibly efficient at doing the same thing again and again and again. But when there's rapid change, that rigid organizational structure, those sequential handoffs, and the isolation of data systems that Jonathan talked about sometimes make change feel like it's impossible. Organizations that are successfully navigating these changes actually respond much more like an immune system. They swarm and reshape based off of changing customer needs and challenges driven by business objectives and customer outcomes, not hierarchies.

Now if you'd like to dive into this topic a little more, there will be a recording of Ishit's presentation, but we also have a link to a blog that Ishit authored that dives into these mental model shifts more significantly. It's one of just many topics that the executive and resident team produces every year of the challenges and patterns that we are seeing as we talk with our own customers. But what I want to do now is shift. As we talk to our team, we talked to over fifteen hundred different organizations annually. We're talking at that sea level change, and we see the patterns and the questions that we get. And we often hear from our customers like, okay, that's an interesting story, but what's Amazon actually doing?

And in this case, this is a very rapidly emerging question: how is Amazon thinking about organizational structure in an agentic world? Like many of you, this technology is challenging some of our basic assumptions about how we should organize and get work done. And with over one point five million employees, that question is not optional. We have a team of organizational scientists that are helping us understand which patterns are helping us, which are hindering us, and why. Now the answers are shifting. We're still learning, but I'm excited to share with you some of the insights that we've gained from this work inside our own organization.

The first insight shouldn't be too surprising. Organizations that align their operating model with their business lifecycle phase outperform those that do not.

Now, some of you are probably starting to break out into hives. Please, not another conversation about centralization and decentralization. We all know there are some benefits to centralization, and others you gain from decentralizing and granting team autonomy. But what we've found is that this model is too simplistic, and it often leads us swinging from one end of the pendulum to the other. What we actually need is an organizational design model that is adaptive to ever-changing environments. In addition to that, our businesses are too complex to be served by any one-size-fits-all model.

So the emerging thinking is that our organizations need to be optimized around three distinct tensions. The first is speed. As Andy Jassy has said, speed is a choice. How much should you be optimizing for consistency, and when should your primary objective be agility and iterative change? The second tension is resourcing. When should you be thinking about optimizing for scale and efficiency through shared centralized resources and tools, and when should your focus be on providing dedicated resources for business-specific outcomes? And the third tension is connections. When should you be building deliberately interconnected systems for coordinating complex workflows? And when should you be striving to create more autonomous activity?

Let's dive into each one of these in more detail. First, your customers require different speed versus reliability depending on their context. Organizations that focus on consistency gain speed through systematic execution and standard processes that deliver reliable, repeatable outcomes. In contrast, agile organizations position critical activities close to customers, enabling rapid feedback and iteration. When it comes to resourcing, your customers actually vary in their need for specialized attention or standardized solutions. Teams want to drive efficiency by centralizing delivery and building common infrastructure that scales solutions across multiple needs. Whereas in other situations, we need those dedicated teams to focus on core capabilities with deep customer context, delivering specialized solutions for specific needs.

And finally, on connections, because your customers are actually the ones who should be dictating that balance between autonomous innovation and integrated delivery. Interdependent operations, optimized for end-to-end outcomes through coordinated planning and shared standards, whereas independent teams maximize autonomy by ring-fencing work into logical units, enabling direct customer signals and modular decision-making. Now, where you sit on the optimal balance for each of these actually varies based on business context, customer needs, and organizational maturity. These tensions aren't mutually exclusive. Successful organizations are thoughtfully positioning different parts of their business along each spectrum based on their requirements. The key is not to choose one end of the spectrum, but to position different parts of your organization according to your specific needs and regularly reassess.

We see this pattern at play across most of Amazon's businesses depending on the maturity of that individual business. Younger businesses often skew towards depth. They're favoring agility, custom functionality, but as the businesses mature, they tend to skew towards breadth because consistency, economies of scale, and cohesive user experience become ever more important. So let's follow that evolution. As we're starting out, we're going to skew heavily towards depth over breadth because early adopters are the ones using this new product, and they are seeking innovation and will accept some amount of imperfections. So we're maximizing speed and flexibility through small dedicated teams with direct customer access. The breadth-depth mix starts to shift as the business grows. Early majority customers now join those early adopters, but they bring higher quality expectations while tolerating some iteration. And so now we start to see the emergence of hybrid structures of dedicated and shared teams because we need those shared teams to support scaling, and we still need those dedicated teams for rapid iteration and adjustments.

As the business matures now, mainstream customers start to join, and they become dominant. And so they're requiring consistent, reliable experiences.

They also require high quality customer support, and structured feature request processes. We shift our operating model to balance established processes with innovation through horizontal platform teams for core infrastructure and federated product teams for customer facing features. When the business fully matures, late majority customers dominate, requiring proven solutions with comprehensive support, predictable experiences, and consistent quality across all interactions. At this point, our emphasis is optimization and efficiency through shared services, automated solutions and support systems, and self-service platforms.

Now, this is actually where most organizations stop. They stay at phase 4, refining and squeezing efficiency out of every single process. But this is also where they are the most vulnerable. Because that execution excellence actually becomes the very thing that prevents them from adapting when business climates change or when a new startup shows up to disrupt their business model.

At Amazon, we understand and embrace the phrase we say at Amazon: it's always day one. The need for that startup-like flexibility is important in phase one initiatives like NFL on Prime. But it's equally, if not more important, for well established businesses like home delivery. We have to constantly challenge our own recipes for success, because customers' needs are not static. We need to shift our mix yet again to inject fresh innovation.

In phase 5, we now have a mix of both loyal customers and customers seeking new experiences. We need different value propositions for each of those customers and the balance between familiar and innovative experiences. We want to enable transformation while maintaining stability through sophisticated dual operating models and hybrid team structures. Organizations that are following an adaptive model are far better positioned to react when technologies like agentic AI emerge. In fact, I'd argue it's that organizational flexibility that has enabled Amazon to weather all the changes in customer needs and demands all the way from our very beginning. Rigid, one-size-fits-all approaches just don't work.

Asymmetric Resource Allocation: Balancing Human and AI Capabilities by Work Type

The second key insight we've gained is that organizations that asymmetrically allocate human and AI resources based on the type of work outperform those that do not. Like organizational models, there is no one-size-fits-all approach to agentic AI. Let's look at resource allocation across four types of work.

The first type of work we call strategic differentiated work. This is the work that customers view as uniquely you. It creates competitive advantage, it defines customer experience, and directly enables key goals. The next type of work we look at is strategic enabling work. These are the capabilities that power your differentiation. They support competitive work and reinforce organizational culture to achieve business outcomes.

The third category we call business essential. This is the kind of work that's required for basic operations and near-term success, but it usually isn't tied directly to market value. In fact, most of this work is the keep-the-lights-on work that you just have to do to maintain market parity. And finally, we call another category of work business compliant work. This is the work that's required for legal or regulatory compliance. There's usually little to no market return, but it's essential for keeping ourselves afloat.

So if we think about these four work categories, let's look at how Amazon is currently allocating human and AI resources against these different categories of work. Who's involved in this? Well, first it's you, as strategic leaders. It's our responsibility to provide that vision, that insight, the conviction, and the judgment to define the business outcomes and guide the work.

The next group involved in this is AI and agentic work. It's a combination of AI agents and traditional AI used to solve complex challenges and sift through mountains of probabilities to drive results. The tactical execution team is the humans. All those roles that Jonathan talked about earlier in the day. Those humans are the ones that are creating the agents and the processes needed to achieve the business outcomes.

And then let's not forget, there are significant portions of our businesses still today that can be made far more efficient through simple automation, or by leveraging utility solutions like managed services from AWS and other partners, without reaching for more expensive options like generative AI. So let's look at how we allocate these into those different work categories.

Strategic differentiated work is really the only place where executive leadership is critical. We have to set strategic direction, define our own customer facing competitive advantage.

Making high judgment decisions on product design and innovation is critical to this work. AI agentic systems carry about 25% of the workload. We're leveraging machine learning for things like advanced targeting algorithms, and we're using AI agents for predictive analytics and customer behavior modeling to ensure competitive outcomes. The rest of the work is carried out by the tactical execution team. They're the ones dealing with ambiguity, solving complex challenges, and executing strategic initiatives. Notice that automation and outsourcing are next to non-existent because there are no known solutions yet to automate, and we would never want to outsource our differentiator.

As we move into strategic enabling work, the leadership team can take a back seat. Our role changes to one of auditing and advising. Now we can start to look at the things of tomorrow and the day after tomorrow because we've set those guardrails that empower our teams to build. AI systems take on a greater percentage of the work. They're tackling things like insight generation, anomaly detection, and process optimization. On the human side, technical program managers and solution architects take the lead for technical implementation and cross-function coordination. Now we start to see the beginnings of automation and the use of utility solutions for things like routine coordination of activities and basic workflow management.

When we look at business essential work, agentic systems are used for routine analysis, standard reporting, and basic process optimization. The humans look more like operations teams, account managers, and business intelligence analysts providing operational oversight, exception handling, and process improvement. Agents and people are co-creating these rule-based workflows as problems become better understood and turning those into automation. And then finally, as we look at business compliance, we skew away from agentic toward even more automation as we're looking for deterministic execution against well-understood problems. Here, the human contribution is that context that Jonathan was talking about. It's that dedicated expert knowledge needed for those human-in-the-loop decisions and those situations where rapidly evolving regulatory and compliance frameworks can be digested and understood in the context of the business.

Taken as a whole, this asymmetric approach allows us to deploy the right kinds of resources to the right problems. Like most approaches, it's not perfect, but it's proving to be highly adaptable as a way to leverage this new technology. So our question for you is: how are you thinking about team structure in an agentic world? Hopefully these ideas will give you some new perspectives as you apply them to your own space. For another view on the impact of agents on the work, I'm excited to welcome to the stage Richard Davis, CTO of Danske Bank.

Danske Bank's Transformation: From Cloud Migration to AI-First Banking with Real Results

Thank you very much. I actually forgot I was coming up here because I was so engrossed in the presentation. I'm Richard Davis, as I said. I'm the CTO at Danske Bank, and we're based in Copenhagen. Jonathan mentioned earlier that 95% of organizations are not seeing value from GenAI yet, and we actually think we're part of the latter part of that equation that are seeing the 5% of real value from GenAI. Today I'm going to touch upon our story and some of the challenges we see from both a technology perspective and a human perspective.

Before I go into more detail, I'll give you some background on where we are at Danske Bank. We are a bank in Copenhagen and we have a rich 150-year history. We've been running infrastructure on-premises for many years, and it's given us a lot of the value we've seen through our banking systems. But of course, as we want to become more agile, we've introduced the public cloud and we've gone from on-premises to the public cloud. We've now migrated 850 applications into AWS over the last 18 months. But it's really been about mindset change rather than just a technical change. It's also given us a great opportunity when it comes to GenAI. It's really given us the infrastructure for us to adapt and deliver really quick solutions as well as things such as sandboxes.

We say to ourselves that we're going from catching up to winning at Danske Bank, and it really is cloud being our foundation when it comes to delivering GenAI and us becoming an agentic workforce. We really feel that we're going to become an AI-first bank. People often ask, are you really going to put AI into Danske Bank? But of course, we already think it's there.

As we've been delivering generative AI into our organization, we've developed what we now call 10 big wins. We used to call them big bets or big rocks, but we're now saying that we feel so passionate these things are going to give us value that we're going to deliver them, and they're called big wins. One of them I'm delivering is around our product delivery life cycle, which was based on software delivery life cycle. As we've rolled out AI coding assistance, we've seen a huge reduction in our change lead time by about 50 percent. This is great and provides a huge amount of benefit to our developers.

When we started speaking to our developers and doing a level of analysis using our live engineering tooling where we could see all the different touch points in our delivery life cycle, we soon realized that many of our developers, and we do have quite a few, were actually working very hard, but only 35 percent of their time was spent on coding. A lot of the time they were working really hard, but in other areas of the delivery process.

What we found was there was one process for development, but many other processes across the organization, and they were working hard with those other processes. When we asked them how they're feeling, they felt that the progress they were seeing still didn't equal the level of effort that they're putting in on a daily basis.

So we're on a journey to what we call our new PDLC, which is the product development life cycle. We're looking at how we can help development teams that are stuck in processes of endless kanban boards, handover meetings, documentation, testing, and all sorts of things like that. We feel there's an amazing opportunity for us to deliver one agentic flow with zero friction and to a certain extent toil.

Some of the agents that we're starting to build, we've actually put one into production already, and we're starting to see some immediate benefits from the agents. The first one is around business analysis. We have a large number of BAs, but we also have a lot of developers working on BA work. We're now looking at how we can automate the specs and validation and reduce the manual effort of our resources. We're also looking at QA. They're testing, and we're asking how we can get an agent to start accelerating the generation of test cases and looking for defect detection. A lot of people don't like writing test scripts, but they also don't want to execute so many tests, so this is something that we think will give us a lot of value.

There's something that's close to my heart as an ex-support person. It's about the 24/7 and really how we start thinking about reliability engineering agents. This one really excites me. We already have something called Cloud Buddy, and I think we're going to rename it at some point, but it actually sits in production today and cuts triage time down by about 75 percent and also improves our root cause accuracy. We're also looking at how this can help us with incident resolution. It doesn't actually perform an action, but it helps us going through log analysis, for example. I'm pretty sure this agent at some point is going to be part of our organization. In fact, as we're looking to give it more and more tasks, we're almost thinking about how we can call it a promotion for the agent.

This is the first wave of agents that we're putting in our PDLC, but we really think that at some point we will have the complete agentic framework when it comes from having an idea all the way through to running the agent in production and potentially even retiring the product.

One of the biggest things we've seen is the change management, the people element, the human resources. I really feel that there's a lot of change management to happen, and the reason is there's a huge amount of background of different generations, cultures, and experiences across the organization. Some are super excited with the generative AI opportunities that we have, and some not so much. We all know the corporate jargon. The first one here is "I'll circle back to you." It sounds harmless, but what we really think this says is why should I be using something that can replace me?

Well, we actually tell them, look, generative AI won't necessarily replace your role, but people using generative AI potentially will. Then there's the classic "let's take it offline." This one's okay, but really what it means is it sounds okay, but where do I start? Do I really have the time to start learning new tool sets? This is where we have champions and train the trainers in our organization, continuing to lean in to the employees, teaching them and giving them demos of how others in the organization are getting benefits. And then finally we have the supporters, usually the young grads who are really hungry to use some of their generative AI tooling and the agents. Really what they're saying is it's really about time we implemented some great processes here. This is something that we're seeing across the organization.

This is really around the resources, but what does it mean for me as a CTO? I think this role is continuing to evolve as well. We talked about it earlier about being the expert generalist, and I don't think that me now is not as deep in technology as I used to be. I see myself as a connector of experts across both technology and the YA employee.

This is where the magic happens and really where platform, technology, and processes align. I did actually say that I'm a man of many hats, and I didn't actually expect my team to put this on a slide, so I'll move on very quickly.

But if there's anything I would say, there are a couple of things. One is momentum beating perfection. When we started off , we really kept on planning. We were planning and planning. By the time we actually went to implement any type of AI tooling or agentic opportunities, we really felt that it had already moved on. So we really felt that we've got to get moving very quickly.

What we started to do was some generative AI hackathons. With these generative AI hackathons, we gave the end users, the people in the front line, some of the low code, no code tools that we have, and we said, look, we guarantee you a path into production for the winner. Actually, we ended up having three—the top three solutions all getting ready for production. The winner, called Checkmate, is in production and is actively used by the team that delivered it in the hackathon every day today.

So the commitment that we had made to people about it going into production has really driven the hunger for people to get involved and understand more about generative AI. And then finally, we've teamed up with a number of great partners and strategic supporters across the organization. Our CEO is mandating the use of generative AI, and we continue to focus on the North Star with becoming an AI-first bank. And then finally, as we partner up having that North Star and that end vision gives us something for us to focus upon.

Without further ado, I'll hand it back to Jonathan. Yes, thank you very much for listening to us today. Thank you, Richard, for sharing that story. I love the hackathon idea where we're going to guarantee it goes into production. All of this is such a fluid state right now, such a fluid space—it's changing every single day. We wanted to give you some deep snippets though on what's happening, what we see happening with the roles and in particularly what's happening with Amazon.

Finally, please leave feedback for us. I'm the track owner for all the senior leaders sessions today. I will read every single comment that you leave for us today. We greatly appreciate the scores and feedback you give us, and with that, thank you very much for listening to us today.

---

; This article is entirely auto-generated using Amazon Bedrock.