Chapter 1 — Two Meanings of ADLC, and Why the Confusion Costs You

"The agent development lifecycle (ADLC) maps the process of building, deploying, optimizing and managing AI agents into distinct phases." — IBM [D]

"The Agentic Development Life Cycle (ADLC) represents a fundamental transformation where autonomous AI agents shift from conversational assistants to credentialed actors capable of generating, reviewing, and executing code." — Cycode [D]

These are not two descriptions of one thing. They are two different things wearing one acronym.

1.1 A collision, not a controversy

Somewhere between 2024 and 2026, two communities independently needed a name for something new, reached for the same four letters, and did not notice each other.

The first community builds AI agents and sells them. Their problem is that the thing they ship behaves differently every time you talk to it. They needed a lifecycle for that, and they called it the Agent Development Lifecycle. The term appears to have been coined by Arthur around 2024 and was subsequently formalised by Salesforce as a five-phase Agentforce model, by IBM as a phased framework with iterative loops, and by Glean, EPAM, and Atlan in their own variants through 2025 and 2026 [D].

The second community builds ordinary software — payment systems, internal tools, data pipelines — but has replaced a large fraction of its typing with agents. Their problem is that code now arrives faster than anyone can read it. They needed a lifecycle for that, and they called it the Agentic Development Lifecycle. Cycode built a security platform around the term in March 2026; Forrester published The Agentic Development Security Tools Landscape in Q2 2026 — by Cycode's own account the first landscape Forrester had published for the category, "a market that didn't exist a year ago" [D].

Both communities abbreviate to ADLC. Both position it against SDLC. Both say, correctly, that SDLC assumed determinism and that this assumption has failed. And there the agreement ends, because they are describing different failures.

This is not a controversy — nobody is arguing. It is worse than a controversy. It is a category error propagating at the speed of content marketing, and it means that a practitioner searching for how to run their engineering organisation will receive, interleaved and indistinguishable, advice about how to ship a chatbot.

Before going further, a small observation about how names form, because it explains the mess and will recur in Chapter 7.

AGENTS.md was not announced. It appeared in repositories, spread by imitation across competing tools, reached tens of thousands of projects, and was only then formalised — donated to a foundation eighteen months after it started being useful. One meaning, near-universal.

"ADLC" was announced. Six vendors named it, top-down, each from the vantage of the product they sell. Two incompatible meanings, no convergence.

Conventions that emerge from practice converge, because practice punishes ambiguity immediately — a file that means two things breaks somebody's build. Conventions announced by vendors collide, because a vendor's naming is optimised for describing its own product, and nothing punishes the collision except confusion downstream, which the vendor does not bear. This is a skin-in-the-game asymmetry in Taleb's sense: the cost of the ambiguity falls on the practitioner, who had no vote.

1.2 Meaning A — the agent is the product

In Meaning A, the agent is the thing you sell. You are building a customer-service agent, a research assistant, a scheduling agent. Your engineering team may or may not use AI to build it; that is irrelevant to the lifecycle in question.

The defining problem is that your shipped artefact is stochastic. A user asks the same question twice and gets two answers. The distribution of answers shifts when you swap the model, when the retrieval corpus changes, when a tool goes down, when the season changes and users start asking about something your evaluation set never contained.

The controls that follow from this are runtime controls, and the literature on them is mature enough to be conventional:

Salesforce's five phases — ideation and design, development, testing and validation, deployment and release, monitoring and tuning — map recognisably onto SDLC with the emphasis relocated toward the last phase. IBM's framing is similar in structure, beginning with stakeholder alignment on success metrics "to inform an evaluation framework" and documenting expected agent behaviour in natural language before any code exists [D].

Note what that ordering implies. In Meaning A, the evaluation framework precedes the implementation, because there is no other way to know whether the thing works. Atlan's characterisation is apt: a closed-loop learning system of testing, monitoring, calibration, and refinement designed to manage the drift of an evolving system [D].

None of this is wrong. It is a coherent, useful discipline. It is simply not the subject of this book.

1.3 Meaning B — the agent is the labour

In Meaning B, the agent is your workforce. You are building a payments service, or maintaining a fifteen-year-old billing system, or migrating four hundred call sites off a deprecated API. The agent is how the work gets done.

The defining problem is that your construction process is stochastic while your product remains as deterministic as it ever was. The payment service does not behave differently for each user. It behaves the way the merged code says it behaves. What varies is what the merged code says, because it was produced by a generator whose output you cannot predict.

Cycode's inventory of what this breaks is the sharpest short statement available, and it is worth quoting because each item names a load-bearing assumption [D]:

• The author is a model. Attribution, accountability, and the social pressure that made code review work all assumed a human on the other side.
• Changes move at machine speed. Volume and velocity of code changes exceed human review capacity.
• The IDE is no longer the first feedback point. Code can be written, tested, and committed without a human ever seeing an editor.
• The pull request is no longer a natural checkpoint. It was a checkpoint because producing one was expensive.
• Dependencies are chosen by something that never read the package name, and has, in Cycode's phrasing, "zero understanding of organizational risk tolerance, compliance requirements, or business context."

The controls that follow are not runtime monitors. They are construction-time controls, and they are the subject of Part II of this book: the context assembled for each call, the guides that steer before generation, the sensors that catch after it, the graph that makes the repository navigable, the structure that limits blast radius.

1.4 Where the non-determinism comes to rest

Here is the distinction that matters, and as far as I can find it has not been stated cleanly anywhere. Everything else in this chapter is downstream of it.

Ask where the randomness ends up.

This single structural difference generates every downstream divergence between the two disciplines.

The row that repays the most study is the third. In Meaning A there is no last interaction, so no control can ever be final; you are running a perpetual observation programme against a system that will outlive your attention. In Meaning B there is a last moment — the merge — and this is a gift. A merge gate can be deterministic. It can block. It can be a type checker, a test suite, an architecture fitness function that either passes or does not.

Practitioners who come to Meaning B carrying Meaning A instincts systematically under-use this gift. They reach for probabilistic controls — a review agent, an LLM judge — in situations where a deterministic control was available and would have been strictly better. Chapter 8 gives this a rule: use the cheapest deterministic sensor that can detect the failure class, and reserve inferential sensors for what genuinely requires judgment. A linter that catches a defect every time beats a review agent that catches it four times in five, and it beats it not marginally but categorically, because you can build a policy on the first and only a hope on the second.

1.5 What the confusion costs

Abstract category errors are easy to shrug at. Here is the concrete damage, in both directions.

Transplanting A into B. A platform team reads that the discipline requires evaluation harnesses, drift monitoring, and token economics. They build an eval set for their coding agent, dashboards for output quality, and a per-developer token budget. Twelve months later they are still measured on the same delivery metrics as before, and the reason is that they instrumented the generator instead of the constraint. Nobody measured review load per engineer per week. Nobody tracked whether static-analysis warnings were climbing. The organisation has a beautiful view of its agent's behaviour and no view at all of its own verification capacity — which is, per this book's spine, the actual bottleneck. Their apparatus was built for a problem they do not have.

Transplanting B into A. A team building a customer-facing agent adopts context files, small batches, harness templates, and pre-commit sensors. Their development process is genuinely excellent — Chapter 15 would rate them at maturity Level 3. They ship. The agent is jailbroken in week two, because construction-time controls are silent about runtime adversaries, and no gate at merge time can constrain what a user will type in six months. They built a Meaning B harness around a Meaning A product.

The subtler cost: agent washing, internal edition. Because the acronym is shared, an organisation can satisfy an "ADLC adoption" objective by doing either thing, and will naturally do whichever is cheaper. Standing up a dashboard is cheaper than redesigning how code is reviewed. This is a governance failure that a naming ambiguity made possible, and it is not hypothetical: Gartner's estimate that more than forty per cent of agentic AI projects will be cancelled by end-2027 attributes the cause partly to unclear value [C] 🟡 — and unclear value is the natural end state of a project whose objective was ambiguous at the point of funding.

The cost to the literature. For researchers, the shared acronym makes systematic review nearly impossible. A search for "ADLC" returns two disjoint bodies of work whose citation graphs barely touch. Findings do not accumulate. This is a small, real, fixable harm, and fixing it costs one sentence of discipline per paper.

1.6 The containment relation

The two meanings are not siblings. One contains the other, and noticing this converts a naming problem into a structural insight.

Building an agent is a kind of software development. So if ADLC is the discipline of building software with agents, then building an agent with agents is simply ADLC applied to a particular product category. Meaning A is a special case of Meaning B — specifically, the case where the software under construction happens itself to be stochastic, which adds runtime obligations without removing any construction-time ones.

This is not a rhetorical move. It is observable in the artefacts.

Salesforce AI Research publishes a repository named agentforce-adlc, described as "Agent Development Life Cycle — Build, deploy, test, and optimize Agentforce agents using Claude Code skills and Agent Script DSL" [D].

Read that description slowly. It is a Meaning A framework — the agent development lifecycle, for building Agentforce agents — implemented as Claude Code skills, which is to say implemented as a Meaning B harness. Skills are one of the eight repository-level configuration mechanisms catalogued in Chapter 7. Salesforce is doing Meaning B in order to do Meaning A, and the same four letters name both layers of the sandwich.

Two consequences, and the second is the useful one.

First, an organisation building agents needs both disciplines, and the ordering is not arbitrary: the construction-time harness comes first, because you cannot reliably iterate on an evaluation set inside a codebase your agents are quietly degrading.

Second — and this is the reason the distinction earns a chapter rather than a footnote — Meaning A's mature practices are available for adaptation, and one of them is the most valuable import in this book.

Meaning A solved a problem Meaning B has not: how to state, before implementation, what "working" means for a system whose outputs you cannot enumerate. Evaluation harnesses, golden datasets, and the discipline of writing the eval before the feature are exactly the tools missing from what Chapter 8 identifies, following Böckeler, as the unsolved third of the harness — the behaviour harness. The current state of practice there is to generate tests with the same agent that wrote the code and hope, an arrangement whose circularity Böckeler names plainly: it "puts a lot of faith into the AI-generated tests, that's not good enough yet" [D].

Meaning A does not have that problem, because in Meaning A nobody would dream of letting the system under test author its own acceptance criteria. The eval set is built first, deliberately, by humans, from stakeholder-aligned success metrics. That practice is transplantable, and Chapter 8 attempts the transplant.

So the correct relationship to Meaning A is neither dismissal nor conflation. It is selective import with the boundary made explicit — which is only possible once the boundary has a name.

1.7 The thesis in one line

Delegated execution under human supervision.

Four words, chosen for what each excludes.

Delegated — not assisted. Assistance implies the human is still performing the task with help. Delegation means the task has been handed over, and the handover is the object of study: what was specified, what authority was granted, what came back, and how it was checked. Chapter 13 turns "how much" into a five-level ladder.

Execution — not generation. The unit of delegation is a task with a completion condition, not a block of text. This is the shift SWE-agent demonstrated and Chapter 2 documents: the interesting capability was never producing plausible code, it was operating in an environment until a test passed.

Under human supervision — not autonomy. Supervision is a real, costed, finite resource. Treating it as free is the mechanism behind the Review Collapse anti-pattern of Chapter 21, and treating it as unnecessary is the mechanism behind most of the incidents in Chapter 11. The purpose of a harness is not to remove human input. It is to concentrate human input where judgment is irreplaceable, by mechanising everything that is not judgment.

1.8 The vocabulary of this book

Fixed here, used for twenty-six chapters. Where a term is borrowed, the owner is named.

Two usages to enforce because they are the ones that slip:

"Context engineering" is not "prompt engineering" renamed. Prompt engineering concerns the wording of an instruction. Context engineering concerns the design of the entire payload — retrieved code, tool outputs, prior turns, file contents, instructions — under a budget. Different object, different discipline. Chapter 6.

"Harness engineering" strictly contains "context engineering." Context engineering designs what the model sees. Harness engineering designs the whole control system that decides what it sees, what it may do, and what checks it afterwards. The containment matters because, as Chapter 7's evidence shows, most teams have implemented only the inner discipline while believing they have implemented the outer one. The finding, from a study of 2,853 repositories, is stated by its authors without hedging: "Harness engineering in open source today is therefore mostly context engineering" [A].

1.9 What the reframing buys

Three things, and they are the reason to spend a chapter on vocabulary.

A defensible scope. This book is about Meaning B. Where Meaning A is relevant, it is named, bounded, and imported from deliberately. A reader can now tell whether any given piece of advice — mine or anyone else's — applies to them, by asking a single question: does the randomness ship, or does it stop at merge?

A correct place to point the instruments. If the randomness stops at merge, then the merge gate is where the engineering goes, and the thing to measure is not the generator's output quality but the organisation's capacity to verify. That reorientation is what Chapters 14 and 16 are about, and it is unavailable to anyone who has not first drawn this boundary.

An honest inheritance. Meaning A has solved problems Meaning B has not. Naming the boundary makes the import legitimate rather than accidental — and the most important import, the practice of specifying acceptance before implementation, is precisely the practice that Part IV argues is the last thing a human cannot delegate.