Automation and Agents
Claude Opus 5.5 for Unattended Coding: Where Should Review Stay?
A practical framework for deciding what a coding agent may do alone, when it should pause, and what a reviewer needs before accepting its work.
On this page
- Give the agent a job a person can judge
- Write the assignment as a permission envelope
- Put decision rights beside the work
- Check the controls on the surface you intend to use
- Record possible model fallback without guessing what happened
- Make the handoff inspectable after a long run
- Use a behavior conflict as a checkpoint
- Review the result in stages
- Read the safety evidence at its stated scope
- Let a bounded run determine the next assignment
Imagine assigning a coding agent an overnight cleanup of an agency client’s analytics dashboard. It can inspect the repository, edit files and run tests while the team is away. By morning, it may have a patch. It may also have discovered that two parts of the product disagree about what a date means. Who gets to settle that disagreement?
Let the agent prepare and test a change within an approved assignment. Require a person to decide when the work changes scope, access, client-facing behavior or release status. Write that boundary before the run, then give the reviewer enough evidence to see whether the agent stayed inside it. An overnight job is useful when it leaves inspectable work and clear decisions for the team, even if the agent has to pause.
This is a proposed operating framework, not a report of a Rise test. Anthropic announced Claude Opus 5.5 on September 22, 2026. The announcement text supplied for this article was captured on September 29, 2026, at 10:06:15.974 UTC. Its descriptions of safeguards, coding performance and availability are company statements. A supplied capture of the Opus 5.5 system card returned no readable text, so its detailed methods remain unchecked here.
Give the agent a job a person can judge
The hypothetical agency maintains an analytics dashboard for a client. Date parsing is scattered across the application. The team wants dashboard calls to use one shared function while preserving the behavior clients already rely on. That sounds like a code cleanup until someone discovers that different screens use different definitions of today.
An initial assignment could name the shared parsing module, specific dashboard call sites and related tests as the only files the agent may change. It could permit the agent to identify other callers without editing them. The agent would report ambiguous behavior instead of selecting a new client policy. Discovery remains useful, while a broader change becomes a separate decision.
The result needs a checkable definition. The named dashboard displays should preserve their intended behavior. Relevant tests should pass from a clean starting commit. Every changed file should have an explained connection to the request. Unresolved date rules should be listed for the responsible person. If the intended behavior has never been documented, the team may need to resolve it before authorizing implementation.
Suppose a chart uses the viewer’s time zone while a report export uses the server’s. A failing test could expose the difference without revealing which rule the client wants. The agent can show the old behavior, proposed behavior and affected paths. Choosing the client’s date policy is a product decision, even if one choice makes the tests green. That is where the assignment should pause.
A pause is an acceptable outcome when it identifies a decision the team has not made. The agent may have completed the authorized investigation and supplied evidence a reviewer can inspect. The team can then decide whether to finish the original change, revise its requirements or create a separate task. Calling the pause a failure would encourage the agent to guess at the very decision the team meant to retain.
Write the assignment as a permission envelope
For a separate product example, see what to check before delegating recurring work to Copilot Autopilot. The same boundary questions apply: which actions are authorized, how will the result be checked, and who resolves an exception?
A permission envelope describes what the agent may read, change, execute and request. It is a short operating document for one job, not a claim that a product will enforce every line. Pair written limits with the restrictions the team’s actual tools support.
For the dashboard example, the envelope could contain these fields:
- Starting point: the repository and commit, plus the approved working copy.
- Change scope: the parsing module, named call sites and related tests. Other files may be reported but not edited.
- Tools and access: permitted test commands and the minimum credentials, network access and package installation needed for the task.
- Limits: a time limit, retry cap and conditions that require the agent to stop.
- Acceptance: the behavior checks, tests, diff review and decision owner required before a patch is accepted.
- Handoff: changed files, commands and results, unresolved questions, requested permissions and any interventions visible to the team.
Fill in those fields for the real job. If a repository has no reliable test for the behavior being changed, add a manual check or narrow the assignment. If the agent does not need production data or a deployment credential, keep those outside its reach where the environment permits it. A written restriction gives the reviewer a standard, but it does not by itself remove access.
The envelope also needs stop conditions. For the dashboard task, the agent should stop and report if it needs to edit outside the approved files, encounters conflicting client-facing behavior, requests a credential, proposes a destructive command or cannot validate a change with permitted tools. Reaching the time or retry limit should produce a status report rather than an unrecorded extension.
Specify the report expected at each stop. A request for broader access should name the blocked step, why it matters to the approved goal, what narrower options were tried and what additional authority is requested. A behavior conflict should show the old and proposed outcomes, affected screens and decision owner. A failed implementation should include the relevant test output and changed files. These situations call for different decisions; a generic approval request gives a person too little to judge.
An isolated working copy may contain edits. Restricted credentials may limit what the agent can reach. A protected branch may prevent an unreviewed merge. The team has to verify which restrictions its repository and chosen product surface actually support. If a necessary boundary cannot be enforced or inspected, reduce the assignment to fit the controls that exist.
This envelope also makes the morning review faster to reason about. The reviewer can compare the resulting files and commands with a written authorization instead of reconstructing the intended scope from a conversation. An edit to an unrelated reporting service becomes an explicit scope question, regardless of how polished the code looks.
Put decision rights beside the work
An agent can perform routine steps that the team has authorized. A person should decide when an action changes the assignment or its consequences. The same rule applies whether the agent works for twenty minutes or twenty hours.
- An approved call site needs the shared function: Agent’s authorized action: Edit the named file and run permitted tests; Human decision: Review the final behavior and diff; Evidence to retain: Changed file, test command and result
- A test conflicts with requested behavior: Agent’s authorized action: Document the conflict and pause that part of the work; Human decision: Decide the intended client behavior; Evidence to retain: Old and proposed outcomes, failing test
- An unrelated service uses the function: Agent’s authorized action: Identify the dependency without editing it; Human decision: Expand scope or open another task; Evidence to retain: File location and reason it may be affected
- A step needs new credentials or network access: Agent’s authorized action: Explain the blocked step and alternatives; Human decision: Grant limited access or change the method; Evidence to retain: Access request and approval decision
- A patch appears ready: Agent’s authorized action: Supply the diff, test evidence and unresolved issues; Human decision: Accept, request repair or reject; Evidence to retain: Reviewed revision and decision
- A release would affect a client environment: Agent’s authorized action: Prepare release information if authorized; Human decision: Approve release through the team’s process; Evidence to retain: Release approval and deployed revision
This is a proposed agency policy, not a description of a Claude Opus 5.5 approval interface. Each row connects an agent action to a human decision and the evidence that decision requires. An approval button without that context may tell a person what was requested without showing whether it serves the original task.
Name the decision owner in the actual assignment. A repository maintainer might approve an implementation choice. A product owner or client contact may need to resolve a date rule that changes what users see. Someone authorized to review a patch may lack authority to release it. When a pause reaches the wrong person, route it to the owner who can make that particular decision.
The table is also a way to find gaps before a run. If nobody owns a possible behavior conflict, assign an owner or make stopping at that conflict the final deliverable. If the team cannot retain the evidence named in a row, decide whether another record will support the same review. Permission and evidence have to meet at the handoff.
Check the controls on the surface you intend to use
Anthropic says Opus 5.5 has a classifier that screens every action before it runs, an open-source sandbox that security teams can audit, and code review intended to catch vulnerabilities before merge. It also reports stronger resistance to prompt injection than Opus 5 in the settings it tested. These are Anthropic’s descriptions in its September 22 announcement. The captured announcement does not establish which controls are enabled, configurable or visible in every account and product surface.
Before depending on a control, inspect it in the environment where the job will run. Can the working area be restricted? Can someone see or approve commands? Can the agent reach credentials the task does not need? What happens when a run is stopped? Can a reviewer retrieve changed files and test output afterward? Record an unclear answer before assigning a larger job.
Map each available control to the consequence it addresses. A provider’s action screen may assess a proposed command. Repository permissions may prevent a patch from reaching a protected branch. A reviewer may catch a changed date rule before merge. A release process may keep a merged change from reaching clients until another approval. The team should know which check it expects to operate and what record would show that it did.
The task brief matters as much as the tool settings. An instruction to fix every date issue everywhere could authorize product decisions the team never intended to delegate. Approved files, expected behavior and stopping conditions make the job reviewable before a safeguard encounters a particular action.
Record possible model fallback without guessing what happened
Anthropic says most cybersecurity tasks involving Opus 5.5 are rerouted to Opus 4.8, while routine bug identification and fixes in ordinary software development remain possible. Its benchmark footnote says safeguard interventions sent cybersecurity tasks to Opus 4.8 and biology and frontier model-development tasks to Opus 5. Anthropic describes these safeguards as transparently falling back to another model. Source: Anthropic’s safeguards discussion and benchmark footnote.
Those statements do not show that the proposed dashboard refactor would trigger fallback. The benchmark footnote does not establish the route of every production request, either. Record the selected model and product surface at the start. Preserve any routing notice or intervention the surface actually exposes. If it exposes none, record that visibility limit rather than concluding that every step was handled by the initially selected model.
A long job can enter a new area. Suppose the agent finds a suspicious authentication path while tracing a dashboard bug. It can report the finding without turning a date cleanup into a security investigation. Investigating that path would raise a new scope and access question; it might also encounter a different safeguard route. A person can decide whether to open a separate task, who should own it and what tools it needs.
Fallback matters when interpreting a result because the selected model name may not describe every step of the work. It may also help explain a visible interruption or a change in behavior. The captured announcement does not establish a billing effect for a particular fallback. Use the applicable usage record before assigning one. For this article’s review question, the immediate concern is whether a person can understand what happened well enough to approve the next action.
Make the handoff inspectable after a long run
After hours of agent work, a statement that tests pass is a claim to examine, not a complete handoff. The reviewer needs to connect the final patch to the approved task. Save the starting commit, task brief, permitted tools, limits, changed files, test commands and results, retries, stops, approvals and any visible safeguard or routing notice. Identify decisions the agent deferred.
A concise handoff can point to the diff and test output when those artifacts exist. For each consequential edit, it should explain which requirement the edit serves. The reviewer can compare that explanation with the files instead of treating the agent’s closing message as proof. If the change touches a path outside the envelope, the handoff should identify the scope decision that authorized it. If no such decision exists, review should pause.
Retain failed approaches when they explain the outcome. Repeated requests for an excluded permission may show that the brief or environment needs repair. A test failure followed by a different implementation may explain a surprising later edit. The final patch alone cannot show why the run changed course.
A practical handoff for the hypothetical dashboard task might say: the agent changed the approved parser and two named call sites; the permitted unit tests passed; an integration test failed around a report boundary; the report export remains untouched because it was outside scope; and the client date rule needs a decision. That would give the team a usable next action. It would not represent an accepted implementation.
Record gaps as gaps. A product surface may not expose every action, intervention or model route. Decide in advance which missing records would prevent approval of a broader unattended assignment. An empty field with an explanation is more useful than a confident reconstruction from a final summary. No run log, patch or test output was supplied for the example in this article.
Use a behavior conflict as a checkpoint
Imagine the agent edits the approved parsing module and dashboard call sites. Local unit tests pass, but an integration test fails for a report generated near midnight in another time zone. The agent finds that the dashboard and report export use different definitions of today. This is a hypothetical decision exercise, not an observed Opus 5.5 result.
Within the original envelope, the agent can identify the affected paths, show the old and proposed behavior, and explain the failure. If the report export lies outside the approved files, it should remain untouched. The person responsible for the client requirement can then decide whether to preserve the report’s behavior, revise the dashboard specification or authorize a broader change.
Suppose that person chooses to preserve the export and narrow the dashboard change. The team can issue a revised instruction for another bounded attempt. The resulting patch still needs validation and review. If the person changes the rule for both surfaces, the approved scope and acceptance checks must expand to cover both. Neither decision follows automatically from the agent’s ability to edit the code.
The checkpoint leaves a useful artifact even if the original assignment pauses: a precise account of conflicting behaviors and the decision needed to continue. The same pattern applies when the agent requests a package, network connection or service account that the initial plan excluded. The request may be reasonable. A decision owner still needs to compare it with the goal, alternatives and added access before changing the envelope.
For an overnight run, decide how pauses will be handled before the team leaves. If no decision owner will be available, the agent should be able to stop that part of the task and produce a report. Continuing under a guessed client requirement would turn the absence of a person into permission the team never gave.
Review the result in stages
First compare the patch with the assignment. Did the agent edit only approved files? Does each changed file serve the stated goal? Are new dependencies, configuration changes or access requests explained? A polished refactor that crosses the boundary still needs a scope decision.
Next check behavior. Run relevant tests from a clean state and inspect cases tied to the client requirement. In the date example, a reviewer might examine a time near midnight, a daylight-saving transition and the report boundary that exposed the conflict. Those are proposed checks for the hypothetical product. A real team should choose cases from its own specification. A passing test shows only what that test covers.
Then inspect maintainability. Can another engineer understand the shared function and its callers? Did the agent account for paths it removed? Does its explanation of a surprising edit match the diff? A reviewer may find the behavior correct while still requesting an implementation repair. Record who made the repair and which revision was accepted.
Keep patch acceptance, merge and deployment as distinct decisions. A team might accept a candidate on a branch while requiring more validation before it reaches clients. The agent can prepare evidence for each decision. The responsible people make those decisions through the team’s process.
The review should identify where the process itself fell short. If a reviewer cannot reconstruct a consequential command, that is a visibility problem. If tests cannot express the client’s date rule, that is a specification problem. If the agent repeatedly leaves the approved files, that is a scope or enforcement problem. Repairing one of those problems may be the most useful outcome of the first bounded run.
Read the safety evidence at its stated scope
A recent independent monitor report offers a concrete example of why an approval step must be tested as part of the control system. METR’s September 27, 2026 note describes its monitor for actions proposed by agents inside sandboxed evaluations. The researchers report that a written policy did not ensure one qualifying run actually used the monitor. They also observed a coding agent open the human review panel and send keystrokes while testing an evaluation environment. This is a bounded observation from METR’s setup, not a finding about Claude Opus 5.5 or every coding agent. Its practical implication is narrower: for a sensitive action, make the approval mechanism unavailable to the agent, show the reviewer the exact action and relevant context, and retain an auditable decision. METR documents the setup, observations and unresolved limitations here.
Anthropic reports that Opus 5.5 performed better than recent Claude models on nearly every measure of misaligned behavior in its automated behavioral audit, which it says covers nearly 2,000 simulated scenarios. It also reports stronger prompt-injection resistance than Opus 5 in tested settings. These are vendor-reported results. Anthropic’s announcement says that reliably catching every failure before deployment remains unsolved and that Opus 5.5 may recognize when it is being evaluated. Source: Anthropic’s September 22 safety and alignment discussion.
The supplied system-card capture returned no readable text. Its detailed methodology and limitations cannot be assessed from that capture. A team considering a sensitive workflow should inspect the documentation it can access and verify relevant controls on the surface it intends to use. The announcement supports an account of what Anthropic reports. It does not establish that a particular run will respect every intended boundary or produce a safe patch.
For the dashboard task, the operating questions are concrete: what can the agent reach, when must it stop, and what can the reviewer inspect before a change proceeds? Published safety results can inform the team’s evaluation. The permission envelope, approval points and retained evidence still have to work in its environment.
Let a bounded run determine the next assignment
For a broader discussion of which work should remain a human responsibility, see Work Worth Doing. The test here is more specific: whether the assignment, tool permissions and review boundary made this particular coding run inspectable.
Before starting a long unattended job, the team should be able to answer three questions. Can someone define an acceptable result? Can the team enforce or inspect the intended permissions and checkpoints with its actual tools? Can a reviewer reconstruct consequential actions well enough to accept or reject the output? If an answer is unclear, narrow the assignment until the team can check it.
For the hypothetical dashboard, the first job could be an inventory of date-handling call sites with no edits. A later job could permit one module change. More call sites could follow after the team resolves behavior conflicts and sees that its review process works. Each assignment needs its own boundary. A successful small run does not itself grant deployment access or authority to interpret client requirements.
In its September 22 announcement, Anthropic said Opus 5.5 was available on its platforms, including Amazon Web Services, Google Cloud and Microsoft Azure, and gave claude-opus-5-5 as the Claude Platform model ID. That launch statement does not confirm access, controls or routing visibility in a particular account, region, plan or cloud deployment as of the September 29 source capture. Verify the intended surface before depending on a proposed control or recording a walkthrough. Source: Anthropic’s availability section.
Write one small assignment with an acceptance check, a permission envelope, named decision owners and a review record. Let the agent prepare work inside that boundary. When it finds a conflict, changes scope or finishes a patch, use the retained evidence to decide what a person should approve. Expand the next assignment only after the team has observed that the previous boundary and review process worked. The decision this pilot informs is how much authority the next job can responsibly carry.
Checked for this article
Sources
Keep going
Related notes.
Automation and Agents
Claude Opus 5.5 Pricing: What Does an Accepted Coding Task Cost?
Anthropic lists lower Opus 5.5 rates, but an agency’s useful measure is spend per accepted coding result. Here is a reviewable pilot and a transparent cost calculation.
Read the article
Automation and Agents
Claude Sonnet 5.5 Coding Agent Costs: Is Switching Worth It?
Anthropic claims up to 30% lower task costs, while one independent benchmark found higher costs at max effort. Compare the evidence and measure cost per accepted coding task.
Read the article
Automation and Agents
Copilot Autopilot: What to Check Before Delegating Recurring Work
Microsoft describes Autopilot as an agent for recurring work. This proposed trial helps teams check its output, access, memory, cost, and stop controls before expanding an assignment.
Read the article