Agentic Software Development Lifecycle
From a workplace request to governed, agent-built, deployed software. The demo is the example; the harness is the reusable product.
Özgür Karahan · July 2026
Agents in the SDLC are now shipping products, not experiments.
Copilot agents + Agent HQ
Assign an Issue; the Copilot cloud agent opens a branch and PR behind required checks. Agent HQ brings third-party agents (Claude, Codex) into GitHub.
Claude Code + Agent SDK
Terminal-native agentic coding with plan, test, and PR workflows; GitHub Actions integration; an SDK to build custom agents on the same harness.
Codex · Jules
Cloud software-engineering agents that clone the repo into a sandbox, write code, run tests, and open pull requests asynchronously.
Kiro, Devin, Rovo Dev…
Kiro makes spec-driven agentic development an IDE; Cognition Devin, Cursor cloud agents, Atlassian Rovo Dev, and JetBrains Junie ship the same shift.
community frameworks & methods — many, none standard
Spec Kit · OpenSpec · Agent OS
BMad Method · Squad · DevSquad · HVE Core
MetaGPT · ChatDev
OpenHands · SWE-agent · Aider
Task Master · Claude Squad · Conductor · Ralph loop
Same shape everywhere — and a shared hand-over point.
What they all share
- Role personas mapped to SDLC stages.
- Phased, artifact-driven workflow: spec → plan → stories.
- File artifacts as memory; git as traceability.
- Human gates keyed to risk or impact.
- An orchestrator delegating to parallel workers.
Their scope ends around the merge
- Methods describe tests and quality steps in files; turning them into platform-enforced required checks is up to each team.
- Vendor agents deliver well-checked PRs; the deploy stage — environments, smoke tests, rollback — is wired by the adopter.
- Feeding runtime evidence back into new work items is usually a manual loop.
- Round-trips with PM tools (Jira, Azure Boards) vary by vendor and setup.
This harness packages exactly that remaining wiring: enforcement first, deploy as a governed stage, and live evidence closing the loop.
Agents can write code. The open question is governance.
Agents now ship inside the SDLC
Every major vendor ships coding agents that open branches and pull requests; community methods add personas and phased plans on top.
The last mile is wired by each team
Most approaches scope themselves up to the merge; platform enforcement, the deploy stage, and live validation are left for each team to wire.
A harness that starts there
A reusable, GitHub-native harness — enforcement wired first, deploy as a governed stage, live evidence closing the loop — proven end to end on a small real agent.
The question is no longer whether agents can write code. It is whether the harness makes their work scoped, reviewable, tested, and traceable.
First, the reusable harness.
Before any example, the durable product: a GitHub-native harness that turns a capable model into a dependable, governed agent. Everything in this part is reused for every project.
One harness, five personas.
Harness author
Builds and validates. Designs agents, skills, gates; proves every gate fires with the offline self-test rig.
Platform engineer
Templatizes in GitHub. Instantiates the template per repo and turns files into enforcement: rulesets, required checks, CODEOWNERS, environments.
PM / Business owner
Creates the inputs. Turns meetings and team recaps into intents and work units — the Jira-style backlog the harness consumes.
Validator / Approver
Owns the human gates. Validates and prioritizes issues, approves the plan before code, reviews PRs, approves deploys — three hard stops.
Project team
Runs inside the guardrails. Uses the harness daily: agents implement, engineers review, evidence accumulates.
Agent = model + harness.
The model gives capability. The harness gives the rules, context, tools, gates, memory, and observability that make an agent dependable, and it reaches any system through APIs and MCP.
The platform engineer turns files into enforcement.
This is a one-time, per-repo setup. Copying the harness files gives behavior; real governance only exists once the owner enforces it on GitHub. After that, every project reuses the same baseline.
Rulesets & branch protection
No direct pushes to the default branch; changes arrive as reviewable PRs.
Required checks + CODEOWNERS
Tests, behaviour evaluations (evals), and security jobs are marked required; owners must review.
Environments & merge queue
Protected deploys and safe fan-in, verified with the verify-gates skill.
Every lifecycle step has an owner and a gate.
Planning agent
Decomposes validated intent into a scoped work graph. Procedure: decompose-intent.
Rubber-Duck agent
Adversarial plan review before any code. Gate: plan-lint. Procedure: validate-plan.
Orchestrator → Dev-fleet
Dispatches each unit to a dev-fleet or Copilot cloud agent, one PR each.
Code-review + Quality-test
Scoped review and behavior tests. Gate: tests-and-evals.
Security-compliance + Deployment
Supply-chain and deploy control. Gates: security-gate, deploy.
skills: workspace-hygiene · workplace-intake · plan-to-issues · run-tests · check-deps · verify-gates · deploy · human hard stops: plan approval → PR merge → deploy
The harness plugs into any system through APIs and MCP.
Where work starts
Work IQ, Teams, email, meeting recaps, wikis.
Where work lives
GitHub Issues, Jira, Azure Boards.
What agents call
Custom MCP servers, internal APIs, and databases.
What gates enforce
Test runners, security scanners, and linters as required checks.
Nothing here is locked to one vendor or stack. Every rule and gate is templatized in GitHub, and every integration is a swappable API or MCP server.
Now, one example use case.
Everything that follows is a single example built to exercise the harness end to end. The reusable foundation stays the same; only the use-case-specific choices change.
World Cup Commentator
A small Microsoft Foundry prompt agent (a declarative, served agent) used to prove the harness end-to-end: intake, planning, PR execution, grounding, guardrails, evals, and live validation.
What the example proves
- Work IQ can act as the governed workplace-intake layer for Teams context.
- A Teams request can become structured lifecycle work.
- The harness can add a governed tool connection without widening scope.
- Runtime evidence can become scoped follow-up work.
- Guardrails stay testable as the agent gains grounding.
Per project, three roles repeat and run in parallel.
PM / Business owner
Intent. Voices the need, spoken in a meeting or captured from a team-recap. Raw intent enters the system.
Validator / Approver
Triage gate. Turns messy intent into a clean, prioritized GitHub Issue or Jira item with acceptance criteria.
Project team + gates
Review gate. The Copilot agent executes; an engineer reviews the PR; required checks enforce test, quality, and security before merge.
intent → prioritized issue (acceptance criteria) → harness executes → PR + required checks → human review → merge → live evidence · repeatable per project, parallel across projects
How this example is wired.
From a Teams ask to a validated plan.
Enforce first
Ruleset, CODEOWNERS, required checks, and branch protection were live before any work.
Intake
A Teams request was captured with permission-aware context through Work IQ.
Triage
It became a clean, prioritized Issue with acceptance criteria.
Plan
The request became an approved grounding and work plan.
Rubber Duck
An adversarial verdict challenged the plan before code existed.
Teams intake → Work IQ context → prioritized issue → work plan → rubber-duck verdict
From scoped PRs to live, grounded evidence.
Implement
The Copilot cloud agent landed scoped PRs, one per unit of work.
Gate
Required checks (tests, lint, security) had to pass before merge.
Review
An engineer reviewed and approved each PR.
Register
The Foundry prompt agent became the working served deployment.
Validate
Live E2E refined the harness until grounded behavior passed.
Start small, build the operating system.
The World Cup agent is small by design. The reusable pattern is workplace intake, validated planning, GitHub-native governance, evals, live evidence, and controlled runtime registration.
Keep
Work IQ intake, enforce-first governance, issue-driven work, agent progress observable from PR status, evals, and human gates.
Scale
Apply the same harness, and the same API and MCP connectors, to support, SRE, migration, DevOps, and customer-facing agents.
Remember
Most agent failures are harness failures: unclear rules, missing tools, weak evals, or no enforcement.
A concrete path to try this on your stack.
Scoping workshop
Half a day: map your SDLC, PM tools (Jira, Azure Boards), and approval points onto the five personas and four gates.
Pilot on one repo
Instantiate the harness template on one of your repositories and run one real, low-risk use case through the full lifecycle.
Review & scale
Review the evidence together — PRs, gate logs, live validation — and decide which teams and use cases onboard next.
Everything shown is templatized: the pilot starts from the same files demonstrated in Part 1, on your repositories and your PM tools.