Most AI-assisted development looks the same: a developer types a prompt, an AI suggests code, a human reviews it. Faster autocomplete, essentially. The underlying workflow (requirements to architecture to implementation to testing) remains a human-managed, linear process what we call interrupt driven development.
We wanted to find out whether AI could own the entire development loop, not just accelerate it.
The result is edx-agency-dev-workflow: an open-source, 9-agent autonomous coding system built for Claude Code and GitHub Copilot. After several sprints of real project use, we think it solves a few problems that most agent frameworks quietly ignore.
The problem with most multi-agent setups
The AI developer tooling space is moving fast. GitHub Copilot now runs Claude and Codex as cloud agents. VS Code supports multi-agent sessions. There are open-source repositories with 184 specialized agents and 78 plugins.
What most of them share is a fundamental architecture gap: agents communicate through loose text, state lives in session memory that doesn't survive a reload, and quality control relies on the developer catching errors at review time.
For a solo developer building a personal project, that's fine. For an agency managing multiple client engagements where the same codebase needs to evolve reliably across weeks and people, it creates real problems.
What a structured handoff chain actually looks like
Our workflow uses nine specialized agents in a fixed sequence: researcher, architect, planner, designer, builder, tester, quality, validator and orchestrator.
The critical design decision is that every agent communicates through a schema-validated JSON handoff file, not through in-session context or free-text summaries. Each handoff is written to a versioned log directory (docs/log/phase-N/) and validated against a JSON schema before the next agent reads it.
This means the full decision trail (why the architect chose a particular pattern, what trade-offs the planner sequenced, which acceptance criteria the tester worked from) is durable, inspectable and re-playable. If you pause a phase, change a team member or return to a project after two weeks, the agents reconstruct context from the log, not from your memory.
Most other frameworks treat agent memory as an implementation detail. We treat it as a governance requirement.
The quality gate that actually works
The workflow's quality architecture is where it most visibly departs from common approaches.
There are two separate quality agents, with deliberately different mandates.
The quality agent scores four required dimensions from 1 to 10 and fixes anything below 9 — inline, up to three passes. It is interventionist: its job is to raise quality to standard.
The validator agent runs after quality passes. It is adversarial and read-only: it checks for layer violations, interface contract breaches and data leaks, and returns either PASS or FAIL. It cannot fix anything. Its only job is to find structural problems the quality agent might rationalize away.
Only after both gates clear does the orchestrator perform a final go/no-go check against the phase objective. Three gates, two independent agents, before a PR opens.
Most multi-agent frameworks have one quality check, if any. Separating quality improvement from adversarial validation was one of the most valuable design decisions we made.
One workflow, two IDEs
A practical constraint for agency teams: not everyone uses the same tools. Claude Code is the natural home for this kind of agentic workflow, but many enterprise developers work inside VS Code with GitHub Copilot.
We solved this by maintaining agent definitions in two parallel directories ( .claude/agents/ for Claude Code and .github/agents/ for GitHub Copilot ) kept in sync. The same nine agents, the same handoff schemas, the same knowledge base, running identically in both environments.
This was a deliberate choice to avoid creating a two-tier team where some developers get the full autonomous workflow and others work around it.
The knowledge base as shared memory
Rather than relying on vector databases, external memory stores or long context windows, we use a docs/kb/ directory containing a small set of structured files that every agent reads before starting a task.
requirements.md is human-owned and never overwritten by agents. It holds the non-negotiable project constraints. knowledge.yaml is agent-maintained and stores the evolving architecture facts, decisions and CI state that accumulate across phases.
This separation between human-owned and agent-maintained files is what makes the workflow usable over months rather than sessions. The knowledge base grows with the project; agents pick up where the last phase ended without needing a human to re-brief them.
Escalation that fits how teams actually work
When an agent cannot proceed (for example: ambiguous requirements, a decision outside its scope, a dependency the researcher couldn't resolve) the orchestrator opens a GitHub Issue with an agent-escalation label and pauses. The issue contains the exact question, all relevant context and a clear resumption path.
This keeps the human-in-the-loop mechanism where development conversations already happen, rather than requiring a separate AI dashboard or chat thread. Resolve the issue, close it, and the workflow resumes from where it stopped.
Security observability as a build requirement, not an afterthought
Most autonomous coding systems focus entirely on what gets built. Fewer consider how the resulting code behaves in production and specifically, whether it emits security events in a format your monitoring infrastructure can actually use.
Our requirements.md (the human-owned knowledge base file every agent reads before starting any task) mandates that security-relevant events are logged in a format compatible with OCSF 1.8.0 (Open Cybersecurity Schema Framework). Authentication attempts, authorization decisions, configuration changes and circuit breaker state transitions must emit structured events with required fields: class_uid, activity_id, time, severity_id and message.
Crucially, when a feature introduces new security events, the architect agent must produce an ocsf-<feature>.md mapping document before the builder writes a single line of implementation code.
The consequence is that continuous monitoring isn't something you retrofit after a project closes. Because the requirement lives in the knowledge base that agents consult at the start of every phase, OCSF-compatible observability is structural from day one, and not dependent on a developer remembering to add it, and not discoverable only at a security audit.
For enterprise and agency contexts, this matters considerably. It means AI-generated code lands in production environments already observable by standard SIEM tooling, without a separate remediation sprint.
Who this is for
We built this as an agency-grade template, not a solo developer tool. It assumes you are managing multi-phase projects where a codebase needs to evolve reliably across team members and client feedback cycles. The TypeScript 6 strict toolchain, ESLint, Prettier, Vitest and GitHub Actions CI are production defaults, not optional additions.
The template is open-source under the Apache 2.0 license. Clone it, replace the placeholder requirements, invoke the orchestrator with your Phase 0.1 objective and the agents take it from there.
We're continuing to refine the workflow as we use it in live client engagements. Contributions and issues are open on GitHub.
View the repository →
label
ai, continuous innovation
