Let me walk through the complete workflow using a practical example. Imagine we're building an alert management system for a mining operation (something I've actually scoped for clients). The system needs to handle equipment sensor alerts, route them through multiple notification channels (email, mobile push, in-app dashboard), let operators configure their alert preferences, and maintain a queryable history for regulatory compliance.
Phase 0: Branch Initialization
The workflow engine creates a dedicated feature branch before any agent activity begins. All subsequent work happens on this branch, with each completed phase producing a commit. The version control history becomes the state record: the branch represents the feature lifecycle, commits represent completed phases. The engine handles all version control operations. Agents never interact with git directly; they produce artifacts, and the engine manages where those artifacts go.
Phase 1: Requirement Specification
The requirements agent receives the feature description and produces a structured specification artifact. It validates the system overview document for current accuracy, queries the knowledge service for existing conventions around alerting and notification patterns, identifies edge cases (what happens when a sensor generates alerts faster than the system can process them? what's the retention policy for alert history?), and generates testable acceptance criteria.
During this phase, the agent queries the knowledge service several times. Some questions receive answers from existing documentation ('What email delivery service does the project use?' receives a documented answer). Others expose gaps ('Should alerts be processed synchronously or through a queue?'). For gaps, the knowledge service logs the question and the assumption the agent will use to continue. All of these interactions appear as structured data in the phase output.
Evaluation runs: deterministic checks confirm the artifact structure is complete; the evaluator agent confirms each acceptance criterion is objectively testable. Pass? The engine commits and advances.
Phase 2: Architecture Proposal
The architecture agent reads the approved requirement (including its documented assumptions) and proposes technical decisions. It identifies established patterns from the project's architecture records (the email service is already documented; the alert storage convention isn't). For each gap, it proposes a specific approach with documented reasoning and alternatives considered.
For instance: 'For asynchronous alert processing, propose Redis-backed job queue. Reasoning: Redis already in the infrastructure stack for caching; job queue libraries in the project's language of choice provide built-in retry and dead-letter functionality. Alternative considered: managed cloud queue service. Rejected because it would introduce an additional infrastructure dependency for a feature that doesn't require the scale characteristics of a managed service.'
The evaluator checks architectural consistency and coverage. Pass? Commit and advance.
Phase 3: Task Decomposition
The task agent breaks the requirement and architecture into five to eight concrete implementation packages: implement alert processing service, create email notification channel, create push notification channel, add operator preference management, build alert history API, and so on. Each package specifies the exact files to create or modify, dependencies on other packages, and specific acceptance criteria. The evaluator validates the dependency graph for completeness and absence of circular references.
Phase 4: Implementation
The coding agent works through task packages in dependency order (or in parallel where the dependency graph allows). For each package: write implementation code following the project's conventions, write accompanying tests, run the project's linting and test suite. Each completed package produces a commit referencing the package identifier.
Phase 5: Pull Request
When all packages are complete and passing, the engine pushes the branch and opens a pull request. This is the first moment a human enters the workflow. The PR contains everything: the requirement specification, the architecture proposal with its reasoning, the task decomposition, all implementation code, and all tests. The reviewer can see exactly which assumptions the agents made, which architectural alternatives were considered and rejected, and how every line of code traces back to a specific requirement.
The reviewer approves and merges, requests changes (the relevant agent revises on the same branch), or adds comments on specific artifacts. Agents work autonomously, but the merge decision is human.
This article is from The Agentic SDLC by Carlos Aggio.