GitHub issue intent has three settings. Choose yours.

A GitHub Agentic Workflow can now handle each supported issue output in one of three ways: require rationale and confidence metadata, encourage that metadata while allowing the output without it, or disable the metadata. This per-output setting is called issue-intent. The choice determines whether an agent-made issue change must carry an explanation and confidence rating before the workflow can complete.

That setting does not by itself decide whether the change applies automatically, waits for review, or is authorized in the first place. When confidence metadata is present, the repository automation level helps route the change, and an explicit request to suggest can hold it for review. Repository and agent permissions determine what the agent can change. This implementation note explains those separate decisions and gives software and operations leads one bounded label test for deciding whether to enable the preview, limit its use, or wait.

The preview covers specific issue changes, not every agent action

GitHub announced the public preview on July 23, 2026. For each supported issue change, an automation can attach a rationale and a high, medium, or low confidence rating. The covered mutations are labels, fields, issue type, closing issues, and assignees. The same controls are available through Copilot cloud agent automations, GitHub Agentic Workflows, and REST or GraphQL integrations.

The scope ends at those issue changes. According to GitHub's concepts documentation, these controls do not cover other automation actions such as opening pull requests or pushing code. A team should therefore evaluate them as issue-triage controls rather than as a general approval mechanism for everything an agent can do.

Availability also has boundaries. The feature is in public preview and may change. Repository automation-level configuration is rolling out gradually, so the setting may not appear in every otherwise eligible repository. GitHub's current Copilot automation documentation lists Copilot Pro, Copilot Pro+, Copilot Max, Copilot Business, and Copilot Enterprise. It limits Copilot cloud agent automations to private and internal repositories where Copilot cloud agent and automations are enabled; public repositories, repositories owned by managed user accounts, and repositories where an administrator has disabled the feature are ineligible. Those are the documented limits for Copilot cloud agent automations, not a claim of universal access across every supported integration path.

Required, optional, and disabled issue intent produce different evidence

Issue intent is the rationale and confidence metadata attached to a supported issue change. In GitHub Agentic Workflows, it is configured on each safe output, including add-labels, set-issue-type, set-issue-field, assign-to-user, assign-to-agent, and close-issue. The state you choose changes what the workflow accepts.

When issue-intent is unset, metadata is optional and enabled by default. The agent is encouraged to provide rationale and confidence, yet the output still works if it omits them. This preserves compatibility, but it cannot enforce a local requirement that every successful label or assignment output include both values.

Set issue-intent: true when the absence of rationale or confidence should stop that output. GitHub's current management instructions state that the workflow fails if the agent omits either value. For a label-only triage workflow, the compact configuration is:

safe-outputs:
  add-labels:
    issue-intent: true

Set issue-intent: false to opt out for that output. The output carries no rationale or confidence metadata. Use this state only when the workflow does not need the evidence introduced by the preview.

There is a small documentation trap here. The announcement uses the plural issue-intents, while the current how-to uses the singular issue-intent under each safe output. Current documentation should control implementation. Update the GitHub Agentic Workflows extension with gh aw upgrade, use the per-output singular form shown above, and run gh aw compile instead of copying the announcement shorthand into a workflow.

Repository automation levels route changes after metadata is available

The issue-intent setting answers whether a supported output must include metadata. The repository automation level answers what GitHub does with a supported change based on its confidence. Keeping those settings separate prevents a common configuration mistake: requiring rationale does not itself require human review.

GitHub currently defines four repository levels. Full control holds every change for review. Cautious, the default, automatically applies only high-confidence changes. Balanced applies routine, clear-cut changes and holds ambiguous ones. Full automation applies every change unless the agent flags it as uncertain. GitHub has not published numeric thresholds or evidence that explains how the three confidence labels are calibrated.

A change below the configured threshold waits as a suggestion. An explicit instruction to suggest can also hold a change even when its confidence would otherwise allow automatic application. Reviewers can find pending work with has:suggestions, including the query is:issue is:open has:suggestions.

This routing can reduce unnecessary review if the ratings are useful in a repository's actual issue mix. Current sources do not establish false-positive or false-negative rates, reviewer burden, production adoption, or how well confidence transfers between repositories. Confidence can route work without granting permission, so a team still needs evidence from its own cases before increasing automation.

Suggestion review cannot enforce the agent's issue-write boundary

GitHub explicitly describes approvals as a workflow convenience rather than a security control. The actor is an agent with permission to change issues. The object is the issue mutation, such as adding a label or closing an issue. That agent can apply the mutation directly instead of proposing it, including through REST or GraphQL.

The approvals panel therefore helps people review changes that enter the suggestion path. It does not create a server-side boundary around issue writes. Repository and agent permissions supply that authority, which is why least-privilege configuration remains separate from confidence routing and rationale collection. Prompts can request suggestion behavior, but instructions do not enforce permissions.

One label-only test can expose the three separate decisions

Use an internal triage label that has no customer-facing, access, financial, or code effect. Configure only the add-labels safe output, set issue-intent: true, compile with gh aw compile, and keep the repository automation level recorded with the results. Do not include assignment, closure, field updates, issue type changes, pull requests, or code pushes in this test.

Create three clearly identified test issues. The first should be an obvious match for the label rule. The second should contain conflicting or incomplete signals, making it an ambiguous match. The third should sit outside the rule and must remain unaltered. These are constructed test cases, not reported product outcomes.

The test objective is to observe the full result for each case: whether the label applies, waits as a suggestion, produces no change, or causes the workflow to fail because required metadata is missing. Record the rationale and confidence when present, then inspect pending suggestions directly and through is:issue is:open has:suggestions. Do not assume the obvious case will be rated high or the ambiguous case will be held; confidence calibration is one of the preview's unknowns.

Check authority separately. Inspect the agent or workflow permissions and confirm that the test actor has only the issue access needed to add the internal label. Then run a negative permission check with issue-write authority removed, if your test environment permits it, with the objective of confirming that no label change can be made. That result tests permission enforcement; the three issue cases test evidence and routing.

Enable, limit, or wait based on the evidence you need

Enable required issue intent for a narrow, reversible internal issue change when every accepted output needs an explanation and confidence rating, your repository has the relevant preview controls, and someone will inspect both automatic changes and suggestions. Keep the first repository level conservative until the bounded test shows how its real issue language routes.

Limit the preview to required metadata plus Full control or Cautious when you want evidence before broader automation, or when reviewer burden and confidence quality remain unclear. Wait if the needed repository setting has not reached you, if your Copilot automation use falls outside its documented repository and account availability, or if the workflow depends on actions beyond the supported issue mutations.

For teams that need to connect this configuration to permissions, review ownership, and exception handling, BaristaLabs can help implement one bounded workflow through process automation. The useful next decision is the smallest issue change you can test without granting the agent broader authority than the work requires.