Introduction

An agent can write code in minutes. That does not mean it can deliver software.

Software delivery includes discovering intent, gathering context, choosing an approach, changing a codebase, proving the change works, and leaving enough evidence for another person to trust it. A model can contribute to each step, but autonomous delivery only becomes dependable when those contributions are joined by an engineered system.

That system must answer practical questions. What does the agent know? Which tools may it use? How does work survive a failed process or expired session? Who can approve a consequential action? How is success verified? When several agents contribute, how do they avoid corrupting the same artifact? How does the system learn without turning every production mistake into a permanent instruction?

Agentic engineering is the discipline of answering those questions. Its concern is not a clever prompt or a particular model. It is the complete environment that turns probabilistic model output into controlled, observable, and recoverable work.

The path from one agent to a delivery system

The book develops that environment in eight stages.

It begins with one agent. A useful agent combines a model with instructions, tools, context, and a loop that lets it observe the results of its actions. Understanding that unit matters because orchestration cannot repair an agent that lacks the information or interfaces needed to do its job.

The next step is reliability. A harness manages the model’s execution, while durable execution lets work survive failures and pauses. Verification tests the artifact instead of trusting the agent’s report. Controls and security boundaries constrain actions according to their risk.

Reliability depends on knowledge. Context determines what the agent can see during a run. A knowledge base preserves useful information across runs. Skills package repeatable procedures, while agent readiness moves essential knowledge into the environment so every task does not begin with rediscovery.

With those foundations in place, the agent can deliver real work. Ticket enrichment turns an incomplete request into an executable unit. Planning and execution creates a cheap review point before implementation consumes time and compute. End-to-end orchestration connects the issue, code, verification, review, and merge surfaces into one recoverable workflow.

Only then does the book introduce many agents. The target is not unrestricted parallelism. It is a sequential delivery pipeline with bounded parallelism: research and review can fan out, while writes are serialised or separated by ownership. The coordination model protects the artifact from conflicting decisions, and the execution ledger records what every participant attempted and observed.

The sixth stage closes the feedback loop. Self-learning agents turn traces and human corrections into proposed improvements. An evaluation harness determines whether those proposals help.

The seventh stage turns the system into a software dark factory. The minimal bootstrap defines the point at which it can observe software-world signals, create and resume work, deliver verified changes, and sustain the cycle without constant human initiation.

The final stage expands the boundary to an autonomous business unit. The system now needs more than software capability: mission, axioms, goals, measures, authority, and wider world signals form the business identity that tells its agents what outcomes to pursue and which actions remain legitimate.

The role of humans

Autonomous delivery does not mean removing human judgment. It means placing that judgment where it has the most leverage.

The process uses two primary human checkpoints. The first reviews the plan, when changing direction is still cheap. The second reviews the completed change and its evidence before merge. Between those checkpoints, the system can research, implement, test, recover, and report without requiring a person to supervise every action.

Humans must also retain an operational escape hatch. They need the authority and information to pause work, inspect decisions, revoke access, recover failed workflows, and override automation. Autonomy is useful only while it remains accountable.

The destination: a software dark factory

The first destination is an agentic software dark factory designed to move work from issue to reviewed change with minimal intervention. The longer architectural direction is an autonomous business unit that can use that factory in service of durable business goals. The earlier chapters establish the responsibilities each stage must satisfy before the final chapters show why the broader identity and signal layers are needed.

The design remains deliberately separable from its current technology choices. Models, harnesses, storage systems, and hosting platforms will change. The durable architecture lies in the contracts between them: how work is represented, how capabilities are exposed, how state survives, how evidence is recorded, and where authority is enforced.

The next chapter begins with the smallest useful unit: one agent.