Principles for building systems where humans steer intent, agents execute within governed boundaries, and verified outcomes are the primary measure that matters for agentic work.
The Agile Manifesto was written for a world where humans wrote all the code. That world no longer exists.
In agentic workflows, generation, verification, and deployment run at machine speed. Legacy ceremonies — sprint cadence, velocity scoring, manual review-first pipelines — become bottlenecks and blind spots. Early empirical evidence, including the SWE-CI benchmark showing regression rates above 75% per CI iteration across 18 models (arXiv:2603.03823), confirms that agentic systems require purpose-built engineering discipline, not retrofitted Agile ceremonies.
This repository provides a complete alternative: the case for change, the manifesto itself, a companion implementation guide, an organizational adoption playbook, and domain-specific regulatory alignment for six industries.
The Agentic Engineering Manifesto (AEM) is the root layer of a layered governance stack for agentic systems. The dependency direction is explicit:
Agentic Engineering Manifesto (AEM)
├─ Agentic SDLC (ASDLC) — engineering-side governance of agent-built code
├─ Agentic Product Lifecycle (APLC) — product-side governance of agent behavior
├─ Intelligence Governance Manifesto (IGM) — substrate that agents reason over
└─ Agentic Enterprise Manifesto (AEnt-M) — enterprise coordination of multiple agents on a shared substrate
├─ depends on IGM (substrate)
└─ inherits AEM principles
ASDLC, APLC, IGM, and AEnt-M extend AEM and inherit its twelve principles. Earlier framings of the relationship as "complementary" or "companion" are retired in favour of the layered model above. See agentic-governance-stack.md for the canonical one-page reference, the layer-by-layer scope, and the term-collision preface that resolves cross-stack vocabulary collisions (e.g. confidence, autonomy tier, governance, initiative).
The Agentic Engineering Manifesto, ASDLC, and APLC are a layered set, but each is independently adoptable. Pick the one that matches the pain you are feeling now — you do not need to adopt all three at once, and you do not need to read them in order.
| If your pain is… | Start with… |
|---|---|
| An AI agent already in market or about to be, and you cannot describe its behavior, prove its drift, or govern foundation-model updates that change it without warning | APLC — the Agentic Product Lifecycle. Governs the agent product itself: behavioral specification, evaluation, drift, foundation-model update governance, regulated retirement. |
| Software delivery by teams using AI agents to write code, where the inner loop runs faster than your demand validation, release governance, or operational readiness can keep up | ASDLC — the Agentic Software Delivery Lifecycle. Governs the four-layer delivery lifecycle around agent-built software: demand, execution, release, operations. |
| Engineering practice itself — how humans steer intent, how agents execute within governed boundaries, what verified outcomes look like inside the inner loop | Manifesto — the Agentic Engineering Manifesto. Defines the inner engineering loop that both APLC Stage 3 and ASDLC Layer 2 reference. |
Each framework is independently useful. Together they form a complete governance stack for organisations dealing with both agent-built software and agent products in market.
| We value more | over | We also value |
|---|---|---|
| Iterative steering and alignment | Rigid upfront specifications | |
| Verified outcomes with auditable evidence | Fluent assertions of success | |
| Right-sized agent collaboration | Monolithic god-agents | |
| Curated, high-signal context and memory | Stateless sessions and noisy memory | |
| Tooling, telemetry, and observability | Chat-based heroics | |
| Resilience under stress | Performance in ideal conditions |
While there is value in the items on the right, we value the items on the left more.
- Outcomes are the unit of work
- Specifications are living artifacts that evolve through steering
- Architecture is defense-in-depth, not a document
- Right-size the swarm to the task
- Autonomy is a tiered budget, not a switch
- Knowledge and memory are distinct infrastructure
- Context is engineered like code
- Evaluations are the contract; proofs are a scale strategy
- Observability and interoperability cover reasoning, not just uptime
- Assume emergence; engineer containment
- Optimize the economics of intelligence
- Accountability requires visibility
See full text in manifesto-principles.md.
Specify → Design → Plan → Execute → Verify → Validate → Observe → Learn → Govern → Repeat
Any phase can trigger a return to an earlier one based on evidence. The loop is the system. The principles are how you keep it honest.
| If you are | Start with |
|---|---|
| New to agentic engineering | Beyond Agile → The Manifesto → Adoption Playbook |
| A practitioner implementing now | Twelve Principles → Principle Guidance → Patterns → Adoption Path |
| An engineering leader or change owner | Beyond Agile Landscape → Adoption Roles → Metrics |
| In a regulated industry | Domain Overview → your domain document |
- beyond-agile/main.md: The argument for why Agile is insufficient for agentic systems.
- beyond-agile/failures.md: Ten structural failures in values, practices, and conceptual coverage.
- beyond-agile/landscape.md: Critical comparison of competing manifestos, standards, and frameworks.
- beyond-agile/sources.md: Twenty-three cited sources including academic benchmarks (SWE-CI, Feldt et al.), industry frameworks (AWS, P3 Group, ISO 5338), and practitioner perspectives.
- manifesto.md: Core values, scope, Agentic Loop, and reading guide.
- manifesto-principles.md: Twelve principles with minimum bars.
- manifesto-done.md: Agentic Definition of Done (seven criteria plus evolvability) and Definition of Done for Hardening (vibe-to-prod path).
- glossary.md: Canonical definitions for all terms used across the manifesto document set.
- companion/principles.md: Extended guidance and tradeoffs by principle. Includes the Architect–Programmer pattern, evaluation holdout and probabilistic satisfaction, and behavioral vs. structural regression analysis.
- companion/frameworks.md: Maturity spectrum, boundary conditions, and operational definitions.
- companion/patterns.md: Worked patterns and failure patterns.
- companion/re-framework.md: Requirements engineering framework — two-axes classification, behavioral envelopes, and probabilistic assurance targets.
- companion/reference.md: Failure modes and skill requirements.
- adoption/playbook.md: Playbook overview and new way of working.
- adoption/roles.md: Role evolution and human-side transition guidance.
- adoption/path.md: Incremental technical adoption path and phase transitions.
- adoption/vmodel.md: V-model-specific adoption path for regulated and verification-heavy organizations.
- adoption/pilot.md: Resistance management and first pilot execution.
- adoption/metrics.md: Success metrics, quarterly review cadence, and failure modes.
- domains/README.md: Navigation and disclaimers.
- domains/aviation.md: DO-178C, DO-330, DO-333, ARP 4754A.
- domains/medical-devices.md: IEC 62304, ISO 14971, ISO 13485, FDA SaMD.
- domains/pharma.md: GAMP 5, CSA, 21 CFR Part 11, ICH.
- domains/financial-services.md: SR 11-7, DORA, EU AI Act, SOX, Three Lines of Defense.
- domains/automotive.md: ISO 26262, SOTIF, ASPICE.
- domains/defense-government.md: MIL-STD-882, DO-326A, NIST AI RMF.
This is a living document. Contributions are welcome — see CONTRIBUTING.md for guidelines on proposing changes, submitting worked patterns, or reporting issues. See AUTHORS.md for contributors. See LICENSE for terms.