Skip to content

docs: Clean up bits around GH Agentic Workflows #5199

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
cgwalters wants to merge 1 commit into from
Closed

docs: Clean up bits around GH Agentic Workflows #5199

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 5 additions & 9 deletions docs/landscape.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,7 +6,7 @@ A survey of AI-driven code review systems and **adjacent agent infrastructure**

## The industry consensus

The entire industry is solving "AI as first-pass reviewer that helps humans review faster." Nobody is seriously tackling the full autonomous merge problem. GitHub has published an [explicit position paper](https://github.blog/ai-and-ml/generative-ai/code-review-in-the-age-of-ai-why-developers-will-always-own-the-merge-button/) arguing that developers will always own the merge button. This is the question we're asking differently.
There isn't one. Projects range from entirely banning AI to having AI agents doing work with little structure or oversight.

## Major tools

Expand Down Expand Up @@ -77,13 +77,11 @@ Uses "a series of AI code reviewers, each with different specialties" — e.g.,

**Relevance to fullsend:** Sourcery's candor about their limitations is informative. Their specialized-reviewer approach validates our sub-agent decomposition, but their inability to reason about the broader codebase illustrates why context management per sub-agent matters. A correctness sub-agent needs repo context; a security sub-agent needs raw PR content; an intent & coherence sub-agent needs the intent repo. Different sub-agents, different context.

### GitHub Copilot Code Review
### GitHub Copilot

[Blog post](https://github.blog/ai-and-ml/generative-ai/code-review-in-the-age-of-ai-why-developers-will-always-own-the-merge-button/)
[Website](https://github.com/features/copilot)

GA since April 2025. 1 million users in one month. Assign Copilot as a reviewer like any teammate. October 2025 update added context gathering — reads source files, explores directory structure, integrates CodeQL and ESLint.

**Relevance to fullsend:** GitHub's explicit "humans own the merge button" position means we cannot rely on GitHub's native tooling for autonomous merging. We'll need to build merge authority outside of (or on top of) GitHub's review/approval system.
Very relevant to fullsend: has code review and also supports having background agents steered interactively. Backend infrastructure here is reused by GitHub Agentic Workflows (see below).

@qodo-code-review qodo-code-review Bot Jul 16, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Informational

2. Uncited infrastructure reuse claim 🐞 Bug ⚙ Maintainability

docs/landscape.md asserts that GitHub Copilot “backend infrastructure” is reused by GitHub Agentic
Workflows, but provides no citation and the terms are ambiguous (what components, what kind of
reuse). This reads as a factual dependency claim without support.
Agent Prompt 
## Issue description
The doc makes a concrete factual claim about shared infrastructure between Copilot and gh-aw, but does not cite a source and is vague about what is shared.

## Issue Context
Landscape docs are used as a reference; ambiguous/uncited claims are hard to validate and easy to contest later.

## Fix Focus Areas
- docs/landscape.md[84-84]

## Suggested change
Either (a) add an authoritative citation supporting the reuse claim, and/or (b) rephrase to be specific and qualified (e.g., “gh-aw appears to build on similar agent runtime primitives as Copilot, based on <source>”).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


### GitLab AI Merge Agent

Expand Down Expand Up @@ -305,8 +303,6 @@ Repository automation from GitHub Next and Microsoft Research, running coding ag

Its integrity filtering system is particularly interesting — it implements a form of input trust tiering (`merged > approved > unapproved > none`) that addresses a subset of what fullsend explores in [autonomy-spectrum.md](problems/autonomy-spectrum.md), though applied to content visibility rather than merge authority. The content sanitization pipeline is a concrete implementation of pre-LLM injection defense, complementing the post-LLM threat detection scan. The orchestration pattern (`dispatch-workflow` / `call-workflow`) provides native multi-workflow coordination that fullsend builds custom infrastructure for.

However, gh-aw explicitly stops at human-in-the-loop automation. It does not address autonomous merge judgment, intent verification, inter-agent trust, or agent governance. Its orchestration is workflow fan-out, not the specialized sub-agent composition with zero-trust review that fullsend envisions. And it inherits GitHub's product constraints — including the position that [developers will always own the merge button](https://github.blog/ai-and-ml/generative-ai/code-review-in-the-age-of-ai-why-developers-will-always-own-the-merge-button/).

The comparison raises a structural question for fullsend: which problems in our implementation are inherent to the goal of autonomous development, and which are artifacts of building externally to the platform we're automating? See [platform-nativeness.md](problems/platform-nativeness.md) for the full analysis.

## Architectural patterns in the field
Expand All @@ -331,7 +327,7 @@ Structure the workflow as a pipeline where deterministic steps (context prefetch

### 5. GitHub Actions as agent runtime (Collo.dev, gh-aw)

Use GitHub's native workflow engine as both the orchestration layer and the compute runtime. Agents are invoked by workflow triggers (label changes, issue comments, schedules), run in ephemeral Actions runners, and coordinate through issues and labels. Zero infrastructure beyond a GitHub repo and an API key. gh-aw adds significant depth to this pattern with containerized execution, network firewalling, artifact-based safe outputs, and AI-powered threat detection — demonstrating that Actions-native agents can have strong guardrails without external infrastructure. The trade-off: tightly coupled to GitHub's event model, limited to Actions runner capabilities and timeouts, and (in the case of gh-aw) constrained by GitHub's product position against autonomous merging.
Use GitHub's native workflow engine as both the orchestration layer and the compute runtime. Agents are invoked by workflow triggers (label changes, issue comments, schedules), run in ephemeral Actions runners, and coordinate through issues and labels. Zero infrastructure beyond a GitHub repo and an API key. gh-aw adds significant depth to this pattern with containerized execution, network firewalling, artifact-based safe outputs, and AI-powered threat detection — demonstrating that Actions-native agents can have strong guardrails without external infrastructure. The trade-off: tightly coupled to GitHub's event model, limited to Actions runner capabilities and timeouts.

These are complementary, not competing. A system could use stacked PRs (Graphite's insight) reviewed by specialized sub-agents (CodeRabbit's insight) with deep codebase context where needed (Greptile's insight), all orchestrated through a deterministic pipeline with agentic steps (Stripe's insight), running on GitHub Actions (Collo.dev's insight for teams that want zero infrastructure overhead).

Expand Down
8 changes: 4 additions & 4 deletions docs/problems/platform-nativeness.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -63,7 +63,7 @@ These problems exist regardless of whether the system is native or external. The

### Autonomous merge judgment

gh-aw explicitly keeps humans in the loop. Its safe-outputs model produces artifacts that a gated write job applies, but merge is never one of the permitted operations. GitHub's own [position paper](https://github.blog/ai-and-ml/generative-ai/code-review-in-the-age-of-ai-why-developers-will-always-own-the-merge-button/) argues developers will always own the merge button. Fullsend's thesis is that for routine changes with sufficient verification, the merge decision can be automated. This is a judgment problem that no amount of platform nativeness resolves — it requires intent verification, confidence scoring, and a governance model for when to override.
gh-aw defaults to keeping humans in the loop. Its safe-outputs model produces artifacts that a gated write job applies, but merge is not currently one of the permitted operations. This is however a default design choice, not a platform limitation — credentials injected into an agentic workflow can allow merging a PR. A [GitHub blog post](https://github.blog/ai-and-ml/generative-ai/code-review-in-the-age-of-ai-why-developers-will-always-own-the-merge-button/) argues developers will always own the merge button, but that's one team's editorial position, not a constraint GitHub's platform enforces. Fullsend's thesis is that for routine changes with sufficient verification, the merge decision can be automated, but such a system could be implemented directly with GitHub Agentic Workflows as well.

### Intent verification

Expand Down Expand Up @@ -121,7 +121,7 @@ GitHub Actions runners have a 6-hour job timeout, limited compute options (unles

### Product dependency

gh-aw is in early development and may change significantly. Building on it means depending on GitHub's product decisions, deprecation timeline, and willingness to support autonomous use cases. GitHub has explicitly stated that humans should own the merge button — a position that directly conflicts with fullsend's thesis. An external system can build merge authority independently of the platform's product philosophy.
gh-aw is in early development and may change significantly. Building on it means depending on GitHub's product decisions, deprecation timeline, and willingness to support autonomous use cases. gh-aw's maintainers have publicly favored keeping humans on the merge button — an editorial stance rather than a platform-enforced restriction, but one that shapes what gh-aw is likely to build next. An external system can build merge authority independently of that stance.

### Isolation model

Expand All @@ -133,7 +133,7 @@ gh-aw's container isolation is strong for its use case, but the isolation bounda

- **Is the forge abstraction worth the cost at this stage?** Fullsend's only concrete implementation is GitHub. If forge-neutrality is deferred to the [Infrastructure](../roadmap.md#infrastructure) and [Cross-forge orchestration](../roadmap.md#cross-forge-orchestration) work in the [roadmap](../roadmap.md), the current implementation could use GitHub-native primitives directly, simplifying the stack substantially.

- **Can gh-aw's safe-outputs model be extended for autonomous merge?** If a safe-output type of "merge this PR" were added (gated by all required checks passing and a confidence threshold), gh-aw's architecture could support tiered autonomy without fullsend's external plumbing. This depends on GitHub's willingness to add such a capability — which their current position suggests is unlikely.
- **Can gh-aw's safe-outputs model be extended for autonomous merge?** Nothing technical blocks this today — a plain workflow job triggered on `pull_request_review` (approved) or a passing check suite can call the merge REST endpoint or the merge-queue GraphQL mutation with a token that has write access, entirely outside gh-aw's safe-outputs system. The open question is whether gh-aw's maintainers formalize this as an official safe-output type (gated by required checks and a confidence threshold), which would make it a first-class, auditable primitive instead of something every adopter bolts on themselves. Given their stated editorial position, that seems unlikely to come from upstream — but it doesn't stop fullsend or anyone else from building it as an unofficial follow-up job today.

@qodo-code-review qodo-code-review Bot Jul 16, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remediation recommended

1. Overbroad merge feasibility claim 🐞 Bug ≡ Correctness

docs/problems/platform-nativeness.md states “Nothing technical blocks” autonomous merging via a
standalone workflow calling merge APIs, but merges still depend on workflow token permissions plus
branch protection/rulesets (required checks, required reviews, merge queue prerequisites). This can
mislead readers into assuming an approval/check event alone is sufficient or that protections can be
bypassed.
Agent Prompt 
## Issue description
The doc uses an absolute statement ("Nothing technical blocks") when the described approach only works if repository policy and token permissions allow it (branch protection/rulesets, required checks/reviews, merge-queue configuration, workflow permissions). This should be qualified to avoid implying merges can bypass protections.

## Issue Context
This section is used to reason about whether gh-aw’s limitations are design choices vs. platform constraints. Overstating feasibility can send implementers down an incorrect path or create confusion when automation fails under common protections.

## Fix Focus Areas
- docs/problems/platform-nativeness.md[136-136]

## Suggested change
Reword to something like: “GitHub exposes APIs for programmatic merging, but success is still subject to the workflow token’s permissions and repository rules/branch protections (required checks/reviews, rulesets, merge queue prerequisites).”

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


- **Where is the boundary between containment and judgment?** gh-aw solves containment well. Fullsend's unique value is judgment. Should fullsend's implementation focus exclusively on the judgment layer and delegate containment to native platform features wherever possible?

Expand All @@ -147,6 +147,6 @@ However, this approach carries real tensions that should be weighed:

- **ADR 0005 conflict:** The accepted [forge abstraction layer](../ADRs/0005-forge-abstraction-layer.md) decision assumes fullsend remains portable across GitHub, GitLab, and Forgejo. Adopting gh-aw as the containment layer would lock fullsend at the runtime and security architecture level — deeper than what the forge abstraction was designed to abstract over. A POC should be evaluated against whether it invalidates, defers, or supersedes ADR 0005.
- **Pre-GA platform risk:** gh-aw is in technical preview (~68 releases in 8 months), Linux-only, and may change significantly before GA. Building on it means depending on GitHub's product decisions, deprecation timeline, and feature stability.
- **Philosophical opposition:** GitHub has [explicitly positioned](https://github.blog/ai-and-ml/generative-ai/code-review-in-the-age-of-ai-why-developers-will-always-own-the-merge-button/) against autonomous merge — fullsend's core thesis. Using gh-aw as the containment layer while building merge authority on top of it means depending on a platform whose maintainers oppose the end goal.
- **Philosophical opposition:** gh-aw's maintainers have [publicly favored](https://github.blog/ai-and-ml/generative-ai/code-review-in-the-age-of-ai-why-developers-will-always-own-the-merge-button/) keeping humans on the merge button — fullsend's core thesis is that this decision should be automatable for routine changes. That stance doesn't block fullsend from adding a merge job on top of gh-aw's containment (nothing in GitHub's API prevents it), but it does mean gh-aw itself is unlikely to ever formalize merge as an official safe-output, so fullsend would own that layer entirely rather than building on upstream support for it.

If pursued, the POC would inform whether fullsend's implementation effort should shift from building containment infrastructure to building judgment-layer capabilities on top of gh-aw — but it should be treated as an experiment, not a commitment.
Loading