An agent needs an owner after the launch

The workflow keeps changing after acceptance

The client signs off, the agent goes live, and the project moves into maintenance. A few weeks later, a policy changes, a CRM field is renamed, and the model provider updates a default. The original acceptance test still passes because it uses an old dataset and a short, clean conversation. Customers are now reporting a different experience.

An agent’s behaviour depends on more than its source code. Prompts, model settings, tools, retrieved information, user traffic, and surrounding business rules all affect what it does. A deployment process that watches only code changes leaves several routes for behaviour to change without a meaningful review.

Responsibility can become unclear at exactly the wrong moment. The consultant understands the orchestration. The client owns the policy. Another vendor controls the business application. When performance declines, each party can reasonably point to a different component.

Before launch, assign an owner for the service as a whole. That person does not need to implement every fix, but they need access to evidence, authority to reduce exposure, and a clear route to the people who control each dependency.

Maintenance should therefore be described as ongoing validation of the service, with an agreed scope and response process. “The automation is running” is too weak a definition when the automation can keep running while doing the wrong thing.

Small changes can produce behavioural regressions

Anthropic’s April 2026 account of Claude Code quality reports described three separate issues involving reasoning defaults, context handling, and a prompt change intended to reduce verbosity. The API itself was unaffected, and the issues had been resolved by the time of the report. The example shows how changes around a model can alter the user experience even when the underlying API is operating normally. [1]

For a business agent, a similarly modest change might shorten answers by removing an explanation customers need, or reduce context by dropping a fact required later in the workflow. A technical improvement can become a product regression when it is evaluated against too narrow a set of cases.

Version the components that influence behaviour. A release record should identify the prompt, model configuration, tool schema, policy version, and relevant data snapshot. Without that information, comparing a good run with a bad run becomes guesswork.

When the system uses live information, full reproducibility may be impossible. Preserve enough of the actual inputs and tool results, within approved retention rules, to reconstruct the decision. A link to a document that later changes is not the same evidence as the version the agent saw.

Changes also need targeted tests. If the team modifies context management, include long conversations and resumed sessions. If it changes the refund policy, test eligibility boundaries and exceptions. A general regression suite is useful, but it should not replace tests that exercise the specific mechanism being changed.

The client should know which changes require notification or acceptance. A new model or broader permission scope may change the service more than a visible interface adjustment.

Monitoring needs to lead somewhere

Logs help only when someone can use them to diagnose and improve the workflow. A dashboard full of successful requests can coexist with incorrect outcomes. The monitoring plan should include signals tied to the business task, such as repeat contact, corrected records, failed handovers, and unsupported completion claims.

Harness’s State of Agent DLC 2026 report surveyed 700 technology professionals at large enterprises already using agents at least in a live proof of concept. It found gaps between confidence in testing and consistently enforced release controls. The sample was screened for committed adopters, so its figures should not be treated as adoption rates across all companies. [2]

For a smaller team, the response does not need to be a large governance program. A weekly review can examine new failure types, changes in important outcome measures, and cases that staff had to repair. Each finding should result in a decision, a test case, or a documented reason to take no action.

Review by workflow and user group. A stable overall score may hide declining performance for one language, account type, or integration. Keep enough context to identify these differences without collecting unnecessary personal information.

Also distinguish a changed workload from a degraded system. If customers suddenly ask more difficult questions, the agent’s success rate may fall even though its behaviour on familiar cases is unchanged. That still requires a product response, but the fix may be new coverage rather than a rollback.

Alerts should have an owner and an expected response. An alert that nobody can act on becomes background noise. For serious errors, define whether the service pauses, falls back to a narrower workflow, or transfers work to staff.

Coding agents need the same operational memory

When coding agents help maintain an operational agent, the feedback loop can become much faster. It can also become harder to control if the coding agent receives a vague complaint and changes several components without a reproducible case.

Anthropic’s November 2025 engineering account of long-running agents describes the importance of persistent progress records and incremental work across sessions. Its examples concern software development, but they offer a relevant design direction for maintenance: preserve what was attempted, what remains unfinished, and how completion was checked. [3]

A well-specified maintenance task should include the failed scenario, expected outcome, relevant versions, and observed evidence. The coding agent can then reproduce the failure, propose a narrow change, and run the affected tests. A human reviewer should be able to inspect the same material without reconstructing the original conversation.

Do not allow the improvement process to redefine success simply to make the test pass. If a coding agent changes both the workflow and its grader, those changes need separate review. Otherwise, the apparent repair may only weaken the acceptance rule.

Deployment should remain progressive. Start with a limited portion of suitable work, compare the result with the previous version, and expand only when the evidence supports it. Rollback also needs careful meaning: reverting code does not reverse messages already sent or records already changed.

The maintenance plan should include repair of those effects. If a bad release changed customer data, the response needs a way to find affected records, determine the correct state, and complete the correction. Restoring the old prompt is only one part of recovery.

For consultants, this can become a clearer ongoing service. The offer is defined around monitored workflows, reviewed changes, and validated improvements, with limits on volume and response time. Clients can then see what the maintenance fee buys and which responsibilities remain with their own team.

Connect production evidence to the next safe change

The product opportunity is a continuous path from observed failure to reproducible test, reviewed fix, and measured rollout. A future system could collect approved traces, group similar incidents, build candidate scenarios, and ask an operator to confirm the expected outcome before those cases become release requirements.

Human developers and coding agents would use the same environment and receive the same evidence. The system could track which failures a change addresses, where it introduces uncertainty, and whether live outcomes improve afterward. ActOut’s emphasis on simulation and ongoing validation is relevant to this direction, with its value resting on how faithfully the test environment represents the client’s work.

Another product could maintain a record of behavioural changes across models, prompts, policies, and integrations. That would help teams answer a difficult operational question: what changed between the last dependable version and the current one? Better answers would make maintenance faster and make expanding agent autonomy a decision grounded in accumulated evidence.