Building in the Agentic Era, Part 2. By Mike

Agents can now write code faster than any team can understand it. That gap is the risk I'd watch most closely right now. I'm not talking about bad code. I'm talking about code that works, passes review, ships, and that nobody on the team can explain when it breaks.

I learned this the hard way. I built a software factory with agents, and at the start I could walk you through every component in detail. I'd picked the architecture and every piece in it. Then I set it up to improve itself. A few days of building later, I realized I didn't know what had actually been built. The way back was the same tool that got me there: I had an AI generate a full set of diagrams from the codebase. That got me back in the door. It also made the lesson hard to miss. If I could lose track of a system I designed myself in a few days, a team running agents across a whole product can lose track of a lot more.

In Issue 02 I wrote that the human hours don't go away when agents build. They move to the plan and the outcome. This week I want to look at what happens when those hours get thin. On Tuesday, Rishi wrote that the engineers who do well hold tight to the destination. That's hard to do when nobody on the team can read the map anymore.

New here? Two engineering leaders on building and leading with AI inside a large enterprise. Every Tuesday and Thursday, free, in your inbox.

Subscribe free

The numbers caught up this week

A few things landed at once. On October 3, Futurism ran a piece on engineers who can no longer follow the code their AI tools produce. A few days earlier, a survey from Undo, a debugging company, put a number on it: 35% of AI-generated code reaches production before engineers fully understand it. The same survey found 79% of engineering leaders say their release cycles haven't sped up, even though writing code has never been easier.

Undo doesn't say how many people it surveyed, so I'd hold the exact figures loosely. The direction matches everything else I'm seeing.

Augment's State of AI-Native Engineering report, a survey of 219 engineering leaders, found that 55% rank understanding their codebase as their top concern. The part that stuck with me: almost none of them are doing anything about it beyond code review.

That's the gap. Leaders can feel the problem. Most of us are answering it with the same tool we already had.

Two names for the same problem

Addy Osmani calls it comprehension debt: the growing gap between how much code a system has and how much of it people actually understand. LeadDev calls it cognitive debt, the slow loss of understanding about what a system does and why.

Technical debt lives in the code. You can see it, search for it, and schedule time against it. Comprehension debt lives in what's missing from people's heads. It doesn't show up on a dashboard. Velocity looks great right up until something breaks and the person on call opens a file nobody has ever read closely.

That's when the bill comes. You pay it in time to diagnose, in fixes that miss the root cause, and in the slow loss of confidence that comes from running a system you can't explain.

Why code review won't save you

Code review checks a change. Understanding is about the whole system. Those used to travel together, because the person writing the change had to understand the system around it to write it at all. Agents broke that link. A change can be correct, reviewed, and approved, and still nobody holds the full picture.

Volume makes it worse. In Issue 02 I wrote about the rubber stamp: nobody reads hundreds of anything carefully. Agent-written pull requests show up faster than people can study them, so review drifts toward "looks fine, tests pass."

The newest answer is to have agents review the agents. Several of the big AI vendors now ship automated pull request review. I think that's useful, and it catches defects people miss. What it doesn't do is put understanding back in anyone's head. You end up with code written by a machine, checked by a machine, and understood by no one.

How to tell you're carrying it

You won't find comprehension debt in a report. Watch for these instead:

• Incidents take longer to diagnose than they used to, even when the fix turns out to be small.

• The answer to "how does this work?" is "let me ask the agent."

• People re-prompt to change code instead of reading it first.

• One person, or nobody, can walk through a critical flow from memory.

• New people can't get up to speed from the docs, because the docs were generated and nobody checked them.

If two or more of those sound familiar, you're carrying the debt. The real question is how much.

What I'd do about it

Not everything needs deep understanding. A throwaway script or a one-time report doesn't need a person who can explain every line. So I'd start with the same grid from Issue 02. Where the cost of being wrong is high and you're slow to detect or roll back, you need people who understand the system. Everywhere else, you can choose to carry more debt, as long as it's a choice.

For the parts that matter:

• Make the explanation part of done. A change isn't finished until someone can explain what it does and why, in plain language, without the agent open. The agent can draft that explanation. A person has to be able to defend it.

• Name someone who can explain it. Every critical area needs at least one person who can walk through it from memory. Not the person who prompted it. The person who understands it. Two is better.

• Read before you re-prompt. When something needs to change, read the code first. It's slower the first few times. That's the point.

• Use the agent to teach. Have it generate architecture diagrams from the codebase, then explain the tradeoffs it made, what it considered and rejected, and where it's least sure. That turns the fastest writer on your team into a tutor. Just treat the diagrams as a starting point to check, not the final word.

• Practice without the safety net. LeadDev suggests AI-free checkpoints, where people work through a problem before checking with AI. Short walkthroughs or incident drills on agent-built code do the same job.

• Measure it. Track time to diagnose and how often the answer is "nobody knows," right next to velocity. If velocity goes up and diagnosis time goes up with it, you're borrowing.

Yes, this costs you some speed

All of this slows you down a little. That's the tradeoff, and I won't pretend it isn't there. Some of the speed agents give you has to go back into understanding what they built.

Teams that skip that step look faster for a while. Then they hit a bad outage, or the one person who understood a critical area leaves, and they find out what they actually saved.

If you try one thing this week: pick your most critical service and ask who can explain how it works without opening an agent. If the answer is nobody, you've found your debt.

A checklist you can steal

Copy it, change it, make it yours.

Before the work starts:

• Place it on the cost and rollback grid. Decide how much understanding it needs.

• Name the person who will be able to explain it once it ships.

While the agents work:

• Ask the agent to explain its choices and the parts it's least sure about.

• Read before you re-prompt.

Before you call it done:

• Write a plain-language explanation of what it does and why, and make sure a person can defend it.

• Ask whether someone on call could understand it at 2 a.m. from what's written down.

Every sprint:

• Track time to diagnose next to velocity.

• Walk the team through one agent-built area.

If you want to go deeper

• Comprehension Debt by Addy Osmani, where the term comes from.

• AI coding creates two kinds of debt from LeadDev, on cognitive debt and what it does to how engineers grow.

• State of AI-Native Engineering 2026 from Augment, where the 55% comes from.

• Coverage of the Undo survey from DIGIT, with the production and release cycle numbers.

• AI now writing code humans can't even understand from Futurism, the piece that kicked off this week's conversation.

Next Tuesday, Rishi takes on how you grow your career when writing the code is no longer the hard part. My bet is that understanding the system is a big part of his answer.

I'm curious how other teams are handling this. How do you make sure someone still understands what the agents built? Hit reply and tell me. The best answers will turn into future issues.

Want the next one? Subscribe and you can reply to any issue. We read every reply, and the best questions become future issues.

Subscribe free

The opinions expressed here are our own and do not represent any employer, past or present. Nothing in this publication describes any specific company's internal systems, data, vendors, teams, metrics, or plans. Sponsored placements and sponsored briefs are clearly labeled.

Till next time,

Ellis & Kherdekar

Ellis & Kherdekar, Issue 03 · Engineering Leadership in the Agentic Era

The teams that move fastest with AI will be the ones whose culture is built for uncertainty. Every team can buy the same tools. Culture is harder to copy, and building it is a leader's job. In my teams, that culture starts with one anchor: the business problem stays put, even when the work underneath it keeps shifting.

Here's why that matters now. Traditional engineering works like a ladder. You write a piece of code, make it work, and build the next piece on top of it. Some rungs break and you fix them. Each step holds the weight of the last one and gets you closer to where you're going. Sprints, design reviews, handoffs, and release trains all worked because the work behaved predictably.

AI takes a lot of that away. You can do the same work twice and get two different outcomes. A full day of work can turn out to be useless by evening. Your team is working with a black box, and they feel it well before anyone says it out loud.

In Issue 01 I laid out the playbook I'd use to set up an engineering org for agents. In Issue 02, Mike looked at how builders keep real control when agents do more of the work. This issue covers the mindset shift and ways of working that make the culture real, and what they cost.

There is more than one way to build this

What I describe here works for my team, my people, and the culture I'm building. I've seen it get results, but it isn't the only path, and your lines may sit somewhere else.

Any leader working through this faces the same questions:

• What do you actually do about the uncertainty?

• How much failed work can a team absorb before morale and retention take a hit?

• Where does experimentation stop and normal building start?

• What do you say when an engineer's week of work gets thrown out?

Engineers tie a lot of their identity to shipping code that works. Losing that work stings, and pretending it doesn't helps nobody. Every answer has a cost. Move too fast and you wear people out and ship things that break. Move too carefully and you spend months designing for a problem you don't understand yet. Here's where I've landed, in the order I'd build it.

Start by understanding the problem

I start without AI. The team first has to understand the business problem and the process behind it, usually by working through it by hand. Then we automate the parts that need it.

This is also where I draw the line on experimentation. If the process is broken or the data is bad, it isn't ready for AI. AI won't stop to ask what's wrong. It will take the garbage and amplify it. So we fix the fundamentals first. Good architecture, clean data, and solid engineering judgment matter more once an agent is in the loop.

The cost of being wrong is the other half of where that line sits. Mike covered that in Issue 02 with the grid he uses to decide how much oversight a piece of work needs. I highly recommend it: read Issue 02 here.

A team that understands the problem can break it down. That's where speed comes from.

New here? Two engineering leaders on building and leading with AI inside a large enterprise. Every Tuesday and Thursday, free, in your inbox.

Subscribe free

Small pieces keep the team moving

Once the team understands the problem, I want the smallest piece that works on its own and can ship. Get that first version out, even if the full solution isn't working yet. Then build the next piece on top.

Some pieces won't work. Some releases will be bad and some things will break. Because each piece is small, a miss costs hours or a few days. If it takes weeks to ship the first thing and weeks for each round after that, you're already behind. Every miss costs a month, and the team stops wanting to try anything.

Small pieces also let the architecture grow with demand. Nobody knows the perfect design on day one, and I'd rather not spend weeks building layers we may never need. How architecture should evolve this way deserves its own issue, and I'll come back to it.

Shipping small means some pieces will fail, often. Whether people keep taking that risk comes down to how the team treats failure.

Failure the team can talk about

Small pieces shrink the emotional cost. Culture handles the rest.

When an experiment dies, we run a blameless root cause analysis (RCA). It's a structured look at what went wrong and why. Blameless means the review is about the problem and the process, and nobody gets singled out. We ask four questions. What was the problem? What did we try? What was the root cause? What could we have done better? The same thing could have happened to anyone on the team. We write it up, share what we learned, and change our process where it needs changing.

I also want the people who surface problems to get credit for it. Someone who writes up what went wrong and how to fix it is showing the behavior I want more of. Once failures get used against people, they start hiding them. Hidden problems are slow problems, and you lose the safety this whole approach depends on.

Owning failure as a team only works if the team can see what it's working toward. That's where the problem comes back in.

Keep engineers close to the problem

This is the part I care about most.

If code is only a means to an end, you need another way to see progress. I use input and output metrics. Output metrics are the needle you're trying to move. They're usually the business problem itself, and you don't fully control them. Input metrics are the levers you do control, like testing, deployment practices, and the checks that keep new pieces from breaking old ones. The team works the levers and watches the needle.

When an attempt fails but the output metric still improves that week, losing the code hurts a lot less. Engineers can only see that if they're close to the customer and the problem.

Territory gets in the way. It shows up between roles, when an engineer says something is the product manager's job. It shows up between teams, when the conversation turns into "our area" and "your area." Either way it pulls people away from the problem. In most large organizations you rarely own a problem end to end. You depend on other teams, and solving the problem means building coalitions with them. That deserves a full issue, and it's coming.

Let go of how we've always done it

The biggest shift for engineers goes past code. It's letting go of "this is how we've always done it."

Across the industry, I see a lot of energy spent defending process: the sprint shape, the review steps, the handoffs, the way a design doc has to look before anyone builds. Some of that still earns its place. A lot of it was built for the ladder. When an engineer spends a week defending how the work should flow, their eye is off the ball. The ball is the outcome for the customer, so spend as much time with them as you can.

So I'm asking engineers for three things. Own the problem, even when you don't own every piece of the code. Get comfortable experimenting, because a failed attempt still teaches the team something. And work closer to the customer than you're used to.

Under all of that is understanding the problem. If an engineer doesn't understand the business problem, or isn't clear on input and output metrics, the rest won't land. That's the biggest gap I see, and it's where I spend a lot of my time.

The destination stays put

I explain all of this to my team with Google Maps. The destination is the business problem, and it doesn't move.

Nobody has ever asked for their problem to take longer to solve or to come back with more mistakes. What took a week becomes a day, then an hour, and better agents will keep pushing that. The tools and timelines will keep changing. What people want holds steady: the right outcome, faster, with fewer mistakes. That's the destination, and it's the one thing I don't let the team lose sight of.

The route is the code, the approach, and yes, the process. Drive from California to New York on roads you've never seen and you'll hit traffic, construction, and a wrong turn or two. You reroute and keep going.

That's the culture that replaces the ladder. Understanding the problem tells the team where it's going. Small pieces make rerouting cheap. Blameless reviews make wrong turns safe to admit. Metrics show whether you're getting closer.

The engineers who struggle with agentic work hold tight to the route. The ones who do well hold tight to the destination.

If you try one thing this week: ask your team to name the output metric for the work in front of them. If they can't, start there.

Next Tuesday: if the work keeps changing this fast, how do you grow your career in it? What gets you promoted when writing the code is no longer the hard part? I'll share how I think about that, and what I look for in the engineers I'm betting on.

Don't miss next Tuesday's issue on growing your career when writing code is no longer the hard part. Subscribe free to get it in your inbox. You can also reply to any issue, and the best questions become future issues.

Get next Tuesday's issue

The opinions expressed here are our own and do not represent any employer, past or present. Nothing in this publication describes any specific company's internal systems, data, vendors, teams, metrics, or plans. Sponsored placements and sponsored briefs are clearly labeled.

Till next time,

Ellis & Kherdekar

Building in the Agentic Era, Part 1. By Mike

Agents have made building software a lot faster. I don't think anyone who's used them seriously still argues that. What they haven't done is take the human out of it. The time you used to spend writing code doesn't vanish. It moves, and you get to decide where it goes.

I caught myself on the wrong end of this not long ago. I was working through a spec-driven build where the agents asked me questions at every stage. Through the requirements, the design, and the first specs, I was sharp. I read every question and thought through every answer. But somewhere in the later specs, I noticed I just wanted the work to get going. I'd answered hundreds of questions by then. The agents had plenty of context, and I was playing the approval game. That's when it clicked for me that more approvals don't automatically mean more control.

On Tuesday, Rishi wrote about governance at the org level: keep it continuous, and give agents more room as they earn it. I want to come at the same problem from the builder's chair. Once agents are doing most of the building, where do the human hours actually go?

New here? Two engineering leaders on building and leading with AI inside a large enterprise. Every Tuesday and Thursday, free, in your inbox.

Subscribe free

Review is the new slow part

I'm not the only one seeing this. Qodo surveyed 500 developers and 300 engineering leaders last week, and both groups put reviewing and validating AI-generated code at the top of their bottleneck list. Only 3.7% of the leaders thought their current process could hold quality as agents take on more work. I'd bet most of the other 96% already know that. They just haven't had time to fix it.

Anthropic's AI-native SDLC playbook lands in about the same place. The build runs at machine speed now, but planning, review, and release still run at human speed. Writing the code used to be the long pole. Now it's deciding what to build and checking that it got built right.

Where the approvals actually happen

Day to day, I see approvals land in two places.

The first is the plan. Sometimes that's a quick plan you hash out in a single session with a coding agent. Sometimes it's the full stack: a requirements doc, a technical design, a prototype, architecture decision records, and specs. Either way, somebody has to look at it and say yes.

The second is the outcome. Did the agents build the thing that solves the problem?

The tricky part is everything in between, and how much governance you put there. Go light and the build is off to the races, but you'll spend more time at the end approving outcomes and dragging the work back to where you meant for it to go. Go heavy and you'll catch drift sooner, but you're in the loops all day.

Make no mistake, if you're building enterprise systems, you're going to spend the time. When and where is the whole game.

How I decide how much governance

There are a lot of ways to handle this, and every company has to work out its own. For me it comes down to classifying the work before anyone starts.

I ask two things. First, what happens if we get this wrong? Is this a P0 app tied directly to revenue? Is it a major feature? Will customers feel it? Second, how fast will we find out, and how fast can we back it out? That one is really about how mature your platform and your CI/CD are. If a user hits a problem, how long until you hear about it, and how long until you can roll back or respond?

Put those side by side and you get something like this:

Fast to detect and roll back

Slow to detect or roll back

High cost if wrong

Moderate plan, strong outcome checks

Heavy plan, governance in the loops, a defined way to validate outcomes

Low cost if wrong

Light plan; let outcome checks and rollback carry it

Light plan, but fix the feedback loop before adding more agents

Most teams get the top row right. The box that bites people is the bottom right: a change that looks small, so it gets almost no planning, on a platform where nobody hears about problems quickly.

Bug fixes are a good example. It's tempting to treat every bug the same. I'd rather take a couple of minutes to classify it first. A small bug in a minor feature you can roll back quickly doesn't need much ceremony. A bug in a revenue-critical flow with slow feedback deserves a real plan, even if the fix ends up being two lines.

Both ends of the dial hurt

With too much governance, the process gets rigid. You still get gains, but your engineers get pulled into every loop and asked close to the same questions over and over. That wears people out.

That's what happened to me on that spec run, and it's the version that worries me most. Imagine a rule that a developer has to sign off on every change to every document. With a handful of agents running, that can be hundreds of sign-offs. Nobody reads hundreds of anything carefully. Eventually the person in the loop just starts agreeing, and now you're paying for governance without getting any protection from it.

Too little governance hurts in a different way. The work drifts from the architecture and the outcomes you started with, and it drifts fast. Run a long loop on a complex app with little planning and you'll spend a lot more time at the end working out the kinks. Do the same while adding features or fixing bugs on a product people already use, and you'll ship new problems and make the experience worse.

So where's the right mix? Honestly, it tends to show itself as you go. In my experience it's usually wherever the architecture or the expected outcomes are changing. That's where I'd put governance, and I'd ease off where things are stable. Addy Osmani makes a related point in his loop engineering piece: a loop that runs on its own also makes its mistakes on its own, so checking the work is still your job.

What I'm actually checking

Approving a plan takes experience. You start simple. There's a problem to solve, and the plan should lay out the best path to solving it. Knowing whether it really is the best path comes from having built platforms and applications before. That makes this a leadership problem as much as a process one. Hire people with that judgment, and give the people you have chances to build it, small ones first and then bigger ones. It's the same thing Rishi said on Tuesday about not skipping the apprenticeship.

Approving an outcome takes understanding. You need to know the problem you set out to solve and how the platform or app is supposed to behave. This is where all that planning pays you back. Did we write down use cases and user stories? Can the builder and the reviewer both use them to check the result?

One question I keep coming back to: could someone who knows nothing about the project read the plan and quickly tell whether the outcome is right? If they can't, the plan isn't done.

A checklist you can steal

Here's the short version. Copy it, change it, make it yours.

Before the work starts:

• Classify it. What does it cost if it's wrong, and how fast can you catch it and roll it back?

• Set your governance level from where it lands on the grid.

• Write the problem down first, then the path.

• Write the use cases and user stories the outcome will be checked against.

• Get the plan approved by someone who's built this kind of thing before.

While the agents work:

• Put governance where the architecture or outcomes are changing. Ease off where they're stable.

• Watch for rubber stamps. If approvals come back fast and nothing ever gets sent back, people stopped reading a while ago.

At the outcome:

• Check the result against the use cases, not just green tests.

• Run the newcomer test on the plan.

If you want to go deeper

• The 2026 State of AI Code Quality Report from Qodo, where the review numbers above come from.

• The AI-native SDLC playbook from Anthropic, a stage-by-stage look at the lifecycle once agents write the code.

• Loop Engineering by Addy Osmani, on designing the loop instead of writing the prompt.

• Running a Software Factory Efficiently at Uber Scale from Uber Engineering, on running managed agents with human review and tracking quality for each one.

I'm curious where other teams have landed on this. Where is your team spending its approval time today: on the plan, in the loops, or at the outcome? Hit reply and tell me. The best answers will turn into future issues.

This was Part 1 of Building in the Agentic Era. Subscribe free to get the next part in your inbox. You can also reply to any issue, and the best questions become future issues.

Get the next part

The opinions expressed here are our own and do not represent any employer, past or present. Nothing in this publication describes any specific company's internal systems, data, vendors, teams, metrics, or plans. Sponsored placements and sponsored briefs are clearly labeled.

Till next time,

Ellis & Kherdekar

Engineering Leadership in the Agentic Era, Part 1 By Rishi

Agentic AI is an operating model change, not a smarter form of automation. That distinction decides whether an engineering org gets lasting capability out of it or a shelf of pilots.

Most engineering orgs have spent years getting good at reliability, security, developer productivity, and customer outcomes. Agentic AI makes every one of those harder, and teams that already do them well have a head start.

Leading engineering teams inside a large enterprise, I often see agents treated as automation with a better vocabulary. That framing undersells what changes. An agent works toward a goal, picks its own tools, pulls in context, and adjusts when conditions change. That affects how you architect systems, and it also affects how you organize people, govern risk, and measure success.

This is the first post in a series on building engineering orgs that are ready for this shift. I'm starting with the playbook I'd use as a leader. Later posts go deeper on each play.

New here? Two engineering leaders on building and leading with AI inside a large enterprise. Every Tuesday and Thursday, free, in your inbox.

Subscribe free

Play 1: Start with one workflow

Big enterprise AI programs lose momentum when there's no concrete workflow attached to them. I'd rather start with one workflow that is valuable, measurable, and contained enough to learn from.

For each candidate, I'd ask the team five questions:

• What business or customer outcome gets better?

• Where are people spending time on repetitive judgment, coordination, or looking things up?

• Which decisions can an agent assist with now, recommend later, and possibly make on its own eventually?

• What does an acceptable failure look like, and where does a person stay accountable?

• Do we use it, compose it, or build it?

I spend the most time on the last question. Use an existing product when it covers most of the problem. Compose when you can combine models, retrieval, tools, and APIs around the need, which is where I think most teams should land. Build only when your own data, domain logic, or customer experience gives you an advantage worth maintaining.

Building is the most expensive option, and in my experience it's also the easiest one to justify in a planning meeting, so I hold it to a higher bar.

Play 2: Organize around small pods that own outcomes

Handing a model to another team and calling it done doesn't work with agents. Someone has to own the workflow, the evaluations, the telemetry, the safety controls, and the user experience as it evolves, and that works best when it's one accountable team.

The model I favor is a small, durable, cross-functional pod that owns an outcome end to end. That pod needs strong engineering leadership, real domain expertise, and a product owner, plus easy access to security, data, and platform support. The engineers in it should be comfortable working across boundaries.

The tell that a pod isn't really accountable is that its evaluations live with a different team than its outcomes. When the people measuring the agent and the people answering for it are not the same people, the measurements stop being honest.

I still see a big role for central platform teams. Where I push back is when every decision gets centralized. The teams closest to the business process should own delivery, and central teams should make them faster with shared identity and access controls, a model gateway (one controlled entry point for every model call), observability, evaluation tooling, approved data access patterns, and policy enforcement. Getting that split right is one of the harder alignment conversations for a leader, because both sides have good reasons to want more control.

Play 3: Build governance into the platform from day one

In most orgs, governance shows up late. A team builds something and then asks security, legal, or risk to approve it. With agents that's too slow, and the approval goes stale quickly because the system keeps changing.

I'd move toward continuous governance instead. Leadership sets direction and boundaries, teams work inside them, and the production system keeps generating evidence that agents are behaving as intended. As that evidence builds up, agents can be given more autonomy.

In practice, every team shipping agents needs:

• A clear identity and scoped permissions for each agent and each tool call

• Human escalation paths for high-impact decisions

• Traceability across prompts, tools, data sources, outputs, and actions

• Offline and online evaluations (repeatable tests of agent behavior against known cases, before release and in production) tied to real failure modes

• Kill switches, rate limits, budget caps, and approval thresholds

• Monitoring for quality, safety, latency, cost, and business outcomes

Most governance lists are really visibility lists. If you can't see what an agent did and why, nothing else on the list is enforceable, and you have no real basis for giving it more room.

Play 4: Invest in context

Model capability matters, but context decides more agent projects than the model does. A strong model without the right data, domain meaning, permissions, memory, and tool access still makes a poor teammate.

The agent that fails most often in practice is the one with the best model and the worst permissions.

That changes how we should think about data. I'd treat it as a product with a consumer, and that consumer now includes agents. Agent-ready data is built for a purpose, carries useful metadata, is structured for reliable use, and connects to the right persistent memory.

Most of the investments this needs are ones we should already be making:

• Domain data products with clear owners

• Explicit schemas and definitions

• Good retrieval and knowledge access patterns

• Data lineage and access controls

• Feedback loops that improve context over time

• Interfaces that let agents take safe actions in addition to generating text

What agents need is the right data at the right time, with the right permissions and an audit trail.

Play 5: Run the team like a research lab

Agents bring real uncertainty. Outputs are probabilistic, workflows keep changing, and good designs usually emerge through experimentation.

Mature teams can keep their standards high and still get more empirical. I'd treat each deployment as a hypothesis: define the problem, set a baseline, agree on success criteria, run controlled experiments, study the failures, and improve. Done well, a research-lab culture makes a team faster at learning and more honest about what the data says.

Play 6: Keep developing junior engineers

It's tempting to staff these pods with only senior people. Senior engineers and domain experts are essential for shaping architecture, controls, and strategy. If we stop hiring and developing junior engineers, though, we give up our future bench for a short-term gain.

The people who will lead AI engineering in five years need room now to build domain judgment and production instincts. Agents make it easier to skip that apprenticeship, which is exactly why leaders should protect it deliberately.

Putting it together

None of this requires a big reorg. I'd run it as a focused operating experiment:

1. Pick one high-value workflow with measurable pain and manageable risk.

2. Form a small, accountable pod that pairs engineering strength with real domain expertise.

3. Decide whether to use, compose, or build.

4. Put evaluation, observability, access controls, and human escalation in place before you scale.

5. Measure whether outcomes improved, and resist reporting activity, demo counts, or model usage as progress.

6. Protect the pipeline of people who will run this in five years.

7. Reuse what worked, both platform patterns and team practices, for the next workflow.

The orgs that get the most from agentic AI will be the ones with a repeatable way to turn trusted, context-rich agents into lasting business capabilities. The number of pilots matters much less. As leaders, our job is to build that system and let autonomy grow only as fast as evidence, safeguards, and customer value allow.

This series is about building engineering teams for an agentic world: culture, org structure, talent, how we govern and measure the work, and how leadership itself has to change. Later posts go deeper on each play, and on the areas around them that decide whether an org can actually operate this way.

What's the first workflow in your org where a small pod could prove both measurable value and trustworthy agent behavior? Reply and tell me. The best answers become future issues.

This was Part 1. Subscribe free to get the rest of the series in your inbox. You can also reply to any issue, and the best questions become future issues.

Get the next part

The opinions expressed here are our own and do not represent any employer, past or present. Nothing in this publication describes any specific company's internal systems, data, vendors, teams, metrics, or plans. Sponsored placements and sponsored briefs are clearly labeled.

Till next time,

Ellis & Kherdekar