AI Engineering

GitHub Agentic Workflows Adds Review-Time Steering Without Permission Creep

GitHub Agentic Workflows now lets agents read explicitly marked pull request feedback during pre-created PR runs without silently adding repository permissions.

GitHub Agentic Workflows published its August 24, 2026 weekly update with a small feature that points at a larger design pattern for production coding agents: review feedback can become part of an active agent run, but only through an explicit permission boundary.

The specific change is pre-created pull request steering. A workflow can allocate a draft PR before the agent starts, let humans leave comments containing a steering keyword, and allow the agent to read that feedback while it works. The important part is not the keyword. The important part is that the feature requires pull-requests: read and the compiler refuses to add that permission silently.

That is the right shape for agent governance. Agents need tighter feedback loops, but those loops should not smuggle new authority into the run.

What Happened

On August 24, 2026, the GitHub Agentic Workflows project summarized a week of changes around safe-output reliability, compiler robustness, and workflow observability. The headline item for agent practitioners is PR steering for pre-created pull requests.

GitHub Agentic Workflows already has a safe-outputs model. Instead of giving the agent direct write access to GitHub, the agent emits structured output. Separate permission-controlled jobs then create issues, comments, pull requests, labels, or other GitHub-side effects. This separates "the model proposes an action" from "the workflow executes an action."

The new steering path extends that model to a more interactive workflow. The feature was added in pull request #55171, merged on August 24, 2026. It lets an agent working from a pre-created PR ingest user-authored PR comments and review comments that contain the steer keyword. The PR description is explicit about the control plane: steering configures GitHub MCP access for pull request reading, requires explicit PR read permissions, and does not automatically broaden workflow permissions.

The docs for pull-request safe outputs now describe the behavior under pre-created PRs. A pre-created PR is allocated before the agent starts, opened as a draft, linked to the workflow run, and later updated by the safe-output phase if the agent produces changes. When steer is enabled, comments become an intentional feedback channel into the running agent.

The same weekly update also called out gh aw models, better Copilot SDK startup diagnostics, and ingestion of automatic PR review dismissals. Those are useful operational improvements, but steering is the one worth unpacking because it changes how humans and agents share an in-flight code review surface.

Why It Matters

Most coding-agent systems have an awkward review loop. The agent runs, opens a PR, the human reviews it, and then somebody has to start another turn with the review context copied back into the agent. That is workable for small tasks. It is painful for long-running maintenance workflows, generated refactors, dependency sweeps, docs migrations, or anything where the PR is the natural place for the team to talk.

The tempting fix is to let the agent watch the PR and react to all comments. That is also a footgun.

Pull request comments are not just friendly reviewer input. They are untrusted text attached to a high-authority workflow. They may come from people with different repository roles. They can contain stale assumptions, adversarial instructions, accidental secrets, or requests that conflict with the workflow's original scope. If an agent can read PR comments, and if enabling that read path also quietly grants broader GitHub permissions, the review surface turns into a privilege expansion surface.

GitHub's implementation is notable because it does not treat "feedback loop" and "permission expansion" as the same feature. The agent can read steering feedback only when the workflow author opts in. The workflow must already have effective pull-requests: read permission or higher. If not, compilation reports an error instead of patching the permissions block on the author's behalf.

That compiler behavior matters. In agent systems, implicit permission repair is usually the wrong default. It makes demos smoother, but it hides security decisions in tooling. A workflow author should have to say, in version-controlled YAML, that this run may read PR metadata.

This is also a useful distinction for enterprise teams adopting coding agents. The hard problem is not only preventing agents from pushing directly to main. It is preserving auditability as agents become more interactive. Every additional context source should be treated as an authority decision, even when the permission is read-only.

How It Works

GitHub Agentic Workflows is built around workflow Markdown that compiles into GitHub Actions. The safe-outputs section declares which validated GitHub operations may happen after the agent runs. The framework documentation describes the security model as separation: agents run with limited authority and request side effects through structured output, while separate jobs with scoped permissions execute those requests.

For pull requests, create-pull-request is one of the safe-output types. It can create a PR with the agent's changes, enforce draft defaults, apply labels, request reviewers, restrict branch targeting, limit patch size, and protect sensitive files. The pre-created PR mode is experimental: it allocates a draft PR during activation, before the agent starts, then reuses that PR when the agent emits its final create_pull_request output.

That pre-created PR gives the team a stable review artifact while the run is still active. Instead of waiting for a finished branch and PR, reviewers can see the work-in-progress shell and leave targeted guidance.

Steering adds a read path on top of that pre-created artifact. In the pull request that introduced the feature, the authors describe object-form pre-create configuration with steer: true. When enabled, the framework injects instructions telling the agent to query user-authored PR comments and review comments containing the steering keyword. It also ensures the GitHub MCP server exposes the pull request read toolset needed for that query path.

The important constraints are:

The workflow needs explicit pull-requests: read permission. The compiler reports an error if steering is enabled without that permission. Existing boolean pre-create: true behavior is preserved. The feature is scoped to comments containing the steering keyword, not a general invitation to treat every PR comment as an instruction. The final repository mutation still flows through safe outputs rather than direct write authority inside the agent turn.

The release page for v0.87.4, published on August 22, 2026, shows the same broader direction. That release focused on compiler robustness, safe-output validation, reproducibility around pinned Agent Plugins, engine flexibility, and hardening of checkout and credential handling. The August 24 weekly update layers the steering change into that same operating model: agents become more useful by reading more operational context, but the compiler and safe-output layer keep deciding where the boundary sits.

Example

Consider a workflow that refreshes stale PR descriptions for a large repository. The agent's job is not to invent code. It reads the branch, issue, commits, and review state, then updates the PR body with current context, test notes, and a footer identifying the automation that touched it.

Without steering, the human loop looks like this:

The workflow runs.
The agent drafts or updates the PR.
A reviewer notices the description missed an important migration note.
Someone starts a follow-up run or manually edits the PR body.

With pre-created PR steering, the workflow can expose a deliberate feedback channel:

permissions:
  contents: read
  pull-requests: read

safe-outputs:
  create-pull-request:
    pre-create:
      steer: true

During the run, a reviewer can comment on the draft PR:

steer: include the database migration compatibility note from PR #4821,
but do not mark the PR ready for review until the generated test summary
references the new rollback job.

The agent can read that comment because the workflow author explicitly granted PR read access and enabled steering. It can incorporate the instruction into its plan and final structured output. The safe-output phase still controls the actual PR update.

That division is subtle, but it is the difference between useful autonomy and loose automation. The review comment influences the agent's reasoning; it does not become arbitrary write authority. The final write remains constrained by safe-outputs, branch policy, protected-file rules, patch limits, and whatever review rules the repository already enforces.

There are obvious extensions of this pattern. A dependency upgrade workflow could accept steering that narrows the package set. A docs automation could accept steering that points at a canonical source. A release-note workflow could accept steering that asks the agent to include or exclude specific PRs. The same rule should apply in every case: the steering source must be explicit, narrow, and auditable.

My Take

This is the kind of feature that looks minor until you have operated agents in a real repository.

The first generation of coding-agent integrations optimized for task delegation: give the agent an issue, let it work, review the diff. The next generation has to optimize for review-time collaboration. Humans do not communicate with code changes only at task boundaries. They leave comments, change labels, dismiss reviews, ask for narrower scope, point to broken assumptions, and correct priorities while the work is underway.

If agents cannot consume that feedback, they stay clumsy. If they consume it without a hard boundary, they become risky.

PR steering is an example of a better middle path. It turns the PR into a controlled context source. It uses a keyword so steering is intentional. It requires an explicit read permission so the workflow's authority is visible in code review. It keeps writes on the safe-output side of the system.

I would still treat this as an advanced feature. Pre-created PRs are documented as experimental. Teams should start with low-risk workflows, require narrow prompts, and log what steering comments the agent read. I would also avoid using steering as a dumping ground for arbitrary product requirements. If every comment becomes a steering instruction, the keyword loses its value and the run becomes harder to audit.

The more interesting long-term idea is not "agents can read PR comments." It is "agent feedback channels should be typed." A reviewer instruction is different from a CI failure, a code review dismissal, a label change, a security scanner alert, or an issue comment from a drive-by contributor. Production agent systems should preserve those distinctions all the way into the agent context.

That is where workflow compilers can do useful security work. They can force explicit permissions. They can reject ambiguous configurations. They can keep unsafe defaults from spreading through copy-pasted YAML. They can make agent runs reproducible enough that teams can debug failures instead of reading chat transcripts and guessing what happened.

Conclusion

GitHub Agentic Workflows' August 24 update is another signal that coding agents are moving from single-turn code generators toward governed workflow participants. Pre-created PR steering gives agents a way to listen during review without erasing the permission model that makes safe outputs useful.

The lesson for engineering teams is straightforward: do not build agent feedback loops as hidden prompt plumbing. Make every feedback source explicit. Bind it to permissions. Keep writes behind a separate validated execution path. Then let the agent move faster inside boundaries that a human reviewer can actually see.