A manifesto for AI-era delivery · May 2026
The Discovery
Manifesto
Agile was built for a world we no longer live in.
In the new one, if you can't experiment,
you're already failing.
We are discovering better ways of delivering AI by building it and helping others build it.
Agile gave us a way to ship software whose behaviour could be specified in advance. AI systems are not specified — they are discovered. Their quality emerges in operation, their unit of change is an experiment, and their definition of done is proven, not asserted. Discovery is what fits instead.
By "agile" we mean Scrum and its sprint-based derivatives — what most teams practice today. The original 2001 Agile Manifesto values are what Discovery extends, not what it rejects.
There is still value in specifications, gates, and assembly. Where work can be specified in advance, we use them. But for what must be discovered, we value the following items on the left more.
The Pillars
Pillar I
Speed is value, not delay.
A solution shipped in weeks gives the business something the same solution shipped in months never gets to: time to use it, learn from it, and improve it. AI evolves faster than projects — what takes too long arrives obsolete. Time to value is not an efficiency metric here; it is a survival metric.
Speed is not the reward for good delivery. It is the point of it. Everything that follows exists to ship sooner without shipping worse.
Pillar II
Outcomes, not specifications.
Work is defined by what the system must achieve, expressed as a measurable threshold. The engineer who receives that definition owns the how entirely. This eliminates the user story as the fundamental unit of AI work. Telling the engineer how to write the prompt defeats the purpose of employing someone capable of owning the solution.
Pillar III
Thresholds, not gates.
Done means the system clears a pre-agreed success rate. Not that it passed a test, not that it satisfied a reviewer, not that the demo looked convincing in a sprint review. This requires locking the KPIs before the build starts, building automated evaluations against those KPIs from day one, and treating the eval suite as non-negotiable regardless of deadline pressure. The system either clears the threshold or it does not ship.
Clearing the threshold means the system can ship. The work continues from there. An AI solution always evolves — monitored, tuned, and adapted in production as inputs, context, and expectations change.
Pillar IV
Integrity, not assembly.
An AI solution is an interactive probabilistic system, not a collection of features. Prompts, context, guardrails, and fallback logic must be designed as a single coherent whole by one person who holds the full mental model. When construction is distributed across engineers who each own a component, nobody owns the emergent behaviour. The architect, paired from day one with a deputy whose purpose is to inherit the full mental model, owns the complete design.
What once took a team, one architect now does with AI. Singular ownership is no longer an ideal — it is the practical shape of the work.
The architect does not just build the system; they govern it. They own its behaviour, its boundaries, and — where multiple agents interact — the emergent behaviour that arises between them.
Components built separately do not become a system when assembled. They become an incoherent stack with no owner of the whole behaviour.
Pillar V
Two speeds, not one rhythm.
Deterministic work and AI work require different rhythms. What can be specified runs through standard agile. What must be discovered runs on a faster experiment loop. The test is simple: if acceptance criteria can be written as input-to-output pairs before the work begins, it is deterministic. If quality can only be evaluated by observing behaviour over time, it is AI work. The experiment lane has no sprint ceremonies — only a hypothesis, an eval suite, and a deployment record.
The Principles
We follow these principles.
- 01Speed is value. Every week earlier is a week the business can use the system, learn from it, and improve it. Delay is not just cost — it is obsolescence.
- 02We define work by what the system must achieve. The engineer owns the how.
- 03We never dictate the prompt. We set the target and step back.
- 04We audit the data before we build. A confident agent on bad foundations gives confident wrong answers.
- 05We match the solution to the problem. The right level is often deterministic or hybrid, not always a model. Fit beats sophistication.
- 06We lock KPIs before building. We ship when the eval passes. The eval suite is non-negotiable.
- 07We advance when the KPIs prove it, never when the calendar says so.
- 08One architect holds the full mental model. We pair the architect with a deputy from day one — for handoff, not oversight.
- 09Prompts, evaluations, and orchestration are the assets we own. We build portable — the architecture outlasts any model, any vendor, any person.
- 10If acceptance criteria can be written as input-to-output pairs, it runs as agile. Otherwise it runs as an experiment.
- 11Prompt changes skip the sprint. An experiment is not a feature.
- 12We do not wait for permission to experiment.
- 13We keep the customer in the loop continuously — through demos and a live sandbox, not through sprint reviews. The customer experiences the system, not its fragments.
- 14We observe behaviour, not just outputs. A decision the system cannot explain is a liability we cannot defend.
Frequently Asked Questions
What is the Discovery Manifesto?
The Discovery Manifesto is a manifesto for AI-era delivery. It sets out five pillars and fourteen principles for shipping AI solutions when sprint-based agile does not fit. It extends the original 2001 Agile Manifesto values into work where behaviour is discovered, not specified.
Why doesn't agile work for AI?
Sprint-based agile assumes work can be specified in advance, validated in fragments, and gated on binary acceptance criteria. AI work is probabilistic: quality emerges in operation, the unit of change is an experiment, and done is a measurable threshold rather than a checkbox.
How is the Discovery Manifesto different from the Agile Manifesto?
It extends Agile rather than rejecting it. The original 2001 Agile Manifesto values — individuals over process, working software, responding to change — are preserved. Discovery adds five pillars for AI work: speed over delay, outcomes over specifications, thresholds over gates, integrity over assembly, and two speeds in one team.
What does discovery mean in AI delivery?
In deterministic software, you build what you specified. In AI work, you discover what the system actually does by running it. Quality is observed in operation, behaviour is uncovered through evaluation, and done is proven by measurement — not asserted by review.
What is the cost of delay in AI delivery?
AI evolves faster than projects. A solution that takes seven months to ship may be obsolete by launch — overtaken by new models, new tools, or new customer expectations. Time to value in AI delivery is not an efficiency metric; it is a survival metric. Speed is the first pillar of the manifesto, not a reward for good delivery.
Who is the Discovery Manifesto for?
Practitioners building AI solutions — architects, engineers, product owners, and delivery leaders working on AI Agents, AI Skills, agentic systems, or any probabilistic AI capability. It is also for executives and sponsors deciding how AI work should be funded and governed.
What is the deputy?
The deputy is not a reviewer or a manager. They exist to inherit the system’s full mental model, ensuring continuity when the original architect steps away. Without this, the system loses ownership and degrades over time.
How do I sign or get in touch?
To add your name, email sign@discoverymanifesto.org — we'll confirm before listing you publicly. For anything else, reach us at info@discoverymanifesto.org.