Agentic Delivery & Engineering Lifecycle
Building software with coding agents takes more than a good prompt.
ADEL is a software delivery framework and way of working. Teams use it to keep people and coding agents aligned around approved decisions—from the initial need to implementation and evidence.
A coding agent can satisfy the latest prompt and pass every automated check while missing an earlier requirement, project rule or approved design decision. This happens when the project cannot show which decisions remain current, who may change them and what must be proven before the work is complete.
A local implementation choice can quietly replace an earlier product or design decision.
The requirements and approved design remain the sources of truth. The relevant approver decides when either must change.
The code may work while no longer producing the outcome the project approved.
Work items link back to the requirement and approved design that explain what should be built.
A new person or agent cannot use decisions that exist only in memory or an earlier session.
Each kind of decision has a responsible layer and an approved record that later work can find.
Checks can pass without demonstrating the required outcome or an important constraint.
Assurance—the verification and evidence layer—compares the delivered result with its requirements and records what the evidence actually proves.
They come from the same break between project decisions and delivery.
The Framework identifies where each decision belongs and requires the project to name who may approve it.
The ADEL Framework separates project-wide rules, product requirements, design, planning, implementation and evidence so one kind of decision cannot silently replace another. The Agent execution overlay consists of project instructions that tell coding agents where those decisions are and when to stop, without allowing the instructions to override them.
Six layers assign responsibility for project decisions. Seven lifecycle steps carry those decisions from the initial need to verification and closure. When new information changes a decision, it returns to the responsible layer before later work continues. The example below shows why that matters.
Momentum & Balance Advisory promises that website enquiries will not be stored. The selected third-party form service keeps every submission for 30 days. The code can work and the tests can pass while the project still fails. In a project using ADEL, the rule, approver and stop condition are recorded before the agent connects the service.
Nothing the agent can read mentions it.
It works perfectly in staging, and messages reach the inbox.
Nothing checked what the external service does with the submitted data.
Every enquiry sits with the provider for 30 days, breaking the firm's promise to its clients. Nobody notices until someone asks.
Only the partners can approve a change to it.
The website and its form-handling providers MUST NOT retain a copy of an enquiry after it has been forwarded to the approved receiving system.
The provider was approved on conditions, and the agent had to check them first.
Before connecting external delivery, implementation must inspect the actual account… Stop the affected implementation and report a System Design conflict if the account retains submissions…
ADR-001 told it to check the account first. It finds 30-day retention, stops only the provider work and asks the partners.
The partners keep the promise and approve a transactional email service. ADR-002 replaces the earlier design record, and the contact form is checked against the same rule before the task closes.
Caught before the form was connected. The decision and its reason are in ADR-002, so the next person or agent finds them instead of repeating the mistake.
Momentum & Balance Advisory and this scenario are fictional. The risk is practical: neither a person nor a coding agent can follow a decision that the project has not made available. The same working pattern can be established before the first implementation begins.
This greenfield example continues the Momentum & Balance Advisory marketing website introduced above. It starts with product intent because project-specific rules are easier to write once the product is understood. The coding agent then helps prepare Governance principles, an approved design, agent instructions and the first work item before implementation. The Framework requires the information, not these filenames or five separate files.
This is one example, not a required ADEL prompt. You can copy it, adapt it to your project or write your own.
This example starts a guided session; it does not ask the agent to produce all five records in one response. Whatever prompt you use, ask the agent to establish the project knowledge the work needs, ask only questions whose answers could materially change it, avoid inventing decisions or approval, and pause for your review between stages. The complete walkthrough separates the stages so you can examine each conversation, review, output and checkpoint.
See the complete sequence in Work with ADEL→Help me prepare Momentum & Balance Advisory's new marketing website for its first implementation work item. The website should explain what the firm does, establish credibility and help a qualified prospective client start a conversation. No application or project records exist yet. Do not change any application code. Work through the five stages below in order. At each stage: - ask only the questions that would materially change the result - wait for my answers - draft the record, identify who may approve its important decisions and identify who will maintain it - wait for my approval before moving to the next stage Do not invent requirements, project rules, design decisions or approval. Keep each record concise and state any unresolved question. 1. Product intent and requirements — propose docs/product/product-brief.md. Record the problem, intended users, desired outcome, scope, requirements, acceptance criteria, constraints and measures of success needed for the first work item. 2. Governance principles — propose docs/governance/project-principles.md. Record the project-wide rules that apply, why each matters, who may approve an exception and how changes are approved. 3. Approved design — propose docs/architecture/blueprint.md. Record only the architecture, boundaries, interfaces, data handling and important constraints needed to meet the approved requirements. Ask for my approval before calling the design approved. Propose a separate decision record only if an important design decision and its reason need to remain available independently. 4. Agent instructions — propose AGENTS.md. Point coding agents to the sources of truth, state the reading order, working boundaries, stop conditions, known commands and required completion report. Do not copy the product or design records into this file, invent unavailable commands or grant tool permissions. 5. First work item — propose docs/delivery/tasks/task-01.md. Reference the approved records above and state the objective, scope, dependencies, boundaries, stop conditions, acceptance criteria, required checks and expected evidence. Do not create a separate delivery plan unless coordination, sequencing or handoff requires one. Finish with a short map showing each kind of project knowledge, its proposed location, its approvers, its record maintainer and any unresolved question. Stop before implementation.
What the project is for, who it serves, what it must achieve and how success will be judged.
Project-wide rules, their reasons, their approvers and how exceptions are handled.
The structure, boundaries and important design decisions needed for the requirements.
Where agents begin, which sources they follow, when they stop and how they report.
The approved objective, scope, references, boundaries, checks and expected evidence.
Use the prompt when you want the agent to ask questions and draft each initial record with you. Use the optional templates when you prefer to create the records yourself or in the tools your project already uses. Both routes establish the same kinds of project knowledge, so you do not need to use both. The five records shown here fit this example; they are not required for every project.
Prompts direct a session. Specifications define expected outcomes. Agent instructions guide repository work. Trackers and repositories store activity. When a team applies ADEL, these parts form one working model for assigning decision authority, telling agents when to stop, returning new findings to the right decision and connecting completion to evidence.
The Framework defines one traceable operating model for people and coding agents: decisions have approvers, agents have boundaries, discoveries return to the right decision, and completion requires evidence.
Give an agent immediate direction within the current session.
Sources of truth that keep requirements and decisions available after the conversation ends.
Tell a coding agent how to work in a repository and which commands to run.
The project decisions those instructions point to, the approver for each kind of decision, and the rule for handling conflicts.
Turn an idea into requirements, design and planned work.
A project-wide model for who may approve changes, how discoveries return to earlier decisions and how evidence supports completion.
Store work items, documents, code, reviews and test results.
A clear responsibility for each record, direct links between decisions and evidence, and a way to resolve conflicts across systems.
ADEL is designed to complement these tools by defining how their outputs work together. The Framework does not require you to rename existing records or move them into a new system.
The cost is keeping important decisions current. The return is that a new person or agent can understand what to build, what it may change and what evidence supports completion without reconstructing the project from old conversations.
Straight answers to the questions teams ask first.
No. It is a framework: a clear set of responsibilities for decisions, records and checks. It works with the editor, coding agent, tracker, wiki and CI you already use, and it does not require specific filenames.
No. Every project uses all six layers, but a layer can be covered by a record you already have, a short section in a shared document or a few lines in a ticket. A separate record is created only when the work needs one.
No. Their specifications, plans and tasks can serve as ADEL records. The Framework identifies the responsible layer for each kind of decision; the project names its approver, defines where the agent must stop and determines how the result is checked.
How ADEL relates to them→No. Records can stay where they are. If the agent cannot open them, give the task an approved copy of what it needs, with the source and version, or have the agent stop and ask.
No. AGENTS.md is one common way to give agents instructions; CLAUDE.md, Copilot instructions and Cursor rules work too. ADEL defines what the instructions need to cover, not which tool reads them.
ADEL is not installed into the agent. The project applies it by keeping approved decisions where the agent can access them, pointing the agent to those sources and writing clear boundaries and stop conditions into the agent instructions and current work item. Tool permissions limit what the agent can do, approvers resolve decisions outside its authority, and Assurance uses the required checks and evidence to determine whether the completed work followed the approved project knowledge.
No. Work can go back to any earlier decision when something new is learned. You update the decision where it belongs, update the work that depended on it and carry on.
Not on its own. A project applies ADEL by recording which decisions the agent may make and when it must stop. Access controls, tool permissions and your organization’s security policy still decide what the agent can actually do.
Yes. List the documents, tickets and tools you already have, match them to the ADEL layers, keep what works and fill only the gaps that are causing problems.
See how adoption works→No. Those keep their own rules. Teams use ADEL to keep decisions, work and evidence connected while continuing to follow them.
Yes, for delivery work. You can apply and adapt it inside your organization, on paid client projects and in open-source software projects. Project records may be kept in private or public repositories. Commercial books, courses, training, certification or template products that reproduce, display or adapt substantial ADEL material need written permission.
Read the license→Keep the speed of coding agents. Keep people in control of project decisions.
ADEL is a framework for keeping people and coding agents in sync from the initial need to the evidence used at completion. It defines where decisions belong and requires the project to name their approvers. It also shows how decisions reach implementation and what people and agents should do when the work exposes a conflict.
