This is Chapter 2 of a book we're writing in public about how the rise of AI agents is reshaping teams, coordination, and the future of knowledge work. Chapter 1, The New Shape of Scale, is where we started.

We're writing this book in public. Each chapter will be published as it's written. The ideas are evolving and your feedback is welcome.

Chapter 2 — The Evolution of Coordination: From Waterfall to the Agentic Order

Every coordination tool a software team has ever used was an answer to a question about scarcity: what is in short supply, and how do we arrange ourselves so we don't waste it? The answers changed as the scarcity changed, and the history of how teams coordinate is really a history of that moving constraint. We ended the last chapter with a claim — that the constraint has moved again, from time to mind-share — and an inherited toolkit that no longer fits. To understand why the old artifacts misfire now, it helps to see exactly what problem each was built to solve. Each was the right answer to its era's question.

So this is a genealogy: waterfall, agile, DevOps, platform engineering, and the agentic moment we're now standing in. We consider each era through four questions: What was scarce? How did teams coordinate around that scarcity? Who held the decisions? And what uniquely human capability was that era trying to preserve? The answers change from era to era, but together they reveal a remarkably consistent pattern. Each generation built new ways to protect whatever human capability had become the limiting factor, until the next constraint emerged and the cycle began again. One of these threads is worth following on its own: who held the decisions. Every shift in how teams coordinated was also a shift in who got to decide what and when. That migration — from a specialized few, to the whole team, and now toward the machines themselves — is the same story told from the inside.

A caveat before we start. This is a deliberate simplification of how individual teams actually organized themselves. Each came in many flavors; no two teams ran the same way, and shelves of books have gone into the distinctions. The point here is not to adjudicate those debates. It is to capture the essence of why each broad approach existed, what problem it was reaching for, and why that reasoning no longer holds.

Waterfall: coordination through document

The first era emerged when software was young and expensive. Compute was expensive, and a deployment might mean shipping physical media or booking mainframe time. Execution was slow, the cost of being wrong late in the process was enormous, and the scarce resource was certainty. More certainty in the plan led to better outcomes; less led to waste a team could not afford. The rational response was to be as right as possible early, before any of the expensive steps began. So teams borrowed from disciplines that had solved exactly this at scale — civil engineering, manufacturing — and arranged the work in phases: requirements, then design, then implementation, then verification, then maintenance, each signed off before the next began.

Execution plans were rigid and detailed and decisions were front-loaded. Business analysts and architects settled on what and how to build at the outset, project managers guarded the plan, and everyone downstream executed choices someone else had already made. Time deepened the trap. The road from idea to shipped product was long and the pace was glacial, measured in quarters and years, so the reasoning behind a decision often faded from view as people rotated and priorities shifted. The "why" was quietly forgotten, and the plan was the one thing that endured across the stretch. A team could be celebrated for delivering exactly what it promised while the product failed, and judged more harshly than one that strayed, slipped its dates, but shipped something better. Success was often pinned to the plan, not the outcome.

The coordinating artifact of this era was the document. A requirements specification was a contract; a design document was a contract; the phase-gate review was the moment the contract was ratified and the next group was allowed to start. This is how large numbers of people get coordinated when they cannot all fit in one room or hold the whole system in their heads: the system is written down, frozen, and handed across the boundary to the next group. The document is the interface between people who will never need to talk, because everything they need to know has been committed to paper. Waterfall, fairly or not, became the name for this methodology, drawn from a 1970 paper by Winston Royce that diagrammed the phases as a cascade. The irony, mostly forgotten, is that Royce put the diagram up in order to knock it down: he called the pure sequential version "risky and invites failure" and spent the rest of the paper arguing for iteration. The field kept the picture and dropped the warning.

What waterfall taught us about coordination is durable: handoffs are dangerous, the interface between two groups is where meaning leaks, and writing things down is how people outside the conversation still take part in it. Its deeper contribution was preserving certainty across large organizations by embedding it in documents that outlived the conversations that created them. What it assumed is what broke: that the future was knowable far enough ahead to be specified before being built, and that change was rare and expensive enough to design against. For systems where a defect is catastrophic — avionics, medical devices — that assumption still holds. But for most software it was simply false, and the falseness compounded. Requirements changed under the document. The late correction waterfall existed to prevent turned out to cost less than building the wrong thing precisely.

Agile: coordination through iteration

The second era was a revolt against the first, aimed squarely at waterfall's broken assumption. By the late 1990s a set of practitioners had concluded that the future was not knowable in advance, that requirements were discovered by building, and that the document-and-freeze model was therefore not just slow but actively misleading. It produced beautifully specified versions of the wrong product. In February 2001, seventeen proponents of Extreme Programming, Scrum, and a handful of rival lightweight methods met at a ski lodge in the Utah mountains and, between runs, wrote the Agile Manifesto. It put the inversion plainly: working software over comprehensive documentation, responding to change over following a plan, customer collaboration over contract negotiation.

Agile could only emerge because the surrounding ecosystem evolved alongside it. It required more than modular architectures and greater team autonomy. It also required a new generation of developer tooling that made rapid iteration practical: version control systems that made branching and merging inexpensive, faster build and test cycles, and deployment pipelines that shortened feedback loops enough for iteration to become genuinely meaningful. The values were a reaction against waterfall, but the practice needed a substrate that hadn't existed a decade earlier.

If waterfall's scarce resource was certainty, agile's insight was that certainty could never be achieved through upfront planning. Rather than trying to eliminate uncertainty before work began, it optimized for the speed of the feedback loop. Coordination came not from writing the whole system down in advance, but from building a small slice, showing it to someone — a colleague, a customer, a partner — and letting what that revealed shape the next slice.

The unit of work shrank from the project to the iteration, and the artifacts changed with it: the backlog instead of the spec, the standup instead of the phase-gate review, the demo instead of the sign-off. The team became the unit of coordination: a small, cross-functional group that owned a slice of the product end to end, rather than a relay of specialists passing a document down the line. Because the team became the bottleneck through which work flowed, it also became the unit of optimization. In many organizations, predictable team throughput became more important than maximizing the leverage of exceptional individuals. Decision-making also moved: no longer front-loaded onto analysts and architects but distributed into the team, paced by a product owner who re-decided priorities every iteration. What to build next stopped being a document handed down and became a conversation the team had over and over.

Agile's lasting lesson is to shorten the horizon, work in small batches, and let feedback rather than prediction drive what comes next. Its deeper contribution was not simply faster software, but faster organizational learning.

When we said in the last chapter that the time horizon of our conversations is collapsing, we were describing an acceleration of exactly the move agile started. But agile carried its own implicit assumption: that the human team was the irreducible unit of production — that throughput was bounded by how fast a cross-functional group could build, review, and learn together, and that going faster meant tightening that loop. The two-week sprint is a human-metabolism artifact, calibrated to how much a team can absorb and ship in two weeks. When the building stops being done by people at people-speed, the sprint stops being the natural rhythm, and the loop agile tightened gets tightened past the point where its rituals still fit.

DevOps: coordination through automation

The third era found the scarcity in a seam. Agile had made development fast and iterative, but the iterations still slammed into a wall on the way to production: the wall between the people who wrote the software and the people who ran it. Developers optimized for change, operations optimized for stability. The two met only at release, which became the most vulnerable moment in the cycle. The scarce resource was a safe, repeatable path from a code change to its life in production, and it was scarce because it ran straight through an organizational boundary nobody truly owned.

DevOps, a name coined in 2009 by Patrick Debois after years of living through exactly this divide, dissolved the boundary by automating it and reassigning ownership across it. Its coordinating artifact is the pipeline: continuous integration, continuous delivery, infrastructure as code. The path to production became a program rather than a sequence of human handoffs. The philosophy that later became widely known as "you build it, you run it" had already begun taking hold inside companies like Amazon as teams shifted toward service-oriented architectures and assumed operational responsibility for the systems they owned. Ownership of a decision now ran all the way through to production. The person who wrote the change owned how it behaved at three in the morning. DevOps wasn't merely a technical shift; it aligned incentives with consequences by restoring the feedback loop between decisions and their operational impact. The people making design decisions now experienced the reliability, failures, and operational burden their choices created firsthand. Coordination improved because accountability moved with the work. Quality improved because incentives and consequences became aligned.

Coordination also moved out of meetings and into automation: the build server, the deployment pipeline, the test suite, the rollback button. But these systems did more than automate deployments. They continuously surfaced feedback that had previously crossed organizational boundaries only through people: whether the build passed, latency regressed, the service stayed healthy, or operating costs increased. In the cloud era, cost itself became part of the developer's feedback loop rather than remaining an accounting concern. Information that once arrived late — or not at all — became immediate, making reliability, performance, and cost the direct concern of the engineers making the technical decisions. Where waterfall coordinated by freezing the description and agile by shortening the loop, DevOps coordinated by encoding operational agreements into infrastructure that executed them automatically.

Encoding coordination into infrastructure this way is the clearest early instance of a pattern that matters enormously for where we're heading: turning recurring coordination into systems rather than rituals. A good deployment pipeline is a coordination decision made once and executed automatically every time thereafter. DevOps taught us that the most durable coordination is the coordination embedded directly into infrastructure instead of relying on people to remember to perform it. Its deeper contribution was aligning accountability with action by making operational consequences immediate and unavoidable.

This history is more than a backstory for us. Two of SageOx's founders, Ajit Banerjee and Ryan Snodgrass, built some of the earliest AWS systems during this transition and were shaped by the culture that produced "you build it, you run it." It instilled a conviction that operational excellence should not depend on heroics or vigilance, but should be designed into the system itself: instrumented, observable, resilient, and increasingly self-healing. More importantly, it left them with a broader mental model: hard coordination problems can often be transformed into infrastructure. Instead of asking people to remember the right thing to do, build systems that make the right thing happen by default. That instinct sits at the foundation of SageOx. We believe the coordination challenges of the Agentic Order can be approached the same way — not by adding more process, but by building infrastructure that carries more of the coordination itself.

DevOps automated the path the work travels, but it still assumed a human author at the head of it, deciding what change to send down the pipeline. Shipping became cheap. Deciding what to build — and producing it — remained fundamentally human work.

Platform engineering: coordination through platforms

The fourth era is the most recent and the closest cousin to the problem this book is about, so it is worth slowing down. DevOps succeeded, and its success created a new scarcity. "You build it, you run it" had handed every team the full stack: not just their code but the infrastructure, the deployment pipelines, the observability, the security posture, and the cloud bill. Each team now had to be expert in everything, and the cognitive load was crushing. The scarce resource was no longer a safe path to production — as DevOps had largely solved that — but human attention, swallowed by the sheer surface area each team had to understand to ship anything at all.

Platform engineering emerged in response. Rather than asking every product team to master the operational stack, organizations created dedicated platform teams whose job was to build and operate an internal developer platform. Instead of treating infrastructure and internal tooling as shared utilities, they treated them as products, with other engineers as their customers. The platform abstracted away undifferentiated complexity — deployment pipelines, Kubernetes, cloud networking, security policies, observability — into self-service capabilities that teams could consume without understanding every layer beneath them. Netflix called its version the "paved road." Spotify called it the "golden path." The explicit goal was to reduce cognitive load so product teams could stay focused on solving customer problems rather than rebuilding operational expertise. It also split decision rights: the platform team owned how software shipped, which freed product teams to own what they shipped. The coordinating artifact of this era is the platform itself: leverage packaged into well-designed defaults, reusable abstractions, and self-service workflows that remove the need to repeatedly solve problems someone else has already solved.

But no amount of tooling dissolved the organizational strain underneath. SageOx's third founder, Milkana Brace, spent this era at Remitly in meeting after meeting, of a kind happening across the industry at the time, debating how a platform team should balance the needs of its internal customers: how much to evolve the platform itself versus satisfy each team's immediate requests, how much capability belonged in the platform versus should remain the responsibility of individual teams. These were architectural and operational questions with real trade-offs, and almost every one was resolved the expensive way: multiple stakeholders in a room, spending human attention to decide. Platform teams also faced a subtler challenge. Because they served internal customers rather than external ones, the value they created was distributed across the organization and difficult to measure. Every additional engineer on the platform returned leverage to dozens of product teams, yet that leverage rarely appeared directly in customer metrics or revenue. As a result, platform teams were often understaffed even as the organization's dependence on them continued to grow.

Platform engineering is the first era to name cognitive load itself as the bottleneck, in the phrase Matthew Skelton and Manuel Pais put at the center of Team Topologies. Its central insight was that human attention had become the scarce resource worth protecting. That makes it the nearest ancestor of where we are, and it got the diagnosis half right: when attention becomes scarce, the answer is leverage — systems that return it instead of consuming it. What it did not anticipate is the source of the new load. Platform engineering assumes the load comes from the breadth of the stack a human author has to manage and abstracts that stack so the human can stay focused on writing code. But the load we described in the last chapter comes from somewhere else entirely: the volume of work agents produce — work a human must read, judge, and trust faster than a human can. Platform engineering paves the road for a human walking it. It has nothing to say about a road suddenly carrying a thousand vehicles no human is driving.

The pattern, and the break

Step back from the details and the four eras reveal a remarkably consistent pattern. Each begins with a new scarcity. Each invents a new coordinating artifact to address it. Each redistributes decision-making to match the new reality. And each pushes more of the work of coordination out of people and into systems. Waterfall coordinated through the document. Agile through the iteration. DevOps through the pipeline. Platform engineering through the platform itself. Together, they trace a fifty-year progression toward the same destination: spending less human effort on coordination so more human effort can go toward creating value. Seen another way, each era preserved the scarce human capability of its time. Waterfall preserved certainty. Agile accelerated learning. DevOps aligned accountability. Platform engineering protected attention.

As that progression unfolded, decision-making migrated with it. Waterfall concentrated it in architects and analysts who settled the design up front. Agile distributed it to cross-functional teams that re-decided priorities continuously. DevOps extended ownership all the way into production by aligning incentives with consequences. Platform engineering redistributed decision rights once more, with platform teams owning how software was built and shipped while product teams owned what was built. The job titles changed with every transition — webmaster, scrum master, DevOps engineer, site reliability engineer, platform engineer — each emerging to solve the dominant coordination problem of its era before gradually fading into the background as its practices became embedded in the next.

Yet beneath all four eras, one assumption remained remarkably stable: humans did the producing. The document was written by people for people. The iteration was a loop of people building and learning. The pipeline carried changes authored by people. The platform paved a road for people to walk faster. Every capability these eras sought to preserve — certainty, learning, accountability, attention — was ultimately constrained by human production. The entire genealogy is a sequence of increasingly sophisticated answers to one question: given that people make the software, how do we help them make it together without drowning in coordination?

That shared assumption is what the agentic moment breaks.

When agents begin producing alongside humans, the load-bearing premise beneath fifty years of coordination practice gives way. Throughput stops tracking headcount, as we argued in the last chapter, because production is no longer bounded by human effort. The bottleneck shifts from production — where every previous era located it — to comprehension, where none had reason to look. The handoffs each era worked so hard to eliminate reappear in a different form — not between people with different responsibilities, but between an agent and the human trying to understand what it did, and between one agent and another that lacks the context to continue the work. Yet again, the inherited toolkit is exquisitely optimized for a bottleneck that has moved.

The new Agentic Order

So what should we call this new era? We call it the Agentic Order because we believe it represents something larger than another software methodology or technology wave. It is a new organizing principle for how humans and agents work together. It is still being invented, and we're among the earliest teams attempting to understand it while the ground shifts beneath all of us. This book is our attempt to describe its emerging contours. Which ideas endure and which practices harden into convention is for time to decide.

Its defining fact is that a substantial portion of production has moved to agents. The migration of decision-making that ran through the whole genealogy — from architects, to teams, to platforms — now extends beyond people altogether at the edges: agents make thousands of small decisions that no human explicitly approves. What remains uniquely human is no longer the building itself, but the steering: setting direction, exercising taste and judgment, and maintaining the shared understanding that everyone and everything now acts from. For the first time in this lineage, the scarce human capability is judgment: our ability to decide what matters, what is correct, what can be trusted, and where attention belongs while the building happens around us at a speed we did not set.

If the pattern established by the previous eras continues, this new scarcity should produce a new coordinating artifact. Waterfall had the document. Agile had the iteration. DevOps had the pipeline. Platform engineering had the platform. The Agentic Order requires a new coordinating artifact: infrastructure that preserves and propagates the team's judgment as work flows through humans and agents. The rest of this book is our attempt to describe what it must become.

The shift to the agentic era changes the role of documentation itself. It does not disappear; it bifurcates. Some artifacts become more durable, transcending individual projects and deliverables to guide work over long periods of time. Vision, values, constraints, acceptance criteria, and design intent become operational inputs, written as much for agents as for humans. They no longer attempt to predict every implementation detail; they establish the intent and boundaries within which work unfolds. Other artifacts move later, becoming the residue of the work rather than its prerequisite. Implementation decisions, trade-offs, summaries, and lessons increasingly fall out of the interaction between humans and agents instead of being written by hand after the fact. The challenge is no longer producing documentation. It is ensuring that intent survives the journey from human judgment, through agent execution, and back into shared understanding for future work, without becoming distorted along the way.

That makes the coordination problem of this era fundamentally different from those that came before it. Waterfall preserved certainty. Agile accelerated learning. DevOps aligned accountability. Platform engineering protected attention. The Agentic Order preserves human judgment. Context matters not as an end in itself, but because it preserves the team's judgment across an expanding network of humans and agents. The central question is no longer simply whether an artifact exists, but whether it faithfully carries the intent behind the decisions that produced it. Can a human trust what an agent understood? Can another agent act without drifting from the original objective? Can the reasoning behind a decision survive long enough to shape the next hundred decisions made on its behalf?

The failure mode is not that agents make decisions. It is that they make them without faithfully carrying forward the team's judgment. Every conversation, plan, decision, summary, and artifact is an imperfect compression of what people actually meant. As work passes between humans and agents, that compression compounds. Intent fades. Assumptions disappear. Context is mistaken for instruction. The dangerous failure is not a spectacular mistake, which is usually obvious and easy to react to, but a gradual drift away from what the team would have chosen had they remained in the loop.

Every era in this genealogy built new infrastructure around the scarce human capability of its time. Ours must do the same for judgment. Preserving the team's judgment as work propagates through an increasingly autonomous system is the central coordination problem of the Agentic Order. The rest of this book is about how to solve it.

The Evolution of Coordination — from waterfall to the Agentic Order. Each era evolved to preserve the scarce human capability of its time: certainty, learning, accountability, attention, and now judgment.

We're publishing this book chapter by chapter as it's written. If this resonated — or if you disagree with something — we'd love to hear from you: feedback@sageox.ai