Issues

An issue is a recurring failure in a deployed agent: a named pattern, the runs that show it, and whether the last change fixed it. Review issues on the Issues page in Studio. Runs from amodal dev are not triaged.

Where issues come from

A run is flagged when any of these is true:

Every fifteen minutes the platform triages each flagged run once. The issue model writes a one-line diagnosis and assigns the run to a known issue or opens one. Scan now runs the triage for one agent immediately. Triage model calls are billed to the organization like online evaluators, and stop at the organization's billing limit.

Settings

The settings on the Issues page apply to one agent.

• Triage flagged runs. On by default. Turn it off to stop new issues and the model calls behind them.
• Model for issue triage and draft fixes. The agent's own model by default. Another model here does not change the model the agent runs on.

Lifecycle

Resolution is manual. Runs from older deploys or previews do not regress a linked fix.

Fixing an issue

The Fix section of an active issue shows three steps and offers the action for the current one:

1. Draft. Draft a fix asks the issue model to propose edits to AGENT.md and the .md files under agents/, skills/, and knowledge/. Drafting runs in the background. The draft reads the files where approving checks them: the production branch of a GitHub source, or the latest version of an Amodal-hosted source.
2. Review and approve. The draft shows its reasoning and a diff for each file. Approve and deploy commits the edits together with the issue's regression evals to the production branch, or as the next version of hosted source, deploys that commit to production, and links the deploy to the issue as its fix. It needs the same permissions as approving a proposal, and it offers the same choice of branch: on a GitHub or GitLab source, the fix can go to a separate branch for a pull request instead, without a deploy. With manual promotion, the deploy builds without serving traffic until it is made live. Discard drops the draft and returns to the first step.
3. Confirm resolved. While the fix deploy is built but not yet live, the issue shows that and offers Make live. Once it is live, check its runs, then Mark resolved closes the issue. If the fix deploy failed or is the wrong one, Link another deploy replaces it with a different production deploy.

A waiting fix is also listed under Proposals, where it can be approved or discarded the same way. If a file changed after the draft was written, approving fails and a new draft is needed. A fix for an issue that is resolved, dismissed, or merged cannot be approved until the issue is reopened.

A fix committed to a separate branch, or one whose deploy did not start, shows "not deployed", and the steps stay on Review and approve. Merge the branch into the production branch, deploy it, then use Link fix deploy. Draft a new fix starts over instead.

When the fix reached production another way, such as a merged pull request, use Fixed another way? under the steps: Link fix deploy links that production deploy as the fix, and mark resolved closes the issue directly.

Regression evals

Approving a fix turns up to five of the issue's runs into eval cases under evals/. Each case replays the user's request and is marked for review, because the recorded reply is the failure and must not become the expected answer. Add the assertions that describe the correct behavior before relying on the case. See Evals.

Approving preserves existing eval files and their assertions. Only missing cases are written.