From Autonomy to Infrastructure: How ACO System Connects to GitHub

The moment you move an autonomous coding system from “runs locally” to “connects to GitHub” is the moment it stops being a demo and starts being infrastructure.

That’s the transition the ACO system just went through. For months it ran as a self-contained multi-agent pipeline: PM creates stories, Planner breaks them into tasks, Architect validates, Developer implements, QA tests. It worked, but everything stayed inside the system — stories in a local SQLite database, code in a local directory, no connection to the outside world.

Last week’s addition of the GitHub integration layer changes that equation entirely.

GitHub Issues as the Entry Point

Before this change, stories entered the ACO pipeline through a Python script (init_story.py) that wrote directly to the local database. You had to know the system to use it.

Now a GitHub Issue is the canonical entry point. Create an issue with the right labels, and the ACO pipeline picks it up automatically. The integration watches for new issues in the configured repository, reads the issue body as the feature description, and routes it through the PM → Planner → Architect pipeline before returning a structured task breakdown as a comment on the issue.

This is the right abstraction for a few reasons. First, it means the ACO system slots into existing developer workflows — you file an issue the same way you always do, and behind the scenes the autonomous pipeline starts working on it. Second, it gives you a natural audit trail: every story has a corresponding GitHub issue, every task has a corresponding PR, and everything is linkable.

Branches and PRs as the Output Layer

The Developer agent already created branches and PRs — but without the GitHub integration layer, those were just local git operations. Now they’re first-class GitHub objects with proper metadata, linked to the originating issue.

The flow is clean: the Architect approves a story → the Developer agent creates a branch → implement the tasks → open a PR with the task checklist in the description → the QA agent runs smoke tests → the PR gets a status check. At any point, a human can step in through the Human Reviewer stage.

What this means practically: you can watch a feature go from issue to PR without any human writing code. The autonomous pipeline handles the full handoff chain. You’re reviewing the output, not producing it.

Why the GitHub Integration Matters More Than the Agent Improvements

Here’s the thing about agent improvements — better prompts, cognitive modes, stricter task contracts — they matter enormously for output quality. But they’re invisible to anyone who isn’t running the system.

GitHub integration is visible. It’s the thing that makes the system credible to a new person looking at the repo. “Here’s our autonomous pipeline, here’s a PR it opened” is a more convincing demonstration than “here’s our cognitive mode taxonomy.”

It also forces a discipline that purely local systems don’t: GitHub has opinions about how code should be structured. Branch naming conventions, PR descriptions, commit messages — these all impose a minimal quality floor that makes the autonomous output easier to review and merge.

What Comes Next

The integration is solid now, but it’s still one-directional: ACO reads from GitHub and writes to GitHub. The next layer worth building is bi-directional sync — if a human comments on a GitHub issue, that context should feed back into the ACO pipeline. If the Architect rejects a story, the issue should be labeled accordingly.

That’s the path from “autonomous coding system” to “autonomous teammate” — not just the ability to ship code, but the ability to participate in the full conversation that surrounds code.

The infrastructure is in place. The agents are sharp. The next constraint is interaction design.