Operate to improve: an agent should not grant itself more authority

If an agent makes a mistake, I want the platform to turn that failure into a reproducible test and a controlled improvement. I do not want it to rewrite its prompt, mark itself improved and expand its own permissions. The Operate-to-Improve loop is the system's change-management workflow.

The local prototype contains three useful paths: an improvement proposal with two evaluation gates, a deployment lifecycle with canary and rollback states, and an autonomy-promotion request routed through the shared approval system.

Follow one improvement proposal

A failed lead qualification becomes a regression case. A proposed change identifies the agent version, the failure it addresses, expected benefit and possible regressions. The lifecycle is:

proposed → scheduled → in_validation
  → gate_a_passed → gate_b_passed → promoted

A failed gate prevents advancement. That is implemented as workflow state, not a sentence in the agent's instructions. The next step is to make the gate depend on representative execution evidence.

What the current evaluation score actually means

The prototype uses a deterministic fixture to exercise the gates. It builds a small golden set and derives which cases pass from a supplied fraction:

cutoff = round(max(0.0, min(1.0, pass_fraction)) * n)
passing_ids = {case.id for case in cases[:cutoff]}

With ten cases, a requested fraction of 0.95 can round to ten passing cases. That demonstrates the gate's mechanics. It is not a measured 95% success rate for a reasoning model, and it should never be presented as one.

The next evaluator will run actual episode inputs against a candidate version, check resulting records and effects, and store individual verdicts. The aggregate is then derived from those observations. A second gate should bring a different check—such as held-out scenarios or a restricted live trial—rather than simply replay the same fixture twice.

Deployment and autonomy are separate decisions

A better prompt may be safe to deploy while retaining the same permissions. Permission expansion is another proposal. The prototype records that distinction through an autonomy profile and an approval request.

The local round trip shows an agent proposing a promotion, a held activation, and a human decision through Risk-to-Control. A self-approval attempt is denied by the separation-of-duties policy. Rejection leaves the promotion inactive.

Canary records need real routing behind them

The prototype can move a deployment through staging, canary and active states and exercise rollback transitions. Those records do not yet prove traffic was shifted between model configurations. The production deployment controller must connect state changes to actual routing and verify the result.

There is also a useful design lesson in the current local rollback helper: one path passes through active to reach a rollback terminal because the state machine lacks a direct edge. I would not use that sequence to activate a regressed release in production. A canary should be abortable while traffic stays on the last known-good version.

What to retain from a failed run

I want the source event, context object versions, selected actions, model and prompt versions, receipts, timing, cost and reviewer correction. Sensitive payloads can remain in controlled storage while the evaluation uses a redacted fixture with the same failure structure.

The correction should identify the business error. “The answer was bad” is difficult to test. “The agent proposed a credit after the annual allowance was exhausted” becomes a precise regression case.

A practical autonomy experiment

Start with a narrow action that is easy to reconcile, such as preparing a lead brief. Track review corrections and failure categories. After the evidence is sufficient, consider one bounded execution step. Keep a rollback route and an authority ceiling independent of the model.

The next article connects the loops. The principle carries through: improving one agent should not change the meaning of an invoice, a delivery receipt or another loop's permission policy. The shared contracts make local improvement possible without giving every experiment the power to redefine the company.

Replace a supplied pass fraction with episode evidence

The current improvement fixture proves a state-machine path. For a real prompt or model change, each scenario must run against the candidate and produce an observed action trace and final business state. The verdict should be derived from those observations. Supplying a desired pass fraction is useful for testing a gate, but it cannot measure whether the agent improved.

The reference evaluator begins with explicit expectations:

from company_lab.evaluation import verdict
from company_lab.business import release_allowed

case = {"state": {"invoice_balance": 400000},
        "forbidden_actions": ["send_paid_confirmation"]}
observed = {"state": {"invoice_balance": 400000},
            "actions": ["draft_partial_payment_update"]}
assert verdict(case, observed)["passed"]
assert not release_allowed(
    critical_failures=1, successes=99, trials=100,
    cost_minor=1000, cost_cap=2000, independent_approval=True,
)

The example gate refuses a release with a critical failure even when the aggregate success count is high. The thresholds are teaching configuration. A real release policy needs scenario coverage, adequate sample sizes and business-specific severity definitions.

Package the candidate so it can be reproduced

A candidate is more than a prompt string. It includes prompt version, model route, tool schemas, retrieval configuration, policy dependencies and relevant code revision. Store the evaluation dataset version and environment fixture hashes alongside it. A result that cannot identify what ran is not a useful release artifact.

The proposer should state the failure being addressed and expected trade-off. For example: “The agent confuses gross customer payment with net provider settlement; add explicit retrieval of the allocation record and evaluate partial-payment cases.” That is more testable than “improve financial reasoning.”

A change to policy or tool authority deserves a different review from a wording change. A better score on response quality does not justify adding payment permissions.

Shadow before canary

In shadow mode, the candidate sees the same permitted input as the baseline but cannot produce external effects. Compare proposed actions, required evidence, cost and review burden. This exposes disagreements before the new agent can contact customers or mutate business systems.

A canary is different: a bounded subset of eligible real tasks can execute under the new version. Persist assignment by task identity so retries do not switch versions unexpectedly. Exclude sensitive actions until their release conditions are met. A rollback changes future routing; it does not undo effects already completed.

The current platform represents release states but does not implement a full live traffic router. The next controller must support a direct failed-canary exit and preserve the earlier active version. It should never require temporarily promoting a failed candidate merely to make a rollback transition legal.

Learn from failures without promoting arbitrary memory

A reviewer correction can become a new scenario, a proposed instruction change or a tool-schema fix. It should not automatically become an instruction applied to every future customer. Some corrections are account-specific; some are exceptions; some may be wrong.

Reflexion explores using feedback in an agent's episodic memory to improve later attempts. The implementation lesson I take from it is to preserve actionable feedback with its context. In this business platform, promotion of that feedback into shared behaviour still needs versioning and evaluation. Reflexion paper.

Measure whether the change solved the intended problem

Report scenario-level differences, critical failures, cost per accepted outcome and reviewer minutes. Keep the holdout set separate from the cases used to tune the candidate. If the improvement only appears after repeatedly editing against the same examples, it may be overfitting the fixture.

The exercise is a cheaper candidate that passes routine enquiries but mishandles changed quote versions. The release should fail or remain limited to the tasks it is authorised and evaluated to handle. A global average should not hide a newly introduced commercial error.