Skip to content
/

Twelve-Factor Agentic SDLC

agentic-sdlc-12-factors · tikalk/agentic-sdlc-12-factors · ★ 29 · last commit 2026-01-11

Primitive shape
No installable primitives
00

Summary

Twelve-Factor Agentic SDLC — Summary

The Twelve-Factor Agentic SDLC is a methodology manifesto (not an installable framework) published by Tikal (tikalk) at https://twelve-factor-agentic.org. It defines 12 factors across 4 pillars (Strategy, Workflow, Governance, Team Capability) for integrating AI coding agents into team software development. The 12 factors are: I. Strategic Mindset, II. Context Scaffolding, III. Mission Definition, IV. Structured Planning, V. Dual Execution Loops, VI. The Great Filter, VII. Adaptive Quality Gates, VIII. AI-Augmented Risk-Based Testing, IX. Traceability, X. Strategic Tooling, XI. Directives as Code, XII. Team Capability. The project is a Jekyll/HTML documentation website with content in markdown; the .mcp.json file suggests MCP tooling awareness but is an example configuration, not a bundled server. 29 stars, 2 contributors, last pushed January 2026.

differs_from_seeds: Pure methodology-doc archetype with no installable components — closest to agent-os (seed, Archetype 4 "Markdown scaffold, zero primitives") but more abstract. Where agent-os ships 5 bash commands that write markdown scaffolding, Twelve-Factor ships zero commands; it's a pure textual framework. The "Mission Definition" factor (Factor III: generate spec.md from issue tracker Mission Brief) directly mirrors the kiro/openspec spec-first pattern. The "Dual Execution Loops" factor (SYNC vs ASYNC) is an original taxonomy not present in any seed.

01

Overview

Twelve-Factor Agentic SDLC — Overview

Origin

Created by Tikal (tikalk), an Israeli software consultancy. Published at https://tikalk.github.io/agentic-sdlc-12-factors/ (canonical URL: twelve-factor-agentic.org). HTML/Jekyll documentation site. Licensed under Creative Commons Attribution ShareAlike 4.0. 29 stars, 2 contributors, last pushed January 2026.

Manifesto Statement

The manifesto opens with a failure-mode analysis:

"The Agentic SDLC was born from a critical observation: while individual developers are experiencing personal productivity gains with AI tools, engineering teams are failing to translate these wins into a collective increase in velocity. Ad-hoc prompting and inconsistent workflows, or 'Vibe Coding,' often lead to systemic problems."

Four primary failure modes of unstructured AI adoption:

  1. Inconsistent Team Output
  2. Organizational Knowledge Gap (siloed prompting expertise)
  3. Unpredictable Team Velocity
  4. Code Ownership Erosion

The Twelve Factors

Pillar I — Strategy:

  • I. Strategic Mindset: "Developer as Orchestrator, AI as Intern" — "Debug the spec, not the code."
  • II. Context Scaffolding: Treat context (code, docs, team standards) as a critical dependency

Pillar II — Workflow:

  • III. Mission Definition: Every task starts as a Mission Brief in the issue tracker → generates spec.md
  • IV. Structured Planning: AI generates plan.md from spec.md; developer triages SYNC vs ASYNC tasks
  • V. Dual Execution Loops: Synchronous (complex, interactive) vs Asynchronous (well-defined, delegated)

Pillar III — Governance:

  • VI. The Great Filter: Human is ultimate arbiter; accountability not transferable
  • VII. Adaptive Quality Gates: Micro-Reviews (SYNC work) vs Macro-Reviews (ASYNC/PR review)
  • VIII. AI-Augmented Risk-Based Testing: Developer defines risks; AI generates targeted tests
  • IX. Traceability: Automated link from issue tracker (why) to spec.md + code (how)
  • X. Strategic Tooling: Central gateway for tool management (cost, security, model choice)

Pillar IV — Team Capability:

  • XI. Directives as Code: Natural language instructions as version-controlled assets (CLAUDE.md, AGENTS.md)
  • XII. Team Capability: Formalize best-practice sharing; versioned Evals suite for performance measurement

Connection to Twelve-Factor App

Named after the well-known Heroku "Twelve-Factor App" methodology (12factor.net). The parallel is intentional — the same discipline applied to team-level AI development rather than cloud application architecture.

02

Architecture

Twelve-Factor Agentic SDLC — Architecture

Distribution

  • Type: methodology-doc (documentation website)
  • Install: None — read the website at https://tikalk.github.io/agentic-sdlc-12-factors/
  • Runtime: None required
  • License: Creative Commons Attribution ShareAlike 4.0

Repository Structure

agentic-sdlc-12-factors/
├── content/                # Factor content files (markdown)
│   ├── strategic-mindset.md
│   ├── context-scaffolding.md
│   ├── mission-definition.md
│   ├── structured-planning.md
│   ├── dual-execution-loops.md
│   ├── great-filter.md
│   ├── adaptive-quality-gates.md
│   ├── ai-augmented-testing.md
│   ├── traceability.md
│   ├── strategic-tooling.md
│   ├── directives-as-code.md
│   └── team-capability.md
├── manifesto.md             # Full methodology manifesto
├── index.md                 # Site home
├── _i18n/                   # Internationalization
├── _layouts/                # Jekyll layouts
├── _config.yml              # Jekyll config
├── .mcp.json                # Example MCP server config (context only)
├── Taskfile.yaml            # Build tasks
├── Gemfile                  # Jekyll dependency
└── docs/                    # Additional documentation

.mcp.json — Example Configuration

The .mcp.json in the repo is a documentation artifact showing how teams should configure MCP tools for their agents, not a bundled server:

{
  "servers": {
    "github": { ... },
    "filesystem": { ... }
  }
}

No Installable Components

Zero commands, zero skills, zero hooks, zero scripts, zero CLI binaries. This is a pure content methodology, not an installable framework.

Format

Each factor is a checklist-style markdown page with:

  • Factor title and tag line
  • Checklist items ([ ] checkboxes)
  • Link to previous/next factor

Content follows the same structure as 12factor.net factor pages.

03

Components

Twelve-Factor Agentic SDLC — Components

Content Pages (12 Factor Files)

Factor File Category
I. Strategic Mindset content/strategic-mindset.md Strategy
II. Context Scaffolding content/context-scaffolding.md Strategy
III. Mission Definition content/mission-definition.md Workflow
IV. Structured Planning content/structured-planning.md Workflow
V. Dual Execution Loops content/dual-execution-loops.md Workflow
VI. The Great Filter content/great-filter.md Governance
VII. Adaptive Quality Gates content/adaptive-quality-gates.md Governance
VIII. AI-Augmented Risk-Based Testing content/ai-augmented-testing.md Governance
IX. Traceability content/traceability.md Governance
X. Strategic Tooling content/strategic-tooling.md Governance
XI. Directives as Code content/directives-as-code.md Team Capability
XII. Team Capability content/team-capability.md Team Capability

Manifesto

manifesto.md — full methodology description, ~4,000 words covering background, failure modes, all 12 factors, and the relationship to the original Twelve-Factor App and Agile Manifesto.

Example MCP Configuration

.mcp.json — example JSON showing GitHub MCP, filesystem MCP, and memory MCP configuration for agent tooling. Documentation only.

No Active Components

  • Commands: 0
  • Skills: 0
  • Hooks: 0
  • Scripts: 0
  • CLI: none
  • MCP servers: 0 (example config only)
05

Prompts

Twelve-Factor Agentic SDLC — Prompts

Excerpt 1 — Factor I: Strategic Mindset Checklist

From content/strategic-mindset.md:

# I. Strategic Mindset: Developer as Orchestrator, AI as Intern

*The foundation of the Agentic SDLC is a strategic mindset shift. Treat the AI as a fast,
knowledgeable junior partner that requires clear direction, mentorship, and rigorous review.
Your role is elevated from writing code to orchestrating solutions.*

- [ ] **Adopt the Mantra:** Your primary focus becomes "Debug the spec, not the code." 
      If the AI generates incorrect code, the first step is to refine the specification or 
      the context provided, not just to fix the output.
- [ ] **Mentor the Intern:** When the AI makes a mistake, correct it by providing clear 
      feedback and better examples, similar to how you would guide a junior developer.
- [ ] **Own the Outcome:** You are the orchestrator. The AI is a tool, and you are ultimately 
      responsible for the quality, security, and architectural cohesion of the final product.

Prompting technique: Not a prompt to an AI — this is a checklist for a human developer's mental model. The "Developer as Orchestrator, AI as Intern" frame is a reframing technique for human cognition, not a system prompt. The [ ] checkbox format makes it actionable rather than abstract.

Excerpt 2 — Manifesto Failure Mode Analysis

From manifesto.md:

The Agentic SDLC was born from a critical observation: while individual developers are 
experiencing personal productivity gains with AI tools, engineering teams are failing to 
translate these wins into a collective increase in velocity. Ad-hoc prompting and 
inconsistent workflows, or "Vibe Coding," often lead to systemic problems.

**Inconsistent Team Output:** Different prompting styles and a lack of shared standards 
lead to a chaotic codebase and unpredictable quality. One developer's shortcut becomes 
the entire team's technical debt.

**Organizational Knowledge Gap:** Critical knowledge about prompts, patterns, and 
architectural standards remains siloed with individuals. The team's collective intelligence 
never improves, leading to duplicated work and repeated mistakes.

Prompting technique: Framing-by-negation — the methodology is defined through what goes wrong without it. This is a persuasion pattern (problem → solution) applied to methodology documentation.

Excerpt 3 — Factor III: Mission Definition Procedure

From content/mission-definition.md:

- [ ] **Start with the Mission Brief:** The process begins when you are assigned a task 
      in the issue tracker that contains a Mission Brief (Goal, Constraints, Success Criteria).
- [ ] **Generate the Specification (spec.md):** Your first action is to use the platform's 
      CLI (e.g., /specify) to generate a detailed, version-controlled spec.md file 
      from the Mission Brief.
- [ ] **Link the Artifacts:** Commit the newly created spec.md to the feature branch and 
      post a link to it back in the issue tracker, ensuring traceability from intent 
      to specification.

Prompting technique: Prescriptive checklist with numbered ordering and conditional inputs. The "Mission Brief" → spec.md artifact chain is presented as a manufacturing process — each step produces a versioned artifact that feeds the next.

09

Uniqueness

Twelve-Factor Agentic SDLC — Uniqueness & Positioning

differs_from_seeds

Pure methodology-doc archetype — no installable primitives. Closest to agent-os (seed, Archetype 4 "Markdown scaffold, zero primitives") but more abstract: agent-os ships 5 bash commands that create markdown scaffolding; Twelve-Factor ships only prose. The "Mission Definition → spec.md" pattern mirrors kiro's spec-first approach (Factor III explicitly prescribes a spec.md in the repo). The "SYNC/ASYNC Dual Execution Loops" taxonomy is an original contribution not found in any seed framework — it operationalizes the decision of when to pair-program with AI vs delegate to autonomous agent. Factor XII (Evals) addresses organizational learning in a way no seed framework does.

Key Positioning

  • The only framework in the corpus framed for teams rather than individual developers — addresses coordination failures, knowledge silos, and institutional learning.
  • The SYNC/ASYNC taxonomy is the framework's most actionable original concept: a decision-making heuristic for "when to watch the AI vs let it run."
  • Published under CC-BY-SA 4.0 by a consultancy (Tikal), suggesting it's designed to be adopted and customized by teams.

Observable Failure Modes

  1. No implementation: The methodology prescribes spec.md, plan.md, Evals — but provides no templates, commands, or tools to create them. Teams must build their own tooling.
  2. SYNC/ASYNC boundary is ambiguous: The framework doesn't provide clear criteria for task triage beyond "complex vs well-defined" — teams will interpret this differently.
  3. Assumes issue tracker integration: Factor IX (Traceability) requires linking specs to issues — if a team uses a different process (Notion, Linear, Confluence), the traceability chain breaks.
  4. No enforcement mechanism: The 12 factors are checklists with checkboxes, not automated gates. A team that ignores them has no system-level consequence.
  5. Low stars + 2 contributors: 29 stars, consultancy origin — may not have broad adoption outside Tikal's client base.
04

Workflow

Twelve-Factor Agentic SDLC — Workflow

Prescribed Workflow (Factor III-V)

The methodology prescribes this workflow:

Step Activity Artifact Factor
1 Create Mission Brief in issue tracker Issue with Goal, Constraints, Success Criteria III
2 Generate spec from Mission Brief via CLI spec.md (version-controlled) III
3 Link spec.md to originating issue Issue comment with spec.md link III (Traceability)
4 AI generates implementation plan from spec.md plan.md IV
5 Developer triages plan tasks SYNC list + ASYNC list IV
6a SYNC tasks: real-time pair programming in IDE Code changes V
6b ASYNC tasks: agent executes independently Pull Request V
7 SYNC: Micro-Reviews (continuous in-session) Reviewed code VII
7 ASYNC: Macro-Reviews (PR review) Approved PR VII
8 Merge and retrospective Retrospective notes VIII, XII

Dual Execution Loops (Factor V)

The SYNC/ASYNC taxonomy is the methodology's most distinctive contribution:

SYNC (Synchronous Collaboration):

  • Complex, ambiguous, interactive problems
  • Developer stays in the loop
  • Real-time feedback and correction
  • Example: designing a novel algorithm, debugging a subtle race condition

ASYNC (Asynchronous Delegation):

  • Well-defined, mechanical, high-effort tasks
  • Agent executes independently
  • Delivers a Pull Request
  • Example: adding test coverage for a fully-specified API, migrating deprecated library calls

Quality Gate Model (Factor VII)

Micro-Reviews (for SYNC work):

  • Continuous: review each code change as it's created
  • Low ceremony: in-session feedback

Macro-Reviews (for ASYNC work):

  • Formal: structured Pull Request + CI pipeline
  • High ceremony: independent review before merging

Approval Gates

Factor III mandates: "You are ultimately responsible for the quality, security, and architectural cohesion of the final product." All approval gates are human-executed — the methodology prescribes human judgment at every merge.

06

Memory Context

Twelve-Factor Agentic SDLC — Memory & Context

Factor II — Context Scaffolding

The methodology's core memory prescription:

"Manage all context — code, documentation, and team standards — with the same rigor as a critical software library."

Prescribed context artifacts:

  • CLAUDE.md / AGENTS.md / .github/copilot-instructions.md — agent context files (Factor XI "Directives as Code")
  • Versioned prompts and rules in the repository alongside code
  • Team standards maintained as evolving documents

Factor IX — Traceability

The methodology mandates a persistent audit trail:

  • Issue tracker (GitHub Issues) → spec.md (reason why)
  • spec.md → feature branch → code (how)
  • Pull Request links back to issue

This creates a bi-directional paper trail that persists beyond any single session.

Factor XI — Directives as Code

Natural language instructions (CLAUDE.md, prompt templates, rules) treated as version-controlled source code artifacts:

  • Stored in the repository
  • Updated via PRs with review
  • Versioned alongside feature changes
  • Shared across the team (not siloed with individuals)

No Active Memory System

The methodology doesn't prescribe any database, vector store, or active memory server. All "memory" is in version-controlled files.

Factor XII — Evals as Institutional Memory

The methodology prescribes "versioned Evals" — a test suite for measuring AI output quality — as the mechanism for capturing institutional learning. Poor prompting patterns identified in retrospectives → codified in evals → prevents future recurrence.

07

Orchestration

Twelve-Factor Agentic SDLC — Orchestration

Multi-Agent Pattern

The methodology acknowledges multi-agent scenarios (Factor III and IV reference "team of agents"):

"As the model matures, agentic teams of orchestrators and sub-agents take on broader coordination, with humans focusing on definition, review, and strategic direction."

However, no concrete multi-agent infrastructure is prescribed. The methodology is tool-agnostic — it describes principles, not implementation.

Dual Execution Pattern

The methodology's unique contribution is the SYNC/ASYNC execution taxonomy:

  • SYNC: Human-in-the-loop; IDE-based interactive collaboration; Micro-Reviews
  • ASYNC: Delegated to agent; delivers PR; Macro-Reviews (PR + CI)

This maps loosely to sequential (SYNC) and task-decomposition-tree (ASYNC) orchestration patterns, but without specifying a tool.

Isolation

The methodology recommends feature branches per story (implied by the PR-based ASYNC workflow) but doesn't prescribe worktrees, containers, or specific isolation mechanisms.

Consensus

No formal consensus mechanism. "The human developer is the ultimate arbiter" (Factor VI — The Great Filter).

Execution Mode

interactive-loop — human drives both SYNC and ASYNC invocations. No autonomous daemon.

Multi-Model

The methodology prescribes "Strategic Tooling" (Factor X) with a "central gateway" for model management, implying multi-model routing awareness, but doesn't specify a concrete tool or model assignment pattern.

08

Ui Cli Surface

Twelve-Factor Agentic SDLC — UI / CLI Surface

CLI Binary

None — the methodology is a documentation framework.

Factor III references "the platform's CLI (e.g., /specify)" as an example but doesn't ship one.

Website

The methodology has a Jekyll documentation site:

  • URL: https://tikalk.github.io/agentic-sdlc-12-factors/ (canonical: twelve-factor-agentic.org)
  • Format: Factor-by-factor checklist pages
  • Mobile-friendly reading format

IDE Integration

None — the methodology is tool-agnostic. Factor XI (Directives as Code) implies CLAUDE.md/AGENTS.md files in the repo but doesn't prescribe specific IDE hooks.

Observability

Factor IX (Traceability) is the observability prescription:

  • Issue tracker as audit log (why decisions were made)
  • spec.md as specification audit trail
  • PRs as change audit trail

No structured JSONL log, no dashboard.

Cross-Tool Portability

High — the methodology is tool-agnostic. Factor XI (Directives as Code) mentions CLAUDE.md, AGENTS.md, and .github/copilot-instructions.md as examples of directives for different AI tools.

Related frameworks

same archetype · same primary tool · same memory type

Context-Engineering Handbook ★ 9.0k

Provides a first-principles, research-grounded vocabulary and learning path for context engineering — the discipline of designing…

walkinglabs/learn-harness-engineering ★ 6.6k

Teach harness engineering from first principles (12 lectures + 6 projects) and provide a scaffolding skill (harness-creator) that…

Awesome Harness Engineering (walkinglabs) ★ 2.7k

Curate the authoritative reference list of articles, benchmarks, and tools for harness engineering — the practice of shaping the…

cline-memory-bank (nickbaumann98) ★ 581

Custom instructions + 6-file hierarchical Markdown memory bank so Cline maintains full project context across sessions, with a…

FPF (First Principles Framework) ★ 372

Provides a formal pattern language for making reasoning explicit, traceable, and publishable in mixed human/AI engineering work —…

nexu-io/harness-engineering-guide ★ 134

Provide a practical, code-first reference guide to harness engineering — from first principles to production patterns —…