Your AI workflow needs a rehearsal of the write step

From reasoning to a persistent change

GitHub announced general availability for GitHub Agentic Workflows on October 28. The open-source project runs coding agents inside GitHub Actions, with workflows described in Markdown and compiled into Actions YAML. GitHub names issue triage, documentation updates and CI analysis among its uses. Availability does not make a workflow a free, unlimited background worker; the default Copilot CLI engine requires a Copilot license.

The announcement describes read-only defaults, isolation, network controls, output validation and threat detection. Those are product claims and documented controls, not evidence that every workflow you write will behave correctly. The practical question is how a piece of model-generated reasoning becomes an issue, comment or pull request that other people must deal with.

GitHub’s safe-output documentation gives this boundary a concrete form. The agent can propose supported operations, and separate machinery handles them under configured rules. Its staged mode previews write operations rather than performing them. That provides an opportunity to review the action layer instead of judging a run only by its final prose.

Our suggested first project is deliberately mundane: inspect open issues in a small test repository and propose a compact triage report. We have not run this workflow or tested the release. The exercise below is a planning and review method grounded in the current documentation.

The goal is not to persuade the agent to sound careful. The goal is to know what it can change, what it actually tried to change and what happens when the attempt is interrupted.

Source: GitHub: Agentic Workflows generally available ↗ · GitHub Agentic Workflows: Safe Outputs and staged mode ↗

Define a small unit of work and inspect its proposed operations

Start with one repository and a small, fixed set of fictional issues. Give them enough variety to require judgment: an incomplete bug report, a duplicate-looking feature request and a question that belongs in documentation. Keep real customers, private code and active production incidents out of the first exercise.

Write the desired outcome as one inspectable artifact. For example, a report might group issues by the next human action needed and explain what evidence is missing. This is narrower than asking an agent to improve the repository, which leaves the meaning of improvement and the scope of changes dangerously vague.

Specify what the report must not decide. A question lacking reproduction steps should remain unresolved; it should not become a verified bug. Similar wording should not automatically establish a duplicate. A feature request should not become a delivery promise because the model can imagine a plausible implementation.

For each issue, request a short explanation tied to its number and observed content. That does not guarantee accurate reasoning, but it makes the output reviewable. A reviewer can inspect the linked issue and ask whether the recommendation follows from what was available.

Keep the first run manually triggered. You want to understand one execution before adding a frequent schedule or reacting to every issue update. Trigger volume changes the consequences of a minor mistake: one poor report is easy to inspect, while repeated reports can crowd out the work they were meant to organize.

A readable report and an authorized write are different things. Decide where the report would appear and what operation creates it. If the workflow only needs a single report, there is little reason for the agent to also label, close, assign and edit every issue it reads.

Use the supported output type that matches the intended result, and inspect the current documentation for its limits. GitHub’s safe-output reference describes output-specific configuration, including maximum counts. A ceiling on operations is useful even when the prose prompt already asks for restraint, because configuration and interpretation are different enforcement surfaces.

Enable staged behavior for the relevant writes during rehearsal. The documentation says staged handlers skip write operations and show previews; they may still read target data to validate filters. Staged therefore means no supported output writes, not necessarily no data access or no resource use.

Inspect the preview for destination, title, body and quantity. Does it target the intended repository? Does it include private information copied unnecessarily from input? Would its title imply a verified incident rather than a preliminary triage note? Would running it twice create two equally plausible reports?

These are review questions you can answer without deciding whether the agent is generally intelligent or trustworthy. They concern a particular operation with a particular destination. A correct explanation in the run log cannot compensate for a write aimed at the wrong place.

Give uncertainty a useful output shape

Many automation problems begin when the output format leaves no room for an incomplete answer. If the workflow must classify every issue confidently, it may manufacture certainty when the input is insufficient. Make a request-for-information outcome part of the normal design.

For a fictional bug report, the useful result might be that reproduction steps and environment details are missing. That is a successful triage observation. It does not need a speculative root cause or a suggested patch to feel complete.

Distinguish evidence, interpretation and proposed next action in the report. Evidence can be the observed exception text. Interpretation can be that two issues may share a symptom. The next action can be a human comparing reproduction conditions. Keeping these layers separate prevents a tentative grouping from becoming an asserted diagnosis.

Do not use the number of generated comments as the success measure. More activity may represent unnecessary interruption. A concise consolidated report can be better than one comment per issue, especially when the underlying information has not changed since the previous run.

Define a no-change outcome as well. If the workflow finds nothing new within its scope, it should be allowed to produce no external write while retaining an inspectable run result. Otherwise, the system has an incentive to rephrase yesterday’s observations just to satisfy an output expectation.

Rehearse the awkward middle of a failure

The most revealing scenario is often not a complete success or a complete failure. It is a run that appears to finish reasoning but has an uncertain write outcome. A timeout can leave you unsure whether the destination changed. Your recovery process should inspect persisted state before repeating an operation.

For the triage report, imagine the report was created but the final response never reached the runner. A blind rerun might add another report. A better application design would identify the logical reporting period or input set and determine whether its intended artifact already exists.

That is our recommended design principle, not a claim that every GitHub safe-output type provides identical deduplication. The reference documents different options for different operations. Check the exact output type rather than assuming a setting for issue creation also applies to comments or pull requests.

GitHub documents a maintenance route for replaying safe outputs from a previous run when their handling fails or is skipped. Treat that as a specific recovery mechanism with documented authorization requirements. Replaying an operation deserves the same destination and duplication review as running it initially.

You can rehearse this on paper before touching a real repository. Write down what you would inspect if the run ended after generation, after validation, during writing and after a successful write with a lost acknowledgment. If two of those cases lead to the same blind retry, refine the recovery plan.

Keep the input from becoming the operator

Issue bodies, comments and repository files are task data, even when they contain imperative language. A bug report that says to ignore the workflow’s instructions is still a bug report. It should not acquire authority over the workflow because the model read it while gathering evidence.

The release’s documented safeguards address several parts of this problem, but your workflow should also have an intelligible authority boundary. The owner-defined configuration chooses scope and allowed actions. The issue contributes evidence about a problem. It cannot expand the repository list or grant itself a new write capability.

For a harmless rehearsal, include a fictional issue containing a request to change the report destination or to close unrelated issues. Observe the proposed output and available logs. Do not add real secrets or a working external exfiltration destination to manufacture a more dramatic test.

A passing example would show that the content was treated as input and that the proposed writes stayed within scope. That single result would not establish resistance to every prompt injection. It would establish only that your chosen example did not cause the behavior you were checking.

Keep the distinction in your report. A bounded test, a configured permission and a vendor safeguard are complementary pieces of evidence. None should be quietly substituted for a claim that no future input can cause harm.

Budget review effort and inspect the first real write

A workflow can stay within a model-spend limit and still cost a team too much attention. Every report, label and proposed pull request becomes something someone might need to examine. Define an acceptable review load before enabling frequent execution.

For a small repository, start with one consolidated artifact and a named reviewer. Ask how long the review takes, which recommendations are useful and how many require correcting basic misunderstandings. These observations help decide whether the workflow saves effort rather than merely redistributes it.

GitHub’s release includes budget forecasting improvements. Use documented cost tools for the chosen engine and account, and distinguish estimates from billed usage. Do not infer cost from a promotional example or from the number of visible workflow steps alone.

Consider the whole sequence: generation, validation, threat checks, retries and review. You do not need a complex accounting system for a pilot. A small log that records runs, outcomes, actual available usage figures and reviewer effort is enough to make the next decision more honest.

Set a stop condition. Repeated duplicate reports, unexpected destinations or an unresolved authorization question should pause expansion. A workflow that cannot operate usefully at a small scope needs refinement before it receives a broader scope or a shorter interval.

Bring the source instructions, compiled workflow and staged preview into the same review. Confirm that the natural-language description matches the configured permissions and outputs. A harmless-sounding brief can still sit beside an overly broad capability, and a restrictive permission can prevent an otherwise sensible task from completing.

Check the intended repository and artifact type explicitly. Confirm who will read the result and whether the artifact is appropriate for that audience. A public issue is not interchangeable with a private report simply because both accept text.

Keep credentials out of prompts, issue content and generated reports. Use the platform’s documented authentication mechanisms for the selected workflow. If a run fails because access is missing, the useful outcome is a clear access error, not a request for a token pasted into conversational material.

Then allow one bounded real output and inspect it at the destination. Confirm its contents and count, rather than relying only on a success message. Save the corresponding run reference so that the artifact has a traceable origin if someone questions it later.

Only after this should you consider additional output types. Add labeling separately from report creation, and review the new behavior on its own merits. Combining several capabilities at once makes failures harder to attribute and recovery harder to reason about.

A first experiment with a clear ending

Create a test repository containing a handful of fictional issues. Write a workflow that proposes one triage report, with no authority to close issues or change source code. Read the current quickstart and output reference before selecting configuration, because implementation details can change.

Run it in staged mode and inspect every proposed operation. Compare the recommendations against the issue text. Include one incomplete report, one misleading instruction embedded in an issue and one case with no useful new action. Record what the workflow did, rather than scoring it from how fluent the summary sounds.

If the rehearsal is useful, permit one real report in the test repository. Confirm its destination and contents, then investigate how a repeated or interrupted run would be handled. This is a suggested exercise, not a guarantee of the product’s behavior.

Finish with a narrow decision about whether this particular workflow deserves another trial. General availability makes the tool easier to adopt. A rehearsed write boundary makes your adoption easier to understand, inspect and recover when the run does not go as planned.