The forest metaphor comes from Adam Bender's talk Software Engineering at the Tipping Point, delivered at Google I/O in 2026. Bender states directly: "It will not be long before we are all not just managing a tree, but an entire forest. And you can't manage a forest by looking at individual trees. You have to manage a forest by seeing it as an ecosystem."

For most of the industry, the unit of care is still a single tree: a repository, a PR, a test suite, a sprint. An engineer tends one tree at a time, and quality comes from the care that individual puts into the individual tree. That model worked when the number of trees an engineer could affect was small. It strains badly when agents can open dozens of PRs a day, each one individually fine and collectively unreviewable.

The value in that straining system is moving up a layer. Engineers still exist and still matter. What they do changes shape: instead of writing each tree's code, they increasingly define how the whole ecosystem behaves. Which steps run unattended. Which gates must pass before a change ships. What data an agent may touch. What "done" means for a class of work rather than for one ticket. The work happens at the level of processes, gates, guardrails, and organization-wide semantics.

So the layer-up idea, stated plainly: yesterday's engineer wrote code, while today's engineer defines and maintains the system that writes and ships code.

Why Modulo is built this way

Everything in Modulo's architecture follows from the principles of Modulo, and from one assumption on top of them: engineers will work at that upper layer, so the software under them must hold steady while they do.

Pipelines are defined and versioned at the organization level. A delivery process in Modulo is a named, versioned pipeline graph: which agent nodes run, in what order, with what prompts and schemas. That graph lives at the org level, and editing it is an ordinary, reviewable change. This assumes that the thing engineers want to modify is the process itself, and that the process should be as inspectable as any other artifact they own.

Deterministic gates sit between agent steps, with human approval points. Agent output does not flow forward on its own. Between steps sit deterministic gates - schema checks, regex checks, scored evals - and HITL approval points where a required human reviews the evidence before anything proceeds. The assumption encoded here: engineers will insist on defined pass/fail conditions rather than vibes, and they will want to review outcomes, not raw output.

Every run is immutable and inspectable. A run captures its full snapshot - the graph, gate decisions, node outputs - and cannot be quietly rewritten after the fact. If an agent did something odd at 3 a.m., the record lets an engineer reconstruct exactly what happened and correct the process that permitted it. This assumes engineers will correct the process above the failure, once, rather than personally fixing the symptom in every affected tree.

Dispatch runs from the cloud rather than from workstation installs. A pipeline run executes in an isolated environment with the external tools it needs - GitHub, Linear, and similar tools - rather than on whoever happened to be at the keyboard. That choice assumes the delivery system outgrows any individual machine and session, which is what a forest requires by definition.

Underneath all four choices sits the same principle Bender articulates when describing system-level health: "You can't resolve any of these by just looking at a single node in the system. You have to look at the whole system." Patching one buggy agent prompt is a single-node fix. Debugging why code review piles up even when every individual PR is decent is a whole-system fix. Modulo puts governance where Bender says the problems actually live: above any single agent, at the level of the system.

One bounded claim about output follows from this design. When the pipeline - rather than headcount - absorbs the per-tree work, and the engineer's job shifts to defining and improving the pipeline, a team can scale its output by compute time rather than by adding engineers. That is a property of the design, observable in how stable, reviewed pipelines run: the throughput lever is machine time, governed by people, and hiring is a lever for improving the process rather than a prerequisite for more PRs.

What this does not mean

Two misreadings sit close to this metaphor, so we will rule them out.

First: this is not a claim that fewer engineers are needed. The demand for software keeps growing, and "10 to 15x growth" is exactly the kind of pressure Bender was describing. Governance layers exist to let a team survive growth without drowning in review queues. They cannot build software for a team that has stopped shipping.

Second, and more important, this is absolutely not a claim that non-technical people can ship software. Modulo may be bought by engineering and DevX leaders but it is driven by software engineers, full stop. There is a real evolving-role story to tell, and we tell it plainly: engineers increasingly define processes, gates, and governance at the organization level while agents carry out the per-tree execution. Engineers configure the pipelines. They decide what each gate must check. They read run outputs, judge whether an agent's work is sound, and adjust prompts, schemas, and autonomy levels until the system behaves as defined. That is skilled technical work every day, and it is the work this product is built around.

Bender's summary of his own field clarifies why this judgment-work sits at the upper layer: "Engineering is programming integrated over time." Design, review, tests, operations, the slow accumulation of what works - that integration is precisely the part of engineering that scales differently from raw code production. Agents can carry the per-tree coding workload under governance. The integration over time - deciding what the system should do, keeping the delivery process healthy, making the calls machines cannot make - remains the engineer's layer, and that is exactly where this product positions its value.

Where the layer goes from here

A forest needs managers, and the managers are engineers. The industry needs people who choose to work at that layer, who would rather define a reviewable pipeline than clear forty PRs by hand every Monday. We built Modulo as the substrate for that work because we wanted it for our own delivery, and we bet that is where a meaningful share of engineering attention is heading - because the cost of per-tree care is already visible in the queues.

The layer will develop the way layers usually do: through standards, through better gate primitives, through shared governance patterns teams exchange between each other. That is how we expect it to develop, and we intend to keep building the substrate under it while it happens.