Design the approval boundary before the agent.

An agent needs an operating model

During an incident, the valuable question is not simply whether an AI system can call a tool. It is whether the team understands the proposed action, its target, and who has authority to authorize it.

Anthropic’s June 2025 engineering account of its research system describes coordination, evaluation, and reliability challenges in agent systems. Its research example does not establish that the same architecture is appropriate for production remediation. For incident response, our starting point is a narrower workflow with an explicit approval boundary.

We also draw a useful distinction from Anthropic’s 2024 discussion of workflows and agents: a fixed sequence and a model-directed process have different control structures. A team should choose deliberately rather than call every automation an autopilot.

Separate investigation from write authority

Our proposed design gives investigation and remediation different permissions. Gathering context should not silently grant the ability to change production. An investigation can examine approved sources, connect recent changes to symptoms, and prepare candidate explanations. It should label uncertainty and identify the evidence supporting its recommendation.

The next artifact is a remediation proposal. We would include the target service and environment, the exact planned action, prerequisites, expected effect, a verification step, and an option for stopping or reversing the action. The reviewer should be able to say no without the system treating that decision as another obstacle to work around.

Approve a particular plan, not a general intention

A button labelled “approve” is not enough to define an approval model. Our recommendation is to bind an approval to the version of the plan that was reviewed. If the system changes the target, increases the scope, or substitutes a materially different action, return the proposal to review.

Proposed approval record
  Plan: rollback-api-release / revision 2
  Target: API service / production
  Action: restore the previous approved release
  Preconditions: reviewed deployment and health context
  Decision: pending human review
  Verification: compare service health after the action

This is an illustrative record, not a schema from a released EvolithCloud product. The important property is that authorization describes the thing that will execute.

Finish with verification and a record

Execution is not the end of a remediation workflow. We recommend recording the authorized plan, the actor approving it, the execution result, and the observed state afterward. If verification is inconclusive, say so. An unsuccessful tool call should not become a success message just because the agent completed its turn.

Evaluation should include ordinary successes and awkward cases: stale context, an unavailable tool, a declined plan, a plan that changes after approval, and a partially completed action. Write down the behavior expected in each case before expanding permissions.

Evolith Respond is being developed around human-approved remediation. These are our intended design principles. Access, retention, deployment, and security requirements should be discussed as part of a specific product evaluation.