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.

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.

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.

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.

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.

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.