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.
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:
Pick one high-value workflow with measurable pain and manageable risk.
Form a small, accountable pod that pairs engineering strength with real domain expertise.
Decide whether to use, compose, or build.
Put evaluation, observability, access controls, and human escalation in place before you scale.
Measure whether outcomes improved, and resist reporting activity, demo counts, or model usage as progress.
Protect the pipeline of people who will run this in five years.
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.
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,