Overview
A proof of concept for the whole software delivery lifecycle: a user story from any work tracker, such as Jira or Azure DevOps, goes through planning, code, tests, review, merge and release, and the story is closed at the end. The work is done by a team of six GitHub Copilot agents: one orchestrator that calls five specialist sub-agents only when it needs them. A separate pull-request review agent then checks the result in its own workflow, on a different model from the one that wrote the code. People still approve the plan and merge the code. It is built on GitHub Agentic Workflows (gh-aw), GitHub's way of running coding agents inside GitHub Actions: each workflow is a Markdown file with plain-language instructions for the agent and a short settings block for triggers, permissions and allowed outputs, which the gh aw compile command turns into a standard Actions workflow. The agents can read but not write; anything they want to publish is checked and carried out by a separate job. There are no stored passwords or tokens, and every run leaves logs that can go to Azure Monitor, Splunk, Datadog, or any other analytics tool.
How it works
- 1
An engineer opens a GitHub issue
The issue holds a question, a request, or just a user story number from the work tracker. Adding a label starts the first workflow.
- 2
A script collects the facts before any AI runs
An ordinary workflow step, not a model, signs in with a short-lived token, reads the story (title, description, acceptance criteria, and which revision it is) and the team's engineering guidelines, saves them as files, and signs out again. The tracker can be anything reachable through an API, a CLI, or an MCP server. If the story is missing or cannot be read, the work stops there; the agents never guess what a story says from its number.
- 3
Two specialists look at the code and the guidelines
The repository explorer reads the code and explains how the relevant parts work today. The guidelines agent reads the saved guidelines and says which ones apply. Both point to the exact file or page they used, and the orchestrator says so plainly when the code and the guidelines disagree.
- 4
The orchestrator picks the route
A question gets an answer in the issue. A small, clear change goes straight to the coder and tester agents and becomes a draft pull request. Anything larger, unclear, or sensitive goes to the planner / architect / designer agent, which writes a plan with the scope, architecture, design for any user-facing screens, acceptance criteria, constraints, tests, and open decisions written down. That plan is published as a draft pull request with no code in it, and the run stops.
- 5
A person approves the exact plan
A maintainer reads the plan and approves it with a comment that names the exact commit. The approval only counts for that commit and that version of the story; if either changes afterwards, the approval no longer applies and the plan has to be approved again.
- 6
The coder and the tester build what was approved
The approval comment starts a second workflow. It confirms who approved and what they approved, then the orchestrator hands the plan to the coder agent, which writes the code on the same branch. The tester agent writes tests from the story's acceptance criteria, so every criterion is covered by at least one test, runs the whole test suite, and reports which criteria pass. The plan files themselves are locked so the code cannot quietly rewrite them.
- 7
Everything is checked again before it is published
A separate job, which never runs the pull request's own code, re-checks the approval and the story version. Only then is the change pushed to the pull request, and a final job confirms that the commit really landed. A message from an agent saying it is done does not count as proof.
- 8
A separate agent reviews the pull request
Opening or updating the pull request starts another workflow with its own review agent. It runs on a completely different model from the coder, so it does not share the coder's blind spots, and it is not part of the coder's session. It reads the change against the team's engineering standards documents and leaves comments on the exact lines, each with the standard it relies on, the evidence, a suggested fix, and a link to the source. It can comment and ask for changes, but it can never approve or push code.
- 9
People review and merge
The pull request carries the plan, the test results, the review findings, and the sources the agents used, so the reviewer checks evidence instead of reading every line cold. A person who did not start the work approves and merges it. Agents never merge.
- 10
The existing pipeline releases it
After the merge, the team's normal CI/CD pipeline takes over: it builds the change and deploys it to the development environment, then to the test environments, then to production, with a person approving each environment along the way. The agents have no rights to deploy anything.
- 11
The story is closed in the tracker
The pull request carries the story number, so the tracker links the story to the code and moves it to done on merge. That update is made by the tracker's own integration with GitHub, not by an agent, so no agent ever needs write access to the tracker.
The agents
Orchestrator
The agent the workflow starts. It reads the request, calls the specialists it needs, combines their answers, and is the only one allowed to ask for a comment or a pull request.
Repository explorer
Reads the code and explains how the relevant parts work, pointing to the files and lines it used.
Guidelines agent
Reads the team's documented engineering guidelines, says which ones apply, and links to the source.
Planner / Architect / Designer
Turns larger or unclear requests into a written plan for a person to approve. It covers the architecture (how the change fits the system, and when it needs an architect's sign-off) and, for user-facing work, the design of screens and states. It never writes production code.
Coder
Writes the code for small, clear changes or for an approved plan, and reports anything that blocks it.
Tester
Writes tests from the story's acceptance criteria, runs the full test suite, and reports which criteria are covered and which are not.
Pull-request reviewer (separate workflow)
Runs on its own whenever a pull request is opened or updated, on a different model from the coder. Checks the change against the engineering standards documents and cites the standard behind every finding. It can comment, but never approve or push.
Key outcomes
- Built on GitHub Agentic Workflows (gh-aw)
- Story to production with human approvals
- Independent PR review on a different model
- Any tracker via API, CLI or MCP
- No stored secrets: OIDC + federated credentials
- Traceable runs: logs to Azure Monitor, Splunk or Datadog