# 747 Sam Vs V Model Aee07411 > Stateless Agent Methodology vs SDLC V-Model - Skill: `tools-only/747-sam-vs-v-model-aee07411` (Agent Skill, multi-file: 3 files) - Install (CLI): `npx skillmds@latest add tools-only/747-sam-vs-v-model-aee07411` - Raw SKILL.md: https://api.skillmd.com/api/skills/tools-only/747-sam-vs-v-model-aee07411/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: tools-only (https://skillmd.com/u/tools-only) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/tools-only/747-sam-vs-v-model-aee07411 --- # Stateless Agent Methodology vs SDLC V-Model A comparative analysis of a modern LLM agent workflow methodology against the classic software development lifecycle model. --- ## Executive Summary The V-Model is a traditional human-centric software development process that pairs design phases with corresponding validation phases. The Stateless Agent Methodology adapts similar structural principles for LLM agent workflows, addressing the unique constraints of AI systems. | Aspect | V-Model (SDLC) | Stateless Agent Methodology | | ------------------- | ------------------------------------------- | --------------------------------------------------------------- | | **Era** | 1980s-present | 2024-present | | **Actors** | Human developers and testers | LLM agents | | **Primary Problem** | Ensuring quality through structured testing | Agent self-assessment failure | | **Core Structure** | Definition phases ↔ Validation phases | Generation phases ↔ Verification phases | | **State Model** | Stateful (knowledge accumulates in humans) | Stateless sessions + persistent artifacts (externalized memory) | --- ## The V-Model Structure The V-Model visualizes software development as a V-shape, where: - **Left side (descending)**: Definition/design phases - **Bottom**: Implementation/coding - **Right side (ascending)**: Validation/testing phases ``` Requirements Analysis ─────────────────────────── User Acceptance Testing │ │ ▼ ▲ System Design ───────────────────────────── System Testing │ │ ▼ ▲ Architecture Design ─────────────────────── Integration Testing │ │ ▼ ▲ Module Design ─────────────────────────── Unit Testing │ │ ▼ ▲ └────────────► CODING ◄──────────────────┘ ``` **Key principle**: Each definition phase on the left has a corresponding validation phase on the right. Test plans are created during definition and executed during validation. --- ## The Stateless Agent Methodology Structure The Stateless Agent Methodology structures work as linear stages with embedded verification: ``` Discovery → Planning (RT-ICA) → Context Integration → Task Decomposition → Execution → Forensic Review → Orchestration Loop → Final Verification ``` Each stage: - Receives complete context as input - Produces artifacts for the next stage - Cannot rely on agent "memory" between stages --- ## Structural Mapping ### V-Model Phases → Stateless Phases | V-Model (Definition) | Stateless Equivalent | V-Model (Validation) | Stateless Equivalent | | --------------------- | -------------------- | ----------------------- | --------------------------- | | Requirements Analysis | Stage 1: Discovery | User Acceptance Testing | Stage 8: Final Verification | | System Design | Stage 2: Planning | System Testing | Stage 6: Forensic Review | | Architecture Design | Stage 3: Integration | Integration Testing | Stage 7: Orchestration Loop | | Module Design | Stage 4: Decompose | Unit Testing | Stage 5: Execution (self) | | Coding | Stage 5: Execution | — | — | ### Visual Comparison **V-Model (V-shape)**: ``` Definition Validation ────────── ────────── Requirements ────────────────────────────────── UAT │ ▲ ▼ │ System ─────────────────────────────────── System │ ▲ ▼ │ Architecture ──────────────────────────── Integration │ ▲ ▼ │ Module ────────────────────────────────── Unit │ ▲ └──────────► CODE ◄────────────────────┘ ``` **Stateless Agent Methodology (Linear)**: ``` ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ Discover │──►│ Plan │──►│ Integrate│──►│ Decompose│ └──────────┘ └──────────┘ └──────────┘ └──────────┘ │ ┌─────────────────────────────────────────────┘ ▼ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ Execute │──►│ Forensic │◀──┘ (loop) └───►│ Verify │ └──────────┘ └──────────┘ └──────────┘ ``` --- ## Core Philosophy Comparison ### V-Model Philosophy **"Test early, test often"**: - Test plans created during definition phases - Each level of design has corresponding test level - Testing validates that implementation matches specification - Traceability from requirements → tests → code **Assumptions**: - Human developers retain context throughout project - Documentation serves as communication medium - Testing catches defects post-implementation - Linear progression is acceptable for stable requirements ### Stateless Agent Methodology Philosophy **"Claude is not a knowledge worker—Claude is a stateless computation engine"**: - Complete context must be provided at each stage - Treat Claude like a pure function: task file (complete context) → agent → verified result - Verification must be independent from generation - Artifacts are the only reliable bridge between stages - Bounded context reduces long-context degradation pressure; deterministic backpressure (tests/lints/etc.) is still required to converge on correctness **Assumptions**: - LLM agents lose context between sessions - Agents optimize for apparent completion over correct completion - Training data may be outdated or irrelevant - Each stage needs complete, explicit context --- ## Definition/Generation Phase Comparison ### Requirements Analysis vs Discovery | Aspect | V-Model | Stateless | | ----------------- | ------------------------------- | ------------------------------------- | | **Input** | User interviews, business needs | User discussion following framework | | **Actor** | Business analysts | Discovery agent | | **Output** | User requirements document | Feature requirements guide, NFR guide | | **Test artifact** | UAT test plans | Acceptance criteria | | **State** | Analysts remember context | Agent receives fresh context | ### System Design vs Planning (RT-ICA) | Aspect | V-Model | Stateless | | ----------------- | ------------------------------- | --------------------------------------- | | **Input** | User requirements document | Gathered data + verification framework | | **Actor** | System engineers | Planning agent (RT-ICA) | | **Output** | Software specification document | Feature design guide with prerequisites | | **Test artifact** | System test plans | Prerequisite checklist | | **Purpose** | Determine how to implement | Verify readiness to implement | ### Architecture Design vs Integration | Aspect | V-Model | Stateless | | ----------------- | ----------------------------------- | ---------------------------------- | | **Input** | Software specification | Design guide + existing codebase | | **Actor** | Architects | Integration agent | | **Output** | Architecture diagrams, tech details | Contextualized implementation plan | | **Test artifact** | Integration test design | File/URL references | | **Purpose** | Define system structure | Ground plan in existing reality | ### Module Design vs Task Generation | Aspect | V-Model | Stateless | | ----------------- | ---------------------------- | ------------------------------ | | **Input** | Architecture design | Integrated plan | | **Actor** | Designers | Task Decomposition agent | | **Output** | Low-level design, pseudocode | Task files with constraints | | **Test artifact** | Unit test design | Per-task verification criteria | | **Purpose** | Enable programmer to code | Enable agent to execute | --- ## Validation/Verification Phase Comparison ### Unit Testing vs Execution Self-Verification | Aspect | V-Model | Stateless | | ------------- | --------------------------- | -------------------------- | | **Validates** | Individual modules | Individual task completion | | **Actor** | Developers/testers | Execution agent | | **Against** | Module design specification | Task file constraints | | **Scope** | Smallest testable unit | Single task | ### Integration Testing vs Orchestration Review | Aspect | V-Model | Stateless | | ------------- | -------------------------- | -------------------------- | | **Validates** | Module interactions | Task dependency completion | | **Actor** | Integration testers | Orchestrator | | **Against** | Architecture design | Task dependency graph | | **Scope** | Inter-module communication | Cross-task coherence | ### System Testing vs Forensics | Aspect | V-Model | Stateless | | ------------- | ------------------------------------------ | --------------------------- | | **Validates** | Whole application | Completed work against plan | | **Actor** | QA team | Forensic agent | | **Against** | System design specification | Implementation plan | | **Scope** | Functional and non-functional requirements | Task completion status | ### User Acceptance Testing vs Verification | Aspect | V-Model | Stateless | | ------------- | ----------------------- | ---------------------------------- | | **Validates** | System meets user needs | Feature meets goal | | **Actor** | Business users | Verification agent | | **Against** | User requirements | Original goal, acceptance criteria | | **Scope** | Real-world usage | Definition of done | --- ## Key Differences ### 1. State Management **V-Model**: Assumes stateful actors - Humans retain context throughout project - Documentation supplements memory - Team knowledge accumulates over time **Stateless**: Assumes stateless actors - Agents cannot retain context between sessions - Artifacts must contain complete context - Each phase starts fresh ### 2. Verification Timing **V-Model**: Verification after implementation - Test plans created early - Tests executed after coding - Defects found post-implementation **Stateless**: Verification throughout - Assessment blocks planning until prerequisites verified - Forensics validates each task - Verification confirms feature completion ### 3. Feedback Loops **V-Model**: Limited feedback - Linear progression left-to-right - Changes require going back up the V - Criticism: "inflexible and encourages rigid view" **Stateless**: Continuous feedback - Orchestrator creates follow-up tasks - Incomplete work triggers new tasks - Verification can restart cycle ### 4. Actor Model **V-Model**: Role-based human teams - Business analysts, architects, developers, testers - Each role has domain expertise - Coordination through meetings and documents **Stateless**: Phase-based agent separation - Different agents for different phases - Separation prevents self-assessment bias - Coordination through artifacts only --- ## Shared Principles Despite different contexts, both methodologies share core principles: | Principle | V-Model Expression | Stateless Expression | | ----------------------------------- | -------------------------------- | ---------------------------------------- | | **Verification mirrors definition** | Each design phase has test phase | Each generation phase has verification | | **Early test planning** | Test plans created during design | Acceptance criteria defined in discovery | | **Traceability** | Requirements → Tests → Code | Goals → Tasks → Verification | | **Separation of concerns** | Different roles for design/test | Different agents for generate/verify | | **Specification-driven** | Code implements specification | Agent follows task file | --- ## V-Model Criticisms and Stateless Solutions The V-Model has been criticized for several issues. The Stateless Agent Methodology addresses some of these: ### Criticism: "Too simple, false sense of security" **V-Model problem**: Managers think following the V guarantees quality. **Stateless solution**: Explicit acknowledgment that agents fail predictably. Verification is not assumed—it's enforced through independent forensic phase. ### Criticism: "Inflexible, no ability to respond to change" **V-Model problem**: Linear progression doesn't handle requirement changes well. **Stateless solution**: Orchestrator can create new tasks based on forensic findings. Assessment can block if prerequisites change. Verification can restart discovery. ### Criticism: "Testing squeezed into tight windows" **V-Model problem**: When early phases overrun, testing gets compressed. **Stateless solution**: Each phase is independent with complete context. No phase "inherits" time pressure from previous phases. Fresh context per phase. ### Criticism: "Encourages rigid link between definition and validation levels" **V-Model problem**: UAT must derive from requirements document. **Stateless solution**: Forensics validates against plan. Verification validates against goal. Orchestrator can add intermediate validation as needed. ### Criticism: "Promotes writing test scripts in advance rather than exploratory testing" **V-Model problem**: Pre-written tests miss unexpected issues. **Stateless solution**: Forensic agent validates independently—not following pre-written scripts. Can report issues not anticipated in task file. --- ## Adaptation Opportunities ### V-Model Concepts Applicable to Stateless | V-Model Concept | Stateless Adaptation | | -------------------------- | --------------------------- | | Test traceability matrices | Task → Verification mapping | | Defect classification | Failure mode categorization | | Test coverage metrics | Phase completion tracking | | Sign-off gates | Phase boundary approvals | ### Stateless Concepts That Could Improve V-Model | Stateless Concept | V-Model Adaptation | | -------------------------- | -------------------------------------------------------- | | Complete context per phase | Comprehensive handoff documents | | Independent verification | Separate test teams with no design context | | Fresh context benefits | Test team reads only specification, not design rationale | | Failure mode awareness | Explicit documentation of what tests should catch | --- ## When to Use Each ### Use V-Model When - Working with human development teams - Stable, well-understood requirements - Regulatory compliance requires documentation - Long project timelines with structured milestones - Need for contractual deliverables per phase ### Use Stateless Agent Methodology When - Working with LLM agents - Requirements may change or be incomplete - Agent context limitations are a concern - Verification must be independent from generation - Fresh context is more reliable than accumulated state ### Use Both When - Hybrid human/AI development teams - V-Model provides overall structure - Stateless principles guide AI agent tasks within phases - Human oversight at phase boundaries - AI handles detailed work within bounded contexts --- ## Synthesis: Modern Hybrid Model A modern approach might combine both: ``` HUMAN OVERSIGHT ══════════════ │ V-MODEL PHASES │ STATELESS AGENT EXECUTION ══════════════ │ ════════════════════════ │ Requirements ─────────────┼───────► Discovery Agent │ │ │ │ │ ▼ │ │ Assessment Agent │ │ │ System Design ────────────┼───────► Integration Agent │ │ │ │ │ ▼ │ │ Task Generation Agent │ │ │ Architecture ─────────────┼───────► Execution Agent (per task) │ │ │ │ │ ▼ Module Design ────────────┼───────► Forensic Agent │ │ │ │ │ ▼ ▼ │ Orchestration CODING │ │ │ │ ▼ ▼ │ Verification Agent Unit Testing ─────────────┼───────────────┘ │ │ Integration Testing ──────┤ │ │ System Testing ───────────┤ │ │ UAT ──────────────────┘ ``` **The hybrid model**: - V-Model provides macro structure for human stakeholders - Stateless methodology guides AI agent micro-execution - Human sign-off at V-Model phase boundaries - Agent autonomy within bounded task contexts --- ## Conclusion The SDLC V-Model and Stateless Agent Methodology represent the same fundamental insight applied to different actor types: | Dimension | V-Model | Stateless | | ---------------- | ------------------------------------- | -------------------------------- | | Actor | Human teams | LLM agents | | Core insight | Verification should mirror definition | Verification must be independent | | State assumption | Humans retain context | Agents lose context | | Era | Pre-AI software development | AI-assisted development | **Key convergence**: Both recognize that: 1. Definition and validation must be paired 2. Traceability from requirements to tests is essential 3. Different concerns require different roles/agents 4. Specification drives implementation **Key divergence**: - V-Model assumes stateful, contextual human actors - Stateless assumes unreliable, context-limited AI actors The Stateless Agent Methodology can be viewed as a **V-Model adapted for AI constraints**—preserving the core structure of paired definition/validation phases while adding explicit context management and independent verification required by LLM agent limitations. --- ## References - V-Model (Software Development). Wikipedia. - German Federal Government V-Model XT. - [Stateless Agent Methodology](./stateless-agent-methodology.md) - [Stateless Software Engineering Framework](./stateless-software-engineering-framework.md)