The important release question for an operational agent is what it can change when its diagnosis is wrong. An agent may produce a persuasive plan and still target the wrong environment, act on stale information or misunderstand the intended scope.
This is an operational design guide. It does not reconstruct a specific company's incident or present a Hyperion client case. The purpose is to make an agent's authority and failure handling explicit before a product owner accepts the system.
Start with an action boundary
List the actions the product needs, the resources each action can reach and the person accountable for the result. Separate observation, proposal, approval and execution. An agent that may propose a production change does not automatically need credentials that can execute it.
Enforce the boundary in the execution system and its permissions. A label in a prompt can help describe the environment; it is not an access-control boundary. The executor should check the actual target and permitted operation before acting.
Bind approval to the actual change
An approval should identify the target environment, the proposed change, the expected before-state, any limits and an expiry. If the relevant state changes between review and execution, stop and reconcile it before proceeding.
For infrastructure managed with Terraform, review the generated plan as part of the existing release process. Terraform's prevent_destroy lifecycle rule can reject planned destruction while the rule is present, but it does not protect a resource after its configuration is removed. Treat it as one control within a wider permission and recovery design. HashiCorp's lifecycle guidance.
Avoid a generic “approve everything” control. Approval needs to remain meaningful when a task is retried, a tool returns partial success or a queued action runs later than expected.
Define success outside the agent's narrative
The agent's statement that a task succeeded is an observation to check. Use durable system evidence: the accepted change, the resulting state and the outcome that the product actually requires.
Record the action identifier, target, approved change, execution result and verification result. Redact sensitive inputs and outputs. An operational audit trail needs concise decision records and observable tool results; it should not depend on storing hidden model reasoning or unrestricted prompts.
Distinguish these states in the product interface:
| State | What has actually happened |
|---|---|
| Proposed | A change is ready for review. |
| Approved | The named authority has authorised the specified change. |
| Applied | The executor reports that the operation occurred. |
| Verified | An independent check confirms the expected result. |
| Recovery needed | The expected result is absent or the outcome is uncertain. |
Test failure handling before extending authority
Use a disposable environment and synthetic records to test a wrong target, stale before-state, expired approval, duplicate request, partial tool failure and lost acknowledgement. A lost acknowledgement must not cause an irreversible operation to be repeated blindly.
AWS's guidance on idempotent APIs explains why a timeout leaves the caller uncertain whether an operation occurred. A caller-provided request identifier can help distinguish a retry from a new intention, provided the execution system enforces the corresponding contract.
Test recovery separately. A backup is useful only if restoration has been exercised and the resulting data is checked. Some actions cannot be undone; for those, define a smaller permitted scope, an additional approval boundary or a reason to prohibit the operation.
For robotics and industrial systems, also examine the physical consequences and the independent controls required by the system design. A database permission model alone does not establish safe authority over equipment.
Put an accountable owner at the release decision
Before release, the product owner should be able to explain the permitted actions, remaining failure modes, evidence from refusal and recovery tests, and the conditions for reducing or removing the agent's authority. Establish who handles an incident and who can suspend execution.
Where the release decision is unresolved, a Product Decision Review can bring the product need, architecture and acceptance evidence into one decision. A broader delivery or leadership need can be scoped independently; a successful demonstration alone is insufficient evidence for operational acceptance.
