Standard operating procedures for the Sparq AI-Native Software Development Life Cycle. Adapted from the Anthropic AI-Native SDLC pattern, this methodology integrates the Evidence Gate as a non-negotiable gate inside the pipeline rather than treating it as an external meta-process.
The base pipeline optimizes for speed and build correctness. However, it requires a mechanism to validate whether we are building the right thing before scaling execution. Therefore, the Evidence Gate explicitly gates the transition from Intent Framing to Design, closing with the tracker sync and merge that was previously modeled as its own Plan stage, now folded into the Gate as its automatic closing action rather than a separate decision point. The commit chain (Git-tracked artifacts at every stage) remains both the operational workflow and the audit trail.
Pipeline is 7 stages, not 8. Stages 0 and 1 together are sold commercially as one unit, the Evidence Sprint, matching how discovery has traditionally been packaged, just with real signal behind it.
This page is the what and why. The tactical page is the how.
Agentic Delivery Life Cycle. Standard operating procedures for engagements where the deliverable is itself an agentic system, a runtime that reasons non-deterministically, selects tools dynamically, and operates under a probabilistic accuracy distribution rather than a fixed spec. It is the mode this pipeline runs in when the deliverable is agentic, not a second pipeline: the same seven stages, with extra checks at most stages (some of which add to the artifact as well) and a real fork at Design and Test.
The mode question
Is the deliverable's runtime behavior fixed at build time, or decided at runtime?
Asked at Stage 0 · Intent Framing. Recorded at Stage 1 · Evidence Gate, in the cleared intent.md. Not re-argued stage by stage.
A fixed answer keeps the pipeline in its standard mode. A runtime answer puts it in agentic mode (ADLC). 5 of 7 stages keep their shape and take on extra checks, and Build and Deploy add to their artifact as well. Design and Test change in kind, so each carries its own marked block below.
Software delivery runs on a spectrum of how much of the system's behavior is fixed at build time versus decided at runtime. SDLC: everything is deterministic, inputs map predictably to outputs through logic fully specified at compile time. AI-Native SDLC: the deployed system is deterministic, but AI accelerates how we build it. ADLC: nothing at runtime is deterministic, the deliverable reasons, selects tools, and adapts to shifting context live.
ADLC governs the third case. The distinction that matters commercially: a client buying software that uses AI in its construction is a conventional build. A client buying a system that is an agent, one whose actions at runtime are not fully predictable in advance, is buying something that needs its own governance model, because "did we build it right" and "does it behave correctly" are no longer the same question. Evaluations, not test suites, become the primary way we know whether the system is doing its job.
Stages 0 and 1 together are the Evidence Sprint. Stages 2 through 6 are the Production Build. Stage 6 feeds back into Stage 0 via a recursive feedback loop.
| Stage | Core artifact | Gate | In agentic mode |
|---|---|---|---|
| 0 · Intent Framing | raw intent.md | — | Adds checks. Structured elicitation surfacing both business and agentic-failure risk. Gate: Facilitator validates assumption tagging including agentic failure modes. |
| 1 · Evidence Gate | intent.md (cleared, synced) | Product + Delivery sign-off; Promote / Iterate / Pivot / Stop + PO merge | Adds checks. Risk validation loop stress-tested against adversarial input, closing automatically on Promote. Same gate. |
| 2 · Design | spec.md | Skills validation | Forks. Architecture synthesis including an explicit Autonomy Matrix and token budget. Gate: Security and architecture sign-off. Artifact: spec.md + autonomy-matrix.yaml. |
| 3 · Build | plan.md + code diffs | CLAUDE.md + hooks | Adds checks and artifact. Plan-mode drafting with evaluation scenarios built alongside code. Gate: Engineer plan acceptance + evaluation coverage check. Artifact: plan.md + code diffs + initial eval benchmarks. |
| 4 · Test | verification logs + eval results | Eval pass thresholds | Forks. Combined accuracy, safety, and tool-selection threshold. Gate: Combined threshold on accuracy, safety, and tool-selection. |
| 5 · Deploy | REVIEW.md + PR findings | Environment autonomy tiers; branch protection and production deploy hooks | Adds checks and artifact. Tiered autonomy with automatic context-engine correction. Gate: Named human sign-off on Production actions above threshold. Artifact: REVIEW.md + PR findings + release record. |
| 6 · Maintain | bands.yaml + incident records | Metric-band triggers; tiered automated response and on-call approval | Adds checks. Metric-band monitoring extended to token and drift metrics. Gate: Automated triage feed + quarterly governance review. |
Stages are artifact order. They describe the sequence of what you produce and which governance gate you pass through. Risk shapes are the real-time operating picture: they describe which capabilities run hot right now, regardless of which stage the work is in.
A risk shape fires wherever it fires. The Feasibility shape can spike during Intent Framing if an architecture constraint surfaces early. The Value shape can stay active deep into Build if a prior assumption gets challenged. Shapes co-occur, recur, and persist. they are not bound to a single stage.
The stage tells you what artifact you owe. The live risk mix tells you what to worry about while you produce it. You are always in a stage, and you are always responding to risk shapes.
Stages have a default gravity, 0 through 6. but change events and failed gates send you back. The change-response doctrine runs at any stage: re-read the risk, re-set the dials, decision gate, re-staff, re-price and re-time, name the next slice.
These hold across the whole pipeline in either mode. Agentic mode makes them more load-bearing, it does not introduce them.
Every tool, legacy connection, and enterprise platform the agent touches is exposed via Model Context Protocol. This decouples model logic from infrastructure, standardizes authentication, and enforces isolation boundaries.
Agent orchestration logic, instructions, skills, and guardrails live directly in the repository via CLAUDE.md. Project context is maintained dynamically, not through ad-hoc system prompts.
In an AI-native model, writing code is fast, which means running in the wrong direction happens at lightspeed too. Stage 0 is not about solutions or specs. It is about getting brutally honest about what is known versus what is merely guessed, before speed gets applied to the wrong problem.
The artifact: raw intent.md
Kickoff meetings produce polite agreement, everyone nods along while vocabulary gaps and hidden risks sit underneath. intent.md exists to reject that agreement. It captures business goals, affected systems, and constraints as a structured inventory of tagged assumptions, not settled facts.
Stage 0 is not limited to fresh kickoffs. A standard feature request, or even a production incident surfacing back through Stage 6 (Maintain), enters the pipeline through this same gate and gets tagged the same way before anything advances.
Every intent.md, whether written by a human or generated by a background agent, must be reviewed and corrected by the Product Owner before it proceeds.
Ask the one question that sets the rest of the pipeline: is the deliverable's runtime behavior fixed at build time, or decided at runtime? A fixed answer keeps the pipeline in its standard mode. A runtime answer puts it in agentic mode (ADLC), which adds checks at most stages and changes Design and Test.
Agentic mode
Prevent over-engineering by establishing whether an agentic architecture is actually necessary before writing any code. Surface business value, feasibility bounds, and, because the deliverable will reason and act on its own, the specific ways an autonomous system can fail that a conventional build never has to consider.
Extend the failure premortem explicitly to agentic failure modes: compounding tool calls, runaway loops, data leakage through tool access. This is the one place Stage 0 diverges from a conventional build. The question is not just "what if this fails," it is "what if this decides something we did not intend."
Gate: Facilitator validates assumption tagging including agentic failure modes · Adds risk shape: AI reliability
The failure premortem is extended to agentic failure modes (compounding tool calls, runaway loops, data leakage through tool access). The rest of the workshop is the New Discovery doctrine.
Tag every claim explicitly. No untagged assertions survive the file.
Decide whether the raw intent.md is trustworthy enough to compile into spec.md. This is a human-driven evaluation gate to validate risk categories that cannot be caught by CI rubrics. On a Promote, the gate closes automatically: tracker sync, merge, and spec compilation fire without a separate decision.
Run the cycle of Risk → Assumption → Slice → Signal → Confidence → Decision on tagged assumptions. Address one assumption per slice. The validation loop is prototyping: build the smallest thing that tests one assumption, read the signal, decide.
For Value/Usability risks, attach the test to a real occasion (next client conversation, stakeholder review, prospect encounter) rather than manufacturing synthetic scenarios. A slice needs something behaving in the world to react to.
Only use internal convergence checks when a real external occasion genuinely does not exist. Record the reason explicitly. Internal-only signals cap at Directional confidence, never Validated.
Make a clear decision for the intent: Promote, Iterate, Pivot, or Stop. No numeric confidence scores.
Once Promote is decided, immediately execute the dual-linkage: Markdown remains the operational source of truth in the repository, synced to legacy enterprise trackers (Jira/Azure DevOps) via MCP connectors for client governance. This merge triggers a non-interactive CI job that compiles spec.md, loading Sparq compliance skills (security, UX, brand guidelines). The Product Owner performs the final review.
Write the answer to the mode question into the cleared intent.md so Design starts in the right mode. The question is asked once, here, and not re-argued at each later stage.
Agentic mode
Decide whether the intent is trustworthy enough to justify architecture investment before any agent design work begins. For agentic systems this gate carries more weight than in a conventional build, because architecture decisions here (tool access, autonomy scope) are expensive to unwind once made.
Adds risk shape: AI reliability
Build a lightweight slice or a fuller prototype addressing the highest-risk assumption.
Run multi-persona synthetic simulations that deliberately introduce ambiguous, malformed, or malicious inputs, stress-testing not just whether the system works but how it fails when it does not.
Synthesize requirements and architecture into a formal specification.
Execute a compressed, single-session requirements and architecture synthesis.
Guide the synthesis utilizing organization-wide skills for security, compliance, and UX standards.
Building is the primary domain: product-interface-building and core-systems-engineering drive the synthesis. Framing constraint-checks run as secondary, ensuring the architecture stays within the boundaries set at the Evidence Gate.
Agentic modeWhere the modes fork
Design the non-deterministic system architecture itself, not just a technical spec but the boundaries of what the deployed agent will be allowed to decide and do. This is where building an agent most clearly diverges from using one to build: the deliverable's own runtime authority has to be designed on purpose.
Gate: Security and architecture sign-off · Adds risk shape: AI reliability
Compressed design session defining the model stack, context engine structure, prompt topologies, and MCP tool schemas.
Map every task category the deployed agent will perform to an explicit authorization level: Autonomous, Automated with Logging, HITL Approval Required, or Prohibited. This is a strategic decision made once per system, not a detail to leave implicit until Deploy.
Set CAPEX/OPEX budgets as a first-class design constraint alongside functional requirements.
Validate the spec against organizational security, prompt-validation, and output-parsing guardrails before implementation begins.
Draft implementation plans and execute code generation within isolated agent environments.
Maintain a robust context engine detailing build commands, linting rules, architectural patterns, and team-specific mistakes to avoid.
AI agents must draft plan.md before writing code. Human acceptance commits the plan to Git.
Isolate agent sessions across separate Git worktrees. Enforce a parallel session cap of 2–3 concurrent worktree sessions per engineer to preserve review quality and prevent fatigue.
Allow autonomous edit execution only where existing test coverage and build hooks are fully mature.
Utilize .claude/agents/ to store standardized helper agents across repositories, including verifier agents (run the app, check behavior) and simplifier agents (strip redundant complexity post-implementation).
Agentic modeAdds to the artifact
Execute engineering work under Evaluation-Driven Development, treating evaluations as the specification that governs whether the system is behaving correctly, not just whether it compiles.
Gate: Engineer plan acceptance + evaluation coverage check
Draft initial evaluation scenarios in parallel with feature code, not after it, because for a probabilistic system the eval suite is part of the spec, not a downstream check on it.
Evaluate model outputs continuously during implementation for hallucination rate, formatting errors, and tool-calling accuracy, alongside standard build verification.
Continually verify code behavior and assess Feasibility and Operational risks through automated CI suites.
Agents must run builds, tests, and visual diffs, proving success in context before reporting a task complete.
Maintain 20–50 real-world task evaluations in .github/workflows/agent-evals.yml. These run non-interactively upon updates to code, skills, or hooks to establish baseline agent performance benchmarks.
CI evaluations assess Feasibility and Operational risks only. Value and Usability risks are resolved upstream at the Evidence Gate (Stage 1).
Implement pre-tool hooks that block agents from modifying existing test files during bug-fix tasks. The agent must fix the code to pass the tests; it is explicitly denied the ability to alter assertions to force a passing status.
Agentic modeWhere the modes fork
Validate the system across non-deterministic outputs. A probabilistic system can pass every functional test and still fail on tool selection or safety alignment. Those need their own verification, not an assumption that functional correctness implies behavioral correctness.
Gate: Combined threshold on accuracy, safety, and tool-selection
Gate merges on a combined threshold covering task accuracy, safety alignment, and tool-selection accuracy, not task accuracy alone. All three axes must pass independently.
Conduct multi-pass reviews and securely deploy artifacts across environments using defined autonomy tiers.
Automate first-pass scans for logical bugs, security gaps, and compliance against spec.md and plan.md (REVIEW.md).
Enforce deterministic pre-execution scripts for security controls, blocking unauthorized path edits.
Dev/Sandbox: full agent execution allowed. Staging: automated PR review with passing CI required. Production: explicit human release-manager authorization required.
Deploy immutable settings centrally (e.g., allowManagedHooksOnly, permissions.deny) to block shell network egress, prevent credential leakage, and disable plugin sideloading.
Agentic modeAdds to the artifact
Transition a probabilistic system into staging and production safely, using tiered autonomy and multi-pass safety verification rather than a single go/no-go review.
Gate: Named human sign-off on Production actions above threshold
Deploy through managed autonomy tiers: full autonomy in Development, automated review plus clean CI in Staging, and explicit named human sign-off in Production for any action above the defined risk threshold.
Feed corrections back automatically: when the same mistake recurs across reviews, the context engine is updated so it does not recur a third time.
Monitor system health continuously and trigger automated triage and incident resolution loops.
Apply deterministic monitoring using statistical control rules against operational metrics (e.g., test failure rate, post-deploy 5xx rates) via bands.yaml.
If a metric breach occurs (e.g., 3σ deviation), a background agent automatically diagnoses the root cause and writes a new intent.md into the triage queue.
Triage live production alerts via Claude Tag in Slack/Teams, execute diagnostic runbooks via MCP, and log root-cause analyses directly to the thread record.
For every resolved production incident, automatically compile a regression evaluation case into the CI suite (Stage 4) to guarantee prevention of recurrence.
Agentic modeMaintain & Governance
Manage probabilistic drift over time: monitor token consumption, capture real-world edge cases the system encounters in production, and feed incidents back into intent triage automatically rather than waiting for the next planning cycle.
Gate: Automated triage feed + quarterly governance review
Monitor performance using statistical process control against defined bands, extended for agentic systems to include token consumption trends and hallucination/drift rates alongside infrastructure and product metrics.
On a detected anomaly (a hallucination, an autonomy-boundary breach, a negative feedback loop) a background process diagnoses the incident, compiles a permanent regression case, and raises a new intent item automatically.
Review governance quarterly against accumulated incident and drift data.
Only what is new once the deliverable reasons and acts on its own. The stage-level changes sit on each stage above.
Unconstrained agent autonomy compounds errors. Default to deterministic Workflows (Prompt Chaining, Routing, Parallelization, Orchestrator-Workers); escalate to fully autonomous Agents only when dynamic reasoning across an open-ended tool space is genuinely required.
Evaluations replace unit tests as the core specification artifact. Prompts and orchestrators are software components whose behavior is verified against 20-50+ task scenarios before production deployment.
| Dimension | Conventional | Agentic mode (ADLC) |
|---|---|---|
| Behavioral model | Deterministic execution (input maps predictably to output) | Probabilistic execution (input, reasoning, one of several possible outputs) |
| Logic residency | Code and config alone | Code, system prompts, foundation models, and vector stores together |
| Primary artifact | Code, tests, documentation | Agent specs, evaluation suites, MCP tool definitions, CLAUDE.md context engine |
| Quality verification | Pass/fail unit tests and code coverage | Evaluation suites, alignment tests, and tool-call accuracy |
| Success metrics | Code coverage and functional pass/fail | Accuracy distributions, hallucination rates, and token economics |
| Feedback loop | Reactive (users report bugs, devs fix them) | Recursive (runtime telemetry feeds evaluations and re-opens intent triage automatically) |
In agentic mode the Evidence Sprint also covers agent-specific scope framing, architecture definition, and simulation before committing to a full build.
| Constraint | How ADLC addresses it |
|---|---|
| Commercial risk | A fixed-fee Evidence Sprint (Stages 0-1) with an explicit Evidence Gate caps unbounded R&D spend before architecture work begins. |
| Legacy systems | Monolithic and tech-debt codebases are wrapped behind strict MCP boundaries and path-blocking guardrails to prevent unauthorized refactoring. |
| Severe unknowns | Greenfield exploration is constrained via Plan Mode First and synthetic dry-run simulation before production tokens are spent. |
| SLA realities | Bounded accuracy distributions replace binary SLAs; post-launch maintenance becomes an ongoing governance retainer tracking drift, not just uptime. |
| Token economics | CAPEX/OPEX budgets are set at Design and tracked through Maintain. Ongoing inference cost is a first-class constraint, not an afterthought. |
Each stage has a primary domain driving the work and risk shapes that are typically hottest at that point. Framing tapers over time but does not hard-stop at the Evidence Gate. Proof runs at the Gate, Test, and Maintain stages, handling distinct but related evaluation tasks.
| Stage | Primary domain | Secondary | Risk shapes typically hot | Added in agentic mode |
|---|---|---|---|---|
| 0 · Intent Framing | Framing | — | Problem clarity, Commercial / viability | AI reliability |
| 1 · Evidence Gate | Proof | Framing | Value, Problem clarity | AI reliability |
| 2 · Design | Building | Framing | Feasibility | AI reliability |
| 3 · Build | Building | Proof | Feasibility, AI reliability | — |
| 4 · Test | Proof | Building | Proof / acceptance, Feasibility, AI reliability | — |
| 5 · Deploy | Building | Continuity | Proof / acceptance, Adoption | — |
| 6 · Maintain | Continuity | Enablement | Continuity / operational, Adoption | — |
Risk shapes are listed where they are typically hottest, not where they only fire. Any shape can spike at any stage.
Commercial Commercial frames the pipeline: it sets the envelope and price before Stage 0, and the proof → commercial seam updates it as evidence arrives. It is not absent from the pipeline; it operates across stages rather than owning one.
Enablement Enablement activates when the Adoption risk shape fires, typically hottest at Deploy and Maintain but possible at any stage where organizational change is needed to land the work.
In agentic mode, Commercial Commercial frames the pipeline: a fixed-fee Evidence Sprint caps unbounded R&D spend, and token economics are tracked as a first-class constraint from Design through Maintain.
In agentic mode, Enablement Enablement activates at Deployment and Governance, where HITL operators manage autonomy tiers and the system transitions to ongoing governance.
Maintenance metrics primarily monitor infrastructure health (error rates). A sensor is needed to monitor Value/Usability drift post-launch (adoption rates, usage depth) so the pipeline does not lose signal on a shipped feature nobody wants. This remains an unresolved gap; the tactical playbook includes a candidate widened bands.yaml design as a proposal, not yet ratified.
The Stage 0 session itself is deliberately left undressed. Naming it before the shape is settled through repeated real use is an anti-pattern. We will call it what it is until it earns a name through institutional habit. This is separate from Evidence Sprint, which names the combined Stage 0 + Stage 1 commercial unit, not the Stage 0 session on its own.
How much of the Intent Framing Session includes the client versus internal Sparq preparation is inherently variable by design, not a gap to standardize away. Some engagements run heavy client involvement, others very little; headcount in the room has ranged from as few as 2 to as many as 20. This is engagement-specific and should stay that way.
In agentic mode
The matrix is currently defined per project at Design. Whether a baseline matrix template should exist for common agent categories (chat interface, workflow automation, autonomous research) is unresolved.
CAPEX/OPEX budgets are currently set per engagement without a portfolio-level baseline to compare against. This should mature as more engagements accumulate data.
The widened performance-band design that includes token and drift metrics is proposed, not yet ratified in production.