Work stops midway
Before pressing “run again,” has the ticket already been created?
An AI investigates a customer inquiry and creates a support ticket. The connection drops during creation, and the screen shows an error. Should the person press the button again or first check the external system? This is a hypothetical recovery scenario. Even when the AI cannot reply, the other system may already have committed the change.
As agents use external tools and continue longer tasks, they need mechanisms for handling failures midway. Following May announcements from Foundry and LangGraph Platform, Amazon Bedrock AgentCore announced preview capabilities in July for runtime infrastructure, permissions, and observing execution. Components for operating work are being offered alongside capabilities for generating answers.
This article uses AgentOps to mean the work of handling execution records, control, recovery, and improvement together. Its argument is that visible records must support decisions about what has committed, what remains unknown, and what may happen next. If users have to investigate from the beginning every time, the value of the agent’s partial progress is also lost.
Services for operating agents
Delegating runtime and history does not settle business completion
The July 16 AgentCore announcement describes individually usable services including Runtime for execution, Identity for access, and Observability for following runs. Its support example identifies a customer through CRM, retrieves orders and product information, and prepares a reply. The prototype simulates internal systems with Python functions. It is not a measurement of safe recovery in live customer support.
Foundry’s Developer Essentials also describes tracing, evaluation, and monitoring alongside tool connections. A team choosing a managed service can compare which history is retained and which failures can be investigated, as well as whether it can query a model. A running environment, a generated answer, and exactly one created ticket remain different things to verify.
This difference also affects decisions to add tools. Moving from a document-reading prototype to ticket creation or sending replies adds external state to check after a failure. The available connections need to be considered together with the records and operations required for recovery.
Investigating the cause
Break “the AI got it wrong” into places that can be repaired
Anthropic’s research-system engineering report describes users complaining that agents missed obvious information, without developers knowing whether queries, source selection, or failing tools were responsible. Adding production tracing helped diagnose and fix causes. This is a vendor’s engineering account, not an experiment showing the same reduction in repair time across organizations.
The July CloudWatch preview offers latency, usage, errors, and tracing across knowledge retrieval, tools, and models. If a search failed to retrieve the needed policy, a team would investigate its corpus or retrieval method. If the correct policy was supplied but ignored in the answer, a different part of the application needs repair.
The operating recommendation is to link inputs, retrieved evidence versions, tool arguments and results, and execution versions. The final answer alone makes it hard to distinguish a wrong input from evidence lost midway. Conversely, a lengthy history that is not linked to the external creation result still cannot settle whether the opening ticket exists.
Resuming midway
Returning to saved execution differs from reversing an external change
LangGraph Platform, generally available on May 14, persists state for long-running work and for waiting on human input. Its Studio description includes checkpoints for returning to a failure point, editing, and rerunning. Responses API background mode likewise provides a way to start long work and inspect its status afterward. These are components for making waiting and resumption accessible to an application.
In our hypothetical ticket example, returning to a point before creation could restore the agent’s internal “not yet created” state while the external ticket already exists. Running the creation tool again could produce two tickets with the same content. An execution checkpoint cannot be treated as a mechanism for undoing external changes.
A resumption point therefore depends on more than step order. Distinguish rereading material from committing an external change. Even rereading can yield different results after document updates, while an external write requires checking whether the earlier change committed. Records should also show which input and environment versions will be used to resume.
Avoiding repeated changes
Distinguish failure from an unknown result after a connection loss
Stripe’s API-design explanation covers unknown outcomes after communication failures, including a successful operation whose response is lost. It describes resending the same operation identifier so the server can avoid duplicates and return its result. Idempotency means repeated calls do not multiply their effects. This is a problem in ordinary APIs too, rather than a failure unique to agents.
If the external ticket system supports this mechanism, our example can link the operation key to the committed ticket ID. A retry must check whether it can use the same creation content and key, including the key’s validity period and the destination’s processing conditions. If the AI reasons again, produces similar prose, and sends it with a new key, the server may see a separate creation request.
When identifiers cannot reconcile the outcome, an empty search immediately afterward does not establish nonexistence. The other system may still be processing or may take time to reflect the result in search. Report “the outcome cannot yet be confirmed,” rather than “creation failed, so create again,” and hand a person the earlier operation content and last verified state. Urgency makes preserving uncertainty more necessary.
Choosing where to stop
Approval, stopping, and cancellation require different checks
Bedrock’s human-confirmation example shows inputs presented and edited before creating a leave request. It provides material for linking a proposed action to the action a person confirms may execute. Applied to customer support, the ticket or reply content should be linked to the actual inputs immediately before sending.
If the prose or recipient changes after approval, the earlier approval may no longer apply. Permissions may also change during a long wait, requiring execution conditions to be checked on resumption. Beyond providing an approval screen, retain which content and operation the person approved.
When designing a stop, distinguish future tool calls from operations already sent. Whether a sent reply can be recalled or a created ticket should be closed depends on the external system and business judgment. Cancellation is another operation whose permissions and outcome need checking. A stopped screen should not imply that every change has been reversed.
Choosing records to retain
Recovery evidence and complete conversations deserve separate consideration
Investigating a cause does not always require retaining every conversation in full. Anthropic describes observing decision and interaction patterns without monitoring individual conversation contents. CloudWatch’s announcement also states that collected and stored telemetry incurs charges. Adding records increases both investigable detail and the information and costs retained.
This article recommends first defining the fields needed for recovery decisions. Link operation and external identifiers, committed outcomes, permissions used, and approved input versions to the same run. If sensitive prose is necessary for investigation, define who may inspect it and how long it is retained, and exclude credentials themselves from history. Recovery staff being able to find evidence differs from everyone being able to read everything.
Make gaps visible when only part of the history remains. Segments using unrecorded tools or missing an external response should not appear identical to confirmed completion. Knowing the boundaries of available evidence lets a person avoid unnecessary investigation and concentrate on unresolved parts.
From recovery to improvement
Help the next person avoid investigating the same failure from scratch
After recovery, ask what missing information made the decision slow. Turn a problematic search condition into an evaluation case, or a lost response into a test of resending the same operation. Comparing recorded input, model, tool, and external-data versions makes it easier to check whether a repair works under the same conditions. Separate repeating real external actions from reproducing a cause in a test environment.
Alongside answer correctness, examine whether unknown outcomes were overlooked, duplicates were created, or a person spent minutes reinvestigating. These are proposed evaluation criteria, not measured product comparisons from the sources. They help move from collecting records to reducing people’s recovery burden.
Observe
Use inputs, evidence, tools, and execution versions to locate what needs repair.
Reconcile and resume
Distinguish checkpoints from externally committed state to avoid repeating changes.
Control
Check approved content, changes remaining after a stop, and permission to cancel.
Improve
Turn causes into evaluation cases and reduce the next person’s investigation.
AgentOps is valuable when even failed work leaves confirmed facts distinguishable from unknowns, allowing the user to choose the next operation. Connecting execution history to recovery decisions and improvement makes partial progress something people can continue.