Agentic Workflows GA: review the actual write boundary

GitHub announced general availability of Agentic Workflows on 28 October 2026. The operational decision is what authority a workflow's output can exercise: a read-only agent can request actions that separate jobs later execute automatically. Start an adoption pilot by specifying permitted outputs, failure behavior and review requirements. Do not assume that the term safe outputs means every proposed write waits for a human. ^[1][3]

What became generally available on 28 October?#

GitHub's announcement describes an open-source project from GitHub Next that runs reasoning-based automation inside GitHub Actions. Markdown workflow definitions compile into Actions YAML. The release is generally available on github.com for Free, Team and Enterprise plans; using the default Copilot CLI engine requires a Copilot license. This is a dated adoption analysis of that announcement, checked on 1 November, rather than a promise of breaking coverage. ^[1]

The announcement also describes additions around runner support, forecasting, model choices and isolation. Those are leads for an environment-specific evaluation. They do not establish that a particular organization can enable every option without prerequisites or that a new workflow inherits an acceptable trust boundary automatically. Read the documentation for the exact engine, runner and output policy you plan to use. ^[1][2]

The important distinction for an engineering team is between reasoning and execution. A model can help interpret an ambiguous issue or investigate a failed build. The resulting suggestion may then become an issue, comment, patch or another configured operation. An issue, comment or patch has a destination and a job authorized to create it. Treat the entire workflow as the unit of authority, rather than reviewing only the agent's token. ^[2][3]

The vendor announcement includes customer productivity figures. This article does not use them as an expected outcome for your team. A small triage pilot needs its own evidence about useful reports, reviewer effort, false conclusions and actual resource consumption. General availability establishes a release status; it does not establish your return on the pilot.

Where is the actual write boundary?#

It sits across the output request and the job that applies it. The safe-outputs mechanism separates structured action requests from permission-controlled execution. That helps limit the agent's direct write authority, but permitted requests can still change repository state. The current reference explicitly says that configured outputs may publish content, update metadata or merge pull requests automatically, depending on configuration and policy gates. ^[3]

An agent operating with a read-only GitHub token therefore does not make the whole workflow observational. Other credentials, authored executable steps and later output jobs are part of the design. GitHub's architecture documentation also warns that trusted custom steps do not automatically share every confinement property of the agent sandbox. Inspect the compiled workflow and its credentials rather than inferring authority from one permissions block. ^[2][4]

There is a particularly useful default to notice during a pilot. The safe-outputs reference documents automatic issue creation when no non-system output configuration is present, unless that behavior is explicitly disabled. Omitting an output section is consequently a poor way to express a requirement that nothing should be posted. Check the current reference and declare the intended behavior explicitly. ^[3]

Record whether the run only prepares a report or also posts it. A report-only dry run, an automatically posted issue, and a proposed code change are different release modes. Name the mode in the pilot record and verify it by observing what the run actually did. A UI label or a read-only agent log cannot substitute for that observation.

What should a first issue-triage pilot permit?#

Scenario: an illustrative platform team wants a daily summary of unresolved support issues in one repository. It does not want labels changed, users contacted, code modified or pull requests merged. Initially it wants reviewers to inspect candidate reports without creating new issues. Later it may permit a single report issue in that same repository.

Begin with the smallest useful input set. Decide which issues the report covers, which sources it can read, and how it identifies missing information. Ask for links to the issues used as evidence and mark unresolved claims separately from confirmed facts. A report that sounds decisive while omitting inaccessible issues is less useful than one that explains the gap.

The following is an original internal decision record. It is valid JSON for a team's own tracker, not a GitHub API schema or copy-paste Agentic Workflows frontmatter. The values are illustrative decisions that must be translated into the current supported configuration and verified after compilation.

{
  "pilot": "support-triage",
  "scope": "one approved repository",
  "initial_mode": "review candidate without external writes",
  "later_output": "at most one report issue per accepted run",
  "forbidden_actions": [
    "change labels",
    "modify code",
    "merge pull requests",
    "write to another repository"
  ],
  "missing_evidence": "report the gap and withhold conclusions",
  "repeat_run": "reconcile the previous accepted report first",
  "owner": "platform triage reviewer"
}

The record describes a requirement, not an implemented guarantee. For every line, identify the configuration or surrounding control that enforces it and the observation that will prove it. If the installed toolchain cannot represent the required mode, keep the pilot unconnected to external writes while choosing a supported arrangement. Do not silently replace the requirement with the nearest convenient default.

The later one-report limit is a bound per accepted run, not a deduplication policy across retries. A repeated run can still create another report unless the system reconciles earlier outcomes. Decide whether the report represents a calendar day, an input snapshot or a run attempt. That identity should remain stable when the same work is retried.

Which evidence should survive a failed or repeated run?#

Keep the source definition, generated workflow, relevant configuration version, input scope, proposed output and observed outcome. If the agent completed but a later job failed, the run must not be treated as equivalent to a successfully applied report. Separate proposed, checked and applied states in your internal record. GitHub's staged architecture makes those distinctions operationally meaningful. ^[2][3]

For the illustrative pilot, a report passes editorial review only when each material claim points to an issue the reviewer can open, conflicting evidence is represented, and inaccessible sources are acknowledged. It passes execution review only when the actual permitted output and destination match the approved mode. These are our acceptance criteria, not vendor promises.

When a rerun occurs, first inspect whether the previous attempt already created its issue. A lost acknowledgement is different from a confirmed failed write. Preserve the existing issue where possible and reconcile state before deciding another operation is needed. The general pattern is covered in the durable action-identity guide; the pilot must implement it using its own supported controls.

Input freshness matters too. If issues change between report generation and review, a conclusion can become stale without any component malfunctioning. Keep an observation window and identify what changed after it. A report about yesterday's state can remain useful when its date is explicit. It becomes misleading when readers assume it is an authoritative current queue.

What should the adversarial review include?#

Use synthetic issues containing ordinary problem reports, incomplete evidence and text that tries to redirect the workflow. Examples include a request to post the report elsewhere, an instruction to reveal a secret, or a claim that a repository owner approved a new action. Those inputs are test data. They do not constitute authorization to expand the pilot.

Review both the proposed content and the actions that follow. A report can avoid an unauthorized write while still repeating an unsupported allegation from an issue. Conversely, an accurate summary can be sent to an unintended destination if output scope is wrong. Content quality and execution scope need separate assertions.

Do not infer that every detection failure blocks all outputs. The architecture documentation distinguishes enforcement modes and notes that warn-mode behavior can differ from strict blocking. The acceptance question is what your exact configuration does when a check detects a problem or cannot complete. Read and test that branch before permitting writes. ^[2]

Put destination limits and failure handling in the execution design, then use the prompt to explain the reporting task. Review the credential and job that can perform the eventual action. A read-only first stage and a broad later credential can still form a broad workflow. ^[2][3]

How should teams review the generated workflow?#

Review the Markdown source and generated lock together. The quick start instructs authors to regenerate after changing frontmatter and explains that the generated lock is required for Actions execution. A source-only review misses the operational artifact that GitHub Actions will run. The relevant comparison is the reviewed definition against its generated jobs, permissions and referenced components. ^[5]

Record the installed toolchain version and re-run the affected pilot checks when updating it. Read the changes to imported components and executable steps as well as the visible prompt. A retained immutable reference can make an artifact reproducible, but it does not cause the artifact to acquire fixes released later. Updating and recompiling remain review work. ^[2]

This analysis does not provide a universal YAML configuration because supported engines, credentials, output modes and runner prerequisites differ. The decision record is deliberately portable; the enforcement must be checked against the current toolchain. A compiled file that passes structural validation still needs the scenario tests that establish the team's intended outcome.

The GitHub Actions supply-chain guide addresses related review concerns around executable dependencies. Agentic Workflows adds a new path from repository content to proposed actions, so keep its input and output boundaries visible alongside those existing checks.

When is an agent the wrong tool for this report?#

Use deterministic queries for facts a fixed filter can compute reliably. If the report is only a count of open issues by label, a normal API query may be sufficient. Add an agent when the task needs interpretation, such as grouping differently worded reports or explaining a failure from several sources. The cost-management documentation recommends deterministic tools where they can solve the task. ^[6]

For a pilot that does use an agent, measure both workflow execution resources and inference usage through the provider and platform records available to your account. Keep those costs separate from reviewer effort. A report produced cheaply but requiring extensive correction may fail the adoption decision. This article offers no cost forecast or assumed savings. ^[6]

No repository workflow, tenant setting or external output was enabled for this article. The decision record and adversarial cases are illustrative, and the release status is a dated reading of the primary announcement. Recheck the current engine, runner and output documentation before implementing the pilot. A future product change may alter the configuration needed to enforce the same requirement.

Is Agentic Workflows generally available?

GitHub announced GA on 28 October 2026 for github.com Free, Team and Enterprise plans. Its announcement says the default Copilot CLI engine requires a Copilot license. Verify the prerequisites for your chosen engine and runner before treating plan availability as an implementation checklist. ^[1]

Does a read-only agent mean nothing can be written?

No. Safe outputs can request actions that separate permission-controlled jobs apply. Review the configured output types, destinations, credentials and policy gates. The authority of the complete workflow includes those later jobs as well as the agent stage. ^[2][3]

Are safe outputs always human-reviewed previews?

No. The reference documents actual downstream actions and configuration-dependent review requirements. Decide whether the pilot should withhold writes, post a bounded report automatically or require a review gate. Verify that exact mode rather than inferring it from the feature name. ^[3]

Must the first pilot use AI for every step?

No. Keep deterministic collection and checks deterministic. Use reasoning where ambiguity requires it, and preserve missing-data signals. Compare report usefulness and reviewer effort with a simpler implementation before expanding the agent's scope or accepting ongoing operating cost. ^[6]