Over time, though, we also built a fairly defined operating model around it. Epics, stories, tasks and sprints. Scrum ceremonies. Jira boards. Useful structures, but structures nevertheless.

Somewhere along the way, the structures around Agile began to obscure the spirit of agility. At least for me.

There is another aspect worth questioning: many of these units were sized for people. A story is something a developer can reasonably finish in a sprint. A task fits into a smaller window of work. We decomposed work this way because that is the size a person can estimate, own and execute.

AI changes that assumption.

A coding agent like Claude Code, Codex or Cursor can often operate on a much larger unit of intent, build, test and iterate without requiring the same human-sized decomposition upfront. How large that unit can safely be depends on the maturity of the harness around the agent, the context, constraints and evaluation it works within.

But the unit no longer has to be what one developer can finish in a sprint. Decomposition will still have its place. The difference is that it becomes a tool chosen for the intent, rather than the default shape of the process.

This becomes especially relevant in pod-based, AI-aided development, what some now call agentic software development. A small team can increasingly own an outcome end to end, with agents expanding its execution capacity. In that environment, forcing every intent through the same hierarchy of epics, stories and tasks can become an unnecessary constraint.

That does not make Agile obsolete. Agile can evolve with this. But perhaps the more interesting question is whether adapting the existing model is enough.

That leads me to a different development model: Intent-Based Development.

The pod owns the outcome. The intent provides direction. The execution path adapts.

Sometimes an agent may build and iterate directly. Sometimes the first step is experimentation. Sometimes it is configuration, composition of existing services, generated code, or discovering that nothing needs to be built.

The developer's role changes with it. Less about mechanically decomposing work into predefined units. More about expressing intent clearly, providing context, defining constraints, evaluating outcomes and applying judgment.

Intent leads. Process adapts.

Perhaps the next evolution of Agile is not another methodology. It is an operating model where agility becomes a property of the development system itself.

But if I look past that momentary frustration, it has been a major enabler. An enabler, not a magic bullet.

And that friction is the point. The back and forth is where the thinking happens.

I sense another pattern emerging, though, and it is far more troubling, because it affects the foundation of a knowledge economy.

An email arrives, polished and well structured, every point carefully qualified. It reads like a lawyer wrote it. Sometimes that is the intent. Say many things without saying anything. Is the sender worried, or just being careful?

A strategy document takes an afternoon. Having a plan used to say something about how much thinking had gone into it. It says less now. The skill is in how well you can make it your own.

Ask for ten ideas and you get ten, ready to present. Where does originality stand in that? Many of them start to look alike. The one new idea in the room still has to compete with nine that sound just as good. I can look at a slide now and often guess which model created it, and then wonder what level of thinking went into it.

Vibe coding has made it easy to build something that runs. It also means a lot more things now look like products. The distance between something that runs and something that can be owned, supported and trusted has not shrunk much. It has just become easier to overlook.

I am calling out four easy places, but you might notice it in many others. The same paradox sits underneath: as producing good-looking work gets easier, judging what is actually good gets harder.

The finished thing used to carry some evidence of the thinking behind it. That premium is rapidly reducing. The thinking is still the hard part. It has just stopped being visible.

I have been on that side of it myself. I have had a slide made that certainly carried my conviction, but not my vocabulary, and then failed to articulate it well in my own language when presenting.

And the collateral debt shows up later. When the emails going back and forth are that hedged, the decision is the casualty. A plan nobody made their own gets executed anyway. Originality is lost in a barrage of sophisticated arguments. And the case for a well designed product gets less compelling when you can simply prototype with intent.

I do not think the answer is to slow any of this down. In fact, I would like it to accelerate, and how to do that well is something I am still internalizing.

What does it mean to put your name on something that took five minutes? When is polish a courtesy, and when is it a hedge?

The bar for producing came down quickly. The bar for judgment has to come up just as fast.

Being human means we sometimes get things wrong. A bad mood. A rocky first meeting. A poorly written note. Any number of triggers can throw us slightly off balance, and in the moment our reaction can feel completely justified.

Say you were hard on someone because their work did not meet your expectations. It felt right at the time. Then some time passes, and you find yourself replaying it. With some reflection, you might realize they were coming from a different point of view. Sometimes the correction is small. You go back with a nudge. Maybe I missed something.

Reflection leads to realization. Realization sometimes exposes a gap, between how I reacted and how I would have wanted to show up. That leads to assessment. And assessment, if you are willing to act on it, leads to self-correction.

Reflect. Realize. Assess. Correct.

What I find interesting is that this loop can operate at very different speeds. Sometimes it takes hours or days. Sometimes it takes seconds.

I notice that most clearly while presenting to an audience. The first few slides, a few faces, a few moments of eye contact, and you start sensing the room. Are they with you? Are you losing them? Is the message landing the way you expected? The same loop is now happening in real time. You notice. You interpret. You assess. You adjust.

The better you get at reflection, the shorter that loop can become. That is a remarkably powerful leadership loop, if done right. Not because you stop making mistakes. You won't. But because you build a mechanism that keeps correcting your trajectory, sometimes after the fact, and sometimes while you are still in the moment.

If self-reflection comes naturally to you, harness it. It may be one of the most durable forms of leadership development available to you.

Be your own frontier.

As I reflect on such inflection points, now and even earlier in my career, my mindspace has always been to stay curious, ride the wave, and shape it in your capacity and around you rather than wait for it to disrupt you.

Of the three lanes of AI adoption, enterprise and team need coordination with others. The personal lane is uniquely ours. It can be the most open ended, unhinged and creative of the three, and it stays with us wherever we go.

Personal here means you decide what to build and why. It can run through your day job or well outside it.

Here is a thinking model for it. Treat it as an investment and pay attention to the dividend.

The key is to recognize that building AI skills means different things for different people. In other words, what is your need and imagination as you look to embed AI in your personal rhythm. It is possible for some of you it could be more influenced by your work lane and that is ok.

For some of you it might mean AI augmented technical writing, an SLM based personal AI space, a research companion for a field you wanted to learn, an agent that helps your parents or your kid, or your own agentic home management system.

Once you have identified a work stream, then take your tasks and decompose them into logical units. Look at these tasks objectively. Some of these will stay with you. Some an agent can augment or replace. Some, over time, become an agentic flow you don't really touch anymore.

I would start small here and let trust and expertise build before expanding, since trust has many moving parts to it.

Next is synthesizing these agents into your own rhythm. This is where you become the confluence. The flows bring everything back to you, and you are the one adding the context, resolving what does not agree, deciding which risks actually matter and owning the recommendation.

In other words, think like a CEO, where judgement takes centrestage and not just task execution. Jobs of tomorrow will carry far more weight on the judgement side, and I suspect that is what separates folks who flourish in an AI native world.

As you iterate on various approaches, it is also important that you try and identify any differentiation which you can build on. I think of it as the elusive Super Power, always good to aspire for one.

Eventually these skills will start showing relevance in your work lane. When something works, keep it. These skills also help you stay close to, or take part in, conversations where you least expected to.

And then, with the time left, start building the next level of skills. That is the dividend. Building all this takes time and that is the investment, but when the next piece of work starts from what you already built instead of a blank page, some capacity comes back to you. Left alone it quietly disappears into more of the same. Directed, it can go into learning, into contributing at the team or enterprise level, and into the skills an agentic era will actually value.

The rhythm is yours to find. Some will build slowly and keep most of the work close, others will push more into the flows early. I don't think there is a right sequence here, only the question the dividend keeps asking: now that some capacity has come back, what is it for?

Stay curious. Stay hungry. Be your own frontier.

Unlike physics, in life, it hides much better. Because we are moving. Sometimes moving quite successfully. The calendar is full. The output is steady. The next milestone keeps arriving. But the direction may not have changed in years.

The more expertise, reputation, and success we accumulate, the more we have invested in the current trajectory, and the more force it takes to change direction.

The trap is that inertia photographs well. It looks like consistency, reliability, mastery. Every year on the same line can earn more recognition. From the outside, a high performer's inertia can be almost indistinguishable from performance.

Not all inertia is bad. Some of it is discipline, consistency, compounding. The dangerous kind is the inertia that keeps us moving long after we would have stopped choosing the direction.

It comes in different forms.

There is skill-set inertia. The comfort of operating where you are already an expert.

There is activation inertia. Wanting to pursue something different, but the capital, people, skills, or infrastructure required to test it make starting too expensive.

And there is success inertia. The current path keeps rewarding you, so you keep moving along it.

This is where AI gets interesting for me. Not simply because it helps us move faster. Because it can make changing direction cheaper. The would-be entrepreneur may no longer need a seed round and five hires just to test an idea. One person working with agents can prototype what once needed a team. A deep expert can venture into an adjacent field without first paying the full beginner cost of acquiring every supporting skill. AI, in that sense, lowers the activation energy required to move.

But lower activation energy does not tell us where to go. That still requires diagnosis.

What am I busy with today that I would not choose again?

I ran that question on myself this year. The answer was uncomfortable. Two decades of thinking, mostly kept closed source. Consumed in meetings and decks, then gone. Staying private photographed well too. It looked like discretion.

Publishing what I think, with AI as a collaborator, became one small way of applying force in a different direction. I even gave that experiment a home, a small publication called Digital Confluence, where these ideas now live beyond the meetings and decks where most of my thinking had traditionally ended. This post is part of it.

Perhaps that is the more interesting use of AI: not doing the same work faster. That can simply become inertia with better tooling. The opportunity is to use it to reduce the cost of testing a different direction, and then decide whether we have the will to move.

We never fully solved that problem. And that was code we could open and read.

By now, enterprises may already be full of agents that work too well to be noticed. They resolve requests, approve access, move data, and make thousands of small decisions in the background.

And the same script will repeat. Authors move on, leaving their agents behind.

Without a proper governance loop, the ghost script comes back in a new avatar. Shadow or sanctioned, the lineage offers no protection.

Someone will ask, or circumstances will force the question. An action shows up from a service account. You check with the user, and nothing traces back. Who is this agent? Why does it have this access? What exactly is it doing in our environment?

A ghost agent is not a repeat of the ghost script. It is a different beast altogether.

Why? A ghost script gets noticed when it fails or causes impact. Then it gets an owner or is switched off.

A ghost agent may not produce that signal.

Its behaviour comes from the model, the prompt, the context, the memory, the tools, the data, and the policy. Each of these can change on its own schedule, without anyone touching the agent itself. The agent keeps acting through all of it, with credentials, access, and consequences. Worse, its capability can grow without anyone deciding it should. A new tool here, a wider permission there, and it can start doing things it was never intended to do.

Most of our controls assume that meaningful change has an author and leaves a trace. Version control, change management, diffs, and audits all rest on that assumption.

An agent can behave differently tomorrow even when no one has changed the agent itself.

So what would have to exist, at a high level?

1. Ownership would have to be binding. Every agent with action authority needs a named owner. When the owner leaves or stops answering for it, the agent loses its action rights until a new owner accepts them. Quarantine as the default, not an incident response.

2. Each agent would need a living record of what it is, not just what it did. Its purpose, ownership, skills, reach, dependencies, and authority. Logs tell you what happened. The record tells you what the agent is now, and what it could do tomorrow.

3. If an agent can behave differently without its code changing, then we need a baseline for how it behaves and a continuous check for drift. The change record moves from the artifact to the conduct.

We talk about agent sprawl as a scale problem.

The quieter problem is the ghost agent, whatever its lineage: behaviour that can change without leaving a diff.

First published on LinkedIn, August 17, 2026.

In his prime, a coterie of clients would sit in the verandah. I would sit somewhere in the side, listening with rapt attention. He reviewed each case aloud, and an assistant took notes. I was never sure how much of what he spoke got recorded verbatim, and how much was the assistant's rendering.

The assistant had become a subject matter expert over time, and could piece two and two together in my grandfather's narrative. By evening, ten or more of those cases became briefs. He would review each one and make sure it carried his thesis and his logic. To what level of detail, I never knew but it used to be often quick.

As I use AI as a collaborator in most of my thought engagement, that verandah came to mind while discussing its pitfalls with a few folks with different perspectives. The technology has evolved. The underlying operating model might not have.

His judgment stayed at the center. The drafting moved to someone else. The review was not about every word. It was about whether the brief carried his thinking and his way of telling it. That is a fair description of how I work with AI today.

But I also remember what happened when the assistant changed. It was rare, and I could see the discomfort in his rhythm. He was more frustrated, and sometimes more intentional in ensuring what he said carried through. Too much of how he worked lived in one person's head.

Our version of that problem is not rare. The assistant changes constantly. Models get updated, tools get replaced, sessions start from zero. The difference is that we can build for it. Skills and context that persist, and workflows around the collaborator, so the model of working survives the change smoothly.

His operating model still holds. The harness is what we get to add, because this assistant is evolving in ways we cannot control. It is the pattern with most technology shifts: draw from what worked, and build beyond it for our time. The future proofing is perhaps what was missing in the past.

For those of us who look at AI as a disruptive force, I hope this parallel gives some context.

And as I think about it, my daughter is watching me engage with an AI assistant. Her future version might draw some inspiration too. A positive one, I hope.

From the outside, that shape looks like the nature of IT. But it is closer to a reflection of the conditions it grew up in. The work under the hood was intricate, often unstructured, sometimes chaotic. The expertise to run it was scarce, and the demand for it was not.

When a thousand people need help and fifty can provide it, you build machinery to protect the scarce side. You queue demand, tier responders, and write catalogs to standardize what can be asked. The friction people feel in IT is mostly rationing, done professionally.

And demand kept trying to escape it.

Shadow IT was unmet demand finding supply it could buy with a credit card. DevOps and platform engineering were a more disciplined escape, rebuilding the interface as self-service. Each move was locally rational, and each took something with it. Context, spend visibility, and accountability moved up to the enterprise and sat there, unowned.

The pattern across all of it was the same. Expertise could not reach demand, so demand routed around IT.

AI can change the supply side. It does not just make the fifty people faster. It can put usable expertise directly where the thousand people already are, so IT can meet demand where it lives instead of asking demand to come to the queue.

If every function does this alone, the old pattern repeats with better tools. If IT does it deliberately, the old reason to route around IT goes away.

The layers do not disappear. They get rebuilt around what stays scarce: judgment about risk the requester cannot see, accountability when something breaks, and the view of how a thousand local changes add up.

Little of this is unique to IT. Any function that built its shape around scarce expertise faces the same question.

The question is no longer how to protect the fifty from the thousand. It is how to stand behind what the thousand can now do.

First published on LinkedIn, July 29, 2026.

It wasn’t the score. It was the tone of those opening exchanges—the lunging tackles, the constant edge, the sense that the match could spill over at any moment. By the final whistle, it had.

Back at work, I mentioned the switch to few team members. A colleague said something almost in passing: maybe it is the team culture. The same players turn out for their clubs every week and often look like different footballers.

That stayed with me. The players do not suddenly lose their ability between club and country. What changes is what the group rewards, tolerates, and amplifies.

For some reason, it brought me back to my favourite topic. A lot of the agentic AI conversation assumes capability is the variable. Yet two organizations can deploy the same models and tools and still end up somewhere very different.

First published on LinkedIn, July 22, 2026.

I sometimes wonder whether it belongs in a launch announcement or a risk register. What matters is what that scale creates and whether the enterprise can operate it.

Consider 1,000 agents across service management, finance, sales, HR, legal, and operations.

They will not arrive through one program. Many will come embedded in the CRM, ERP, ITSM, HCM, and contract platforms each function already runs. They will be useful locally and adopted independently, often with different prompts, memory, credentials, and policies.

Each function sees its own agents. No one sees or owns the system they form together.

The same applies to the runtimes beneath them. Each may look controlled inside its platform. But every additional runtime creates more surface area where enterprise IP has to be protected.

An individual agent may work well. The risk sits in the dependencies agents and runtimes create together, and in whether the enterprise can operate that collective system safely and economically.

Without shared foundations, context gets recreated and knowledge begins to diverge. Policies drift, permissions accumulate, and lineage and cost become harder to see.

A thousand agents could become a new form of enterprise sprawl. This time, the components reason, remember, and act. The layer also keeps changing as models, data, permissions, and ownership evolve.

At tens of thousands, sprawl can become the default architecture.

Four capabilities look structural to me:

1. A deliberate runtime estate with common control across it.
2. Shared context and knowledge, including governed memory.
3. An operating model for identity, ownership, lifecycle, and earned autonomy.
4. AgentOps across lineage, behavior, outcomes, drift, and cost.

Vendors can provide pieces. They cannot decide which runtimes to support, how context should be shared, or where accountability sits. Those choices have to reflect the enterprise's decision rights and risk boundaries.

Experiment broadly in controlled environments. That may mean fewer strategic runtimes, clearer ownership, tighter control boundaries, and a smaller portfolio that earns autonomy over time.

I am still working through what this takes in practice. No single function naturally owns the whole problem. And each runtime provider is incentivized to make its own platform work, not the estate around it. That may be exactly why the fabric does not get built.

The ten-thousandth agent is not the hard part. The first thousand may already have created an unmanaged operating layer beneath the enterprise.

The agent count will make the headline. The operating fabric will determine whether that scale becomes leverage or sprawl.

First published on LinkedIn, July 12, 2026.

Individual leverage. Team flow. Enterprise flow. Three different problems, with different couplings, that do not translate cleanly across them.

At the individual level, adoption moves fastest. Fewer dependencies. Fewer people to align. Less waiting for the system around you to be ready.

This is the lane that decides how you meet the change which is coming. Fluency here is not a convenience. It is how you learn to make AI your extension, and how the work you do stays yours as the shape of it shifts.

It also asks for caution. The same fluency that makes you valuable can leak the thing that makes you valuable. Knowing what to ask the system is the visible skill. Knowing what not to put in front of it is the quieter one.

Team flow is different. A team where each person uses AI for drafting, summarizing, or analysis is still mostly individual leverage. Useful, but local.

Not yet team flow. Team flow begins when the work itself starts moving through the agent.

Take an incident bridge in IT operations. An engineer using AI to summarize logs is individual leverage. An agent carrying the incident narrative across shifts, teams, decisions, and customer updates is team flow. Same technology. Different adoption curve.

The category is real, but the maturity range across teams will be wide. DevOps showed this. Two teams can both claim adoption and mean very different things — one with deep continuity, observability, and shared accountability, another with a few automated handoffs. Team flow will look the same. Naming the lane is not the same as moving along it.

Adoption is not a place you arrive at. The horizon moves as you walk.

The question shifts from how do I work better to how does the team coordinate when part of the context and memory is now carried through agents. And quietly, underneath, another question — who owns the narrative the agent is now carrying.

Enterprise flow carries the largest blast radius. Accountability, systems of record, decades of process logic that autonomy alone does not untangle. It moves with more friction, and the friction is doing real work. When the friction is doing the wrong work, it builds theater instead of durability — and the difference is hard to see from outside.

It looks like the slowest lane. It is often doing the most consequential work.

Of the three, team flow is the hardest to see and easiest to underinvest in. Individual leverage is visible. Enterprise flow gets executive and control attention. Most enterprise AI roadmaps name a fluency program and a governance program. Almost none name a team-flow program.

Three lanes. Different shapes. The interesting question is not which one moves faster. It is which one each of us is quietly underinvesting in.

First published on LinkedIn, June 7, 2026.

You gather context, move between tools, stitch information together, produce something, decide whether it is good enough, and own the result.

AI is not just making those motions faster. It is changing the shape of the bundle. More of the assembly can move to the machine. More of the human work shifts toward judgment.

Same title. Same work product. Different work.

I see it while drafting this post. The first draft, the summary, the structure — more of that can appear quickly. The harder part becomes deciding whether it is true, useful, and still sounds like the person who owns it.

The same pattern shows up across very different roles.

A product manager spends less time turning inputs into artifacts, and more time deciding which tradeoff to make when the inputs disagree.

An analyst spends less time pulling and formatting data, and more time deciding what the data means.

An engineer spends less time on boilerplate, and more time on the call about whether the design is right.

The work does not disappear. It moves.

And often, it moves toward the parts that were always hardest to describe in a job description:
· Judgment.
· Taste.
· Context.
· Accountability.
Knowing when something is off.
Knowing when to trust the machine enough to act.
Knowing when not to.
...

That is why I think the replacement debate misses something important.

The question is not only which jobs go away. It is how much the work inside existing jobs changes before the title admits anything changed.

This shift is not cleanly good or bad.

It is useful and disorienting — because it moves the worker closer to judgment and accountability before the job title admits anything changed.

First published on LinkedIn, May 10, 2026.

But most enterprises are not starting from scratch.

They are evolving from deterministic systems that did more than coordinate work. They encoded accountability: how work gets assigned, how decisions get traced, who answers when something goes wrong, and how recovery happens.

Dorsey and Botha argue that hierarchy was the best available solution to a coordination problem that AI may now solve differently. That feels directionally right.

But in enterprises, hierarchy and deterministic workflows did more than coordinate. They carried accountability and control. They also embedded decades of enterprise logic — technical, procedural, and organizational — that autonomy alone does not untangle.

So this is not just a coordination shift.

It is a control shift.

We are moving from systems where every path is encoded explicitly to systems where intent is defined, boundaries are set, and the system determines the path. Not less control. A different kind — and it demands a different discipline.

What has brought this into focus for me is how quickly decision traceability starts to blur once the system is no longer following an explicitly encoded path. The output may still look reasonable, but the basis for the decision becomes harder to inspect, challenge, and reverse. And because the model itself can advance, drift, or regress, that surrounding traceability matters even more.

Enterprise AI is less about the model and more about the surrounding system. Accountability does not transfer automatically. It has to be rebuilt deliberately — through traceability, reversibility, bounded action rights, and decision frameworks that expand as reliability is demonstrated.

The end state may still be greater autonomy. But the path likely starts with the surrounding architecture: a governance and control plane, a context layer that evolves with organizational reality, and bounded domains where autonomy can be proven before it is broadly expanded.

The near-state is not defined by how much autonomy can be achieved.

It is defined by how much transformation can be absorbed responsibly — without breaking trust, accountability, or recoverability.

First published on LinkedIn, April 22, 2026.

What's missing is an operating model.

Isolated agent development is everywhere right now — good intent, impressive demos. But point tools stay point solutions. The mental model that makes more sense to me is agents as a managed workforce: clear roles, ownership, guardrails, access boundaries, and a way to measure reliability over time.

That also means building what I'd call a "context normalizer" — a translation layer between how the organization actually works and how agents behave inside it. Without it, you get agents operating inconsistently, escalating decisions they should own, or running without policy boundaries in sensitive domains. We don't expand human scope or autonomy without clarity on expectations and observed performance. Agents should be no different.

This is still an open-ended space — and the VM sprawl parallel feels apt to me: easy to spin up, hard to govern, and messy to unwind without a clear operating model. If agentic AI is going to scale in enterprise context, it will need the same discipline we apply to people and teams: a repeatable way to onboard, evaluate, and grow agent capability. Otherwise there'll be a lot of activity, and a fragmented end state.

First published on LinkedIn, March 15, 2026.

Not long ago, people went to San Francisco just to ride in a Waymo — a glimpse of the future made possible.

Then one showed up near our campus in Sunnyvale. Uninvited, but still exciting. Something shifted from "thing I heard about" to "thing that exists in my world."

Then one afternoon driving alongside me on the street. No driver. Just the road, and whatever was making the decisions. I pointed it out to my daughter. I wondered if this would feel ordinary to her by the time she grows up.

Then a moment I won't forget — a Waymo in my lane, another in the adjoining lane, and I realized I might be the only human driver in that stretch of road.

A few months pass. Seeing them regularly. The novelty fades, but a quiet curiosity lingers. Then clusters, parked outside the office. Just part of the landscape. Then one morning, parked on my street. My neighborhood.

That's normalization. Not a launch event. Not a press release. Just quiet, incremental presence. And yet, when I see one navigating an intersection, I still notice. I still evaluate. I still hesitate, just slightly.

Normalization and trust are not the same thing.

The visible part is the car. The invisible part is the discipline that made it safe enough to become ordinary. Most of us experience that shift as consumers, noticing it once it's already normal.

Somewhere else, for years, someone invested in the invisible layer that made that moment possible.

That difference is easy to miss.

First published on LinkedIn, March 7, 2026.

This persistent gap between intent and execution is what I've come to think of as human engineering. I've become increasingly intentional about trying to master it — not as a soft skill, but as a discipline. I'm learning that excellence is less about pushing harder and more about designing environments where:

• incentives and context outweigh individual brilliance
• alignment is the default setting
• friction surfaces early rather than being buried

What intrigues me is how this lens applies to agentic AI. As digital workers evolve, familiar themes reappear: context accumulation, domain understanding, and the need for guardrails that balance autonomy with control. It makes me wonder whether the evolution of AI agents will eventually require a new kind of behavior design — echoing the same human engineering challenges we've been navigating for years.

First published on LinkedIn, January 15, 2026.