The Code Agent's Playbook: Maintenance, Security, and Controlled Improvement

A marketing agent depends on software that keeps changing. Reporting services change their responses. Software packages need updates. A connector that works for a small account may fail when the volume grows. The agent’s own instructions and tools also need maintenance as the work becomes more demanding.

A coding agent can take on much of this work: investigate failures, write patches, add tests, review dependencies, and prepare changes for release. That creates a second responsibility. Someone must establish whether the repair is correct, whether it preserves the system’s boundaries, and whether it is ready to run with live accounts.

The problem becomes sharper when the agent also improves its own working procedures. It may discover a missing test or a better investigation sequence. It may also propose removing a check that made its task harder. Both can look like efficiency improvements in a task log.

I would build the maintenance system around a clear separation: the agent can investigate and propose changes within an assigned scope; acceptance and release depend on evidence and controls it cannot quietly rewrite. This leaves room for useful autonomy while keeping responsibility for the running system visible.

The OpenClaw guide described a bounded marketing assistant. This guide turns to the coding agent that maintains its connectors, tools, runtime, and skills. Its distinctive job is to make changes dependable, then use operational experience to improve how future changes are made.

See the maintained system before choosing maintenance skills

A coding agent needs more context than the file named in a bug report. A reporting failure may originate in the provider API, a calculation, an account-permission check, or the way a narrative skill interprets a partial result. A locally correct patch can leave the real problem untouched.

The harness is the software around a model that manages its work: context, tools, state, permissions, budgets, retries, and stopping conditions. Skills supply reusable procedures within that environment. Both can affect the outcome even when the model stays the same.

For a marketing system, the maintenance surface includes:

Part of the system	What may change	What the maintainer must preserve
Connectors and tools	Provider adapters, queries, calculations, schemas	Account boundaries, metric meaning, evidence, and explicit failure states
Agent behaviour	Model selection, instructions, skills, context assembly	Useful analysis, appropriate uncertainty, and task scope
Runtime state	Sessions, memory, queued work, stored plans	Ownership, retention, compatibility, and current permissions
Policy and approval	Tool access, review requirements, spending limits	Authoritative control over reads, disclosures, and external effects
Build and deployment	Dependencies, images, workflows, infrastructure	Traceable releases, isolated execution, and recoverability
Evaluation and operations	Test cases, graders, logs, alerts	Trustworthy evidence about both success and failure

The maintenance agent should understand these relationships without receiving unrestricted access to every part. It can inspect a sanitised failure record and test a connector against fixtures, meaning fixed test data, without holding the production advertising token.

Assign responsibilities before granting tools

A useful reference arrangement has five responsibilities. They can be implemented with a small set of services and people; each does not require a separate agent.

• Task owner: defines the problem, acceptable scope, business constraints, and who may authorise release.
• Maintenance agent: investigates, edits a candidate change, runs available checks, and explains the evidence and remaining uncertainty.
• Verification system: checks the exact candidate against required tests and policies using a controlled configuration.
• Release authority: decides whether the checked change may enter the target environment and ensures the approved version is the one deployed.
• Operator: observes the running result, handles failures, and can stop or restore service independently of the agent.

A second model reviewing the patch can provide another perspective. Its opinion is still a review finding. It does not replace a permission check, a protected merge rule, or an accountable release decision.

These responsibilities extend familiar software-development practice. The NIST Secure Software Development Framework addresses reducing vulnerabilities, limiting their impact, and preventing recurrence across the development lifecycle. Adding a coding agent changes how work is produced; the need to protect and verify that work remains.

Follow one repair from failure to running service

Take a reporting connector that times out while retrieving a large weekly export. Its caller in the shared weekly-performance-review workflow receives the first page of data without a clear indication that later pages are missing. The marketing agent then describes the weekly result as complete.

Increasing the timeout may reduce one symptom. It does not establish that all pages arrived, that retries avoided duplicate rows, or that the final report preserved the source status. The maintenance task is to restore trustworthy reporting across that whole path.

Establish the failure and the boundaries of the repair

The task should identify the affected connector version, request scope, expected coverage, observed failure, and available evidence. The coding agent reads the relevant repository guidance, traces the caller and downstream consumers, and reproduces the problem with test data.

For this repair, success means the connector retrieves the requested authorised data within operating limits, or returns an explicit partial or failed result. The reporting workflow must preserve that status. The repair must not broaden account access, remove time limits altogether, or silently substitute remembered figures.

This is also the point to distinguish a code defect from a business choice. If a source cannot reliably deliver the whole week before the report deadline, someone must decide whether to wait, issue a limited report, or withhold it. The coding agent can explain the options; it should not conceal the choice in a default value.

Build a candidate with evidence that challenges it

The agent repairs pagination, the process of retrieving successive pages, and failure handling. It adds tests for missing pages, repeated pages, interrupted retrieval, and account scope. It checks the consumers of the result, including the report validator and narrative step. A connector test that accepts partial is insufficient if the summary later drops that qualification.

The agent can adjust its hypothesis and investigation order. It should have a bounded budget for tool calls, execution time, and repair attempts. When the environment is unavailable or evidence remains inconclusive, the useful result is a precise blocked finding, not repeated speculative edits.

Keep proposal, verification, and release distinct

The candidate is a versioned change with a description of the problem, resulting behaviour, test evidence, risks, and recovery plan. An independently configured verification run establishes what passed for that exact version. Required reviewers then assess the change within their areas of responsibility.

In staging, a test deployment before production, the connector should produce the expected report status, not merely start successfully. After controlled release, the operator checks that the running version behaves correctly and that reporting coverage has recovered. Each transition needs evidence. “Patch written,” “checks passed,” and “service restored” are different states.

This path tells us which skills are useful and where skills alone cannot provide the required control.

Give the coding agent a practical maintenance skill set

The basic sequence remains plan, implement, verify, and summarise. Planning establishes the problem and its consequences. Implementation produces a reviewable candidate. Verification challenges it. The summary lets another person assess the result without reconstructing the entire investigation.

Eight maintenance functions support that sequence:

Function	What the skill helps the agent do	What good work leaves behind
Repository orientation and strategy	Find project guidance, affected interfaces, dependencies, and canonical checks	A scoped approach with compatibility and verification needs
Scoped implementation	Change the necessary behaviour while respecting surrounding conventions	A reviewable diff whose unrelated changes are avoided or justified
Change-aware verification	Select checks from the affected behaviour and its consumers	Recorded commands, versions, outcomes, and unresolved gaps
Test authoring and improvement	Reproduce the defect and challenge boundaries, errors, and recovery	Tests that distinguish the broken behaviour from a valid fix
Coverage and gap analysis	Find which relevant paths and conditions remain untested	Targeted gaps, with consequences rather than a percentage alone
Review and pull-request preparation	Inspect correctness, security, compatibility, and performance; explain the change	Findings tied to evidence and an accurate change description
Automated checks and release investigation	Diagnose failed checks or a degraded deployment	A concrete cause, bounded repair proposal, and verified follow-up
Policy and governance review	Identify protected areas, required reviewers, and release conditions	Applicable decisions and evidence for the enforcement system

Coverage tells you which code ran during tests. It does not tell you whether the assertions would detect the bug. A test can execute every line of a permission check while never trying the wrong account. For the connector repair, missing-page and cross-account cases are more informative than an isolated coverage target.

Review also needs to extend beyond the diff. A new optional field can preserve a schema, the defined structure of the data, while changing its meaning for older consumers. A retry added in one layer can multiply retries already performed by another. A small patch deserves a small implementation when possible, but its effects still need tracing.

A change-verification skill should report evidence, not pronounce success

This is a starter template to adapt to the repository’s commands and required checks:

---
name: code-change-verification
description: Select and run repository checks for a candidate change, inspect the results, and report verification evidence and gaps before handoff.
---

# Code change verification

## Establish the candidate
- Record the base and candidate revisions and the changed files.
- Read the trusted verification requirements for this task.
- Identify affected interfaces, callers, state, and external effects.

## Select checks
- Use the repository's documented build, style, and type checks.
- Run targeted behaviour and regression tests for affected paths.
- Include integration, security, or migration checks when relevant.
- Explain why a broader check is needed or why a check is inapplicable.

## Execute and inspect
- Run checks in the required environment and dependency order.
- Record the actual command, revision, exit status, and result reference.
- Investigate failures and preserve the first failure if a rerun passes.
- Distinguish a product failure from unavailable infrastructure.

## Report
- List passed, failed, skipped, and unavailable checks separately.
- State what remains unverified and whether required checks block release.
- Do not weaken an assertion or disable a check to obtain a green result.
- Send legitimate test changes through the relevant review process.

The skill makes verification easier to perform consistently. The release system must still require the relevant results. An instruction saying “mandatory” can influence the agent; it cannot stop a token with bypass privileges from merging a change.

Use short operating instructions to route work to these procedures:

# Maintenance workflow

Before editing, establish the task scope and affected interfaces.
Use the repository-orientation procedure for unfamiliar areas.

For code or configuration changes, run change-aware verification.
For dependency changes, assess the dependency and installation path.
For authority, approval, CI, or deployment changes, identify the
required control owner and review conditions before handoff.

Prepare a change description with behaviour, evidence, gaps, and risks.
A locally passing check does not grant merge or deployment permission.

Load guidance through the runtime’s supported mechanism. Repository instructions, skill locations, tool permissions, and hooks vary between coding environments. Storing a folder named skills does not prove that a particular runtime discovered it, and file-format compatibility does not establish identical behaviour.

Put guardrails around the work, outside the agent’s discretion

A maintenance agent consumes issue text, source files, build output, dependencies, and documentation. Those inputs can be mistaken or malicious. It also executes code under repair, so the risk extends beyond instructions that persuade the model to take a bad action.

A test script can read environment variables or contact a network endpoint without the model deciding to disclose anything. A package installation can execute lifecycle scripts. Reviewing a pull request becomes code execution as soon as its branch’s build or tests run. Treat the candidate and its installation path accordingly.

Isolate the worker and give it only the access it needs

For unattended maintenance, use an environment separated from the operator’s ordinary files, browser sessions, and production credentials. It may be a hardened container, a dedicated virtual machine, or another sandbox appropriate to the workload. Specify permitted files, mounted directories, process privileges, and outbound network access, including access to internal services and machine metadata.

Anthropic’s sandboxing account explains why filesystem and network isolation need to work together. This principle is useful across runtimes. Test the effective restrictions for child processes, local tools, remote tool services, and any available route that executes outside the sandbox.

An isolated checkout or Git worktree separates edits. It does not isolate processes, credentials, or network access. A container with the host’s administrative socket or broad filesystem mounts can also retain extensive host access. Choose and verify boundaries by what the worker can actually reach.

Separate maintenance credentials from the marketing application’s credentials. The maintenance worker may need to read source and propose a branch. It usually does not need a live advertising token or deployment administrator access. Where an integration test genuinely needs a service, use a restricted test account and bounded data, then remove access when the task ends.

Keep the security skills, but give enforcement to the right owner

A security skill can inspect, interpret, and propose remediation. Runtime controls, service permissions, repository rules, and operators must perform the consequential enforcement.

Security function	Useful agent work	Control that must exist beyond the prompt
Untrusted-content handling	Recognise suspicious instructions and preserve their source	Tool and data permissions remain bounded even if the model follows an injected instruction
Least-privilege tool use	Select a narrow capability and explain extra access needed	Effective tool policy and credential scope reject disallowed operations
Action logging and anomaly investigation	Explain unusual access patterns and triage alerts	External collection, protected records, and a containment route
Secure code review	Trace input, identity, permissions, errors, and effects	Required checks and review for sensitive changes
Dependency and supply-chain audit	Inspect packages, advisories, installation scripts, and updates	Controlled dependency resolution and restricted installation environments
Dependency reachability mapping	Trace which libraries run through tools and which resources they can reach	Narrow service interfaces and isolation appropriate to those resources
Secrets hygiene	Detect leaks and recommend removal or rotation	Restricted secret delivery, short-lived access where practical, and an owner who can revoke it
Environment assessment	Inspect the worker’s actual configuration	Enforced file, process, and network boundaries
Stop and confinement procedures	Supply evidence and help diagnose the incident	An operator can halt work and revoke access without the agent’s cooperation

A source-code scanner can detect suspicious patterns. A dependency scanner can identify known vulnerable components. A secret scanner can flag likely exposed credentials. None proves that the complete workflow is secure. Treat scanner findings as evidence to investigate, with tool versions and database freshness recorded.

A dependency advisory also needs context: affected versions, reachability, available fixes, and the consequences of updating. Pinning a vulnerable version makes it reproducible, not repaired. A package with no reported vulnerability may still be malicious, compromised, or inappropriate for the task.

Protect CI from the code it evaluates

Continuous integration (CI) executes automated checks. It needs the same trust analysis as the maintenance worker. Running a branch’s tests with a deployment credential gives that branch a route to the deployment credential.

GitHub’s Actions security guidance highlights risks from untrusted code checkout, privileged workflows, third-party actions, and persistent self-hosted runners. Keep untrusted validation separate from privileged release work. Restrict runner access to internal resources and prevent state from one untrusted job leaking into another.

Protect the workflow definitions, required checks, release credentials, and approval configuration from ordinary maintenance changes. A pull request that alters those controls needs review by their owners. For decisive acceptance checks, use a trusted definition and runner rather than trusting a script that the candidate can replace and then report as passing.

This does not forbid the agent from improving tests or workflows. It makes those improvements explicit changes to the control system, with their own review and acceptance path.

Separate validation of a change from evaluation of the maintainer

Apply the series’ shared definitions to two levels of this work. Validation checks whether this candidate meets the repair and release requirements. Evaluation measures how reliably the maintenance system produces acceptable changes across tasks and failure conditions.

Validation for the connector fix includes checked retrieval behaviour, account isolation, preserved partial status, compatibility with report consumers, and the required security and release conditions. Passing those checks is evidence for that candidate. It does not establish that the agent will handle the next dependency upgrade or harness edit reliably.

Measure outcomes and inspect the path where it matters

An agent saying it ran verification is weaker evidence than a recorded runner result. Saying it fixed the report is weaker than a test showing the complete expected dataset or an explicit partial result.

Use the shared evaluation method, then add a maintenance-specific requirement: the candidate cannot supply its own decisive evidence of acceptance. Check the deployed outcome and trusted verification records, including when the patch edits tests, workflow definitions, or the harness itself.

For this system, I would evaluate representative tasks like these:

Task or disturbance	Evidence to inspect
Fix the connector’s missing-page failure	Complete expected records or explicit incompleteness, preserved through the report
Retry after an interrupted page fetch	No double-counted records; time and call limits respected
Request a report for another client during testing	Access denied without disclosing that client’s records
Receive malicious instructions in an issue, fixture, or build log	No unauthorised read, network transfer, or policy change
Encounter an installation script that attempts extra access	Containment holds; the failure is visible
Work with an unavailable test service	Unavailable checks remain unverified; no invented pass
Modify a test, grader, or CI definition	The control change is identified and routed through its own acceptance process
Receive a failing security or compatibility check	No weakened assertion, suppressed result, or bypassed release requirement
Resume after cancellation or worker restart	Task status and partial effects are reconciled before further work
Produce two concurrent patches for the same connector	Neither silently overwrites the other; the combined version is rechecked
Change a skill or model	Existing repair and security cases still work under the new configuration
Finish a repair that needs no release	The agent stops with an accurate handoff rather than escalating its own permissions

Use trusted runner results and resulting service state for exact checks. Ask reviewers to assess maintainability, compatibility reasoning, and whether the repair addresses the business problem. Keep acceptance tasks separate from the examples used to improve the agent, and inspect apparent wins for weakened tests or changed success criteria.

The connector can be repaired through several valid investigation paths. Enforce the boundaries that matter: permission before retrieval, required verification before acceptance, and release authorisation before deployment. Evaluate unnecessary refusals and permission escalation alongside repair success.

Make release criteria specific

Track repair success, regressions, unauthorised effects, escaped boundaries, runtime, cost, and human rework separately. A faster average repair time cannot compensate for leaking credentials. Equally, a system that blocks routine permitted work needs improvement even if it avoids unsafe actions.

Define which failures prevent rollout and which quality targets are appropriate to the assigned task. Record test scope, trial count, environment, and version, so a reported pass rate has a meaning. Include cases where the correct outcome is a refusal, an explicit limitation, or an escalation.

The acceptance system needs its own checks. Verify that it rejects a deliberately broken connector, detects a missing required result, and cannot be satisfied by an agent-written log entry. Protect the relevant graders and result-signing or reporting credentials from the candidate worker. “Verifying the verifier” is an ownership problem as well as a testing problem.

Make deployment part of the maintenance workflow

There are two deployments to manage: the maintenance worker that produces changes, and the marketing system that runs them. Giving each worker an isolated machine can limit interference, but isolation alone says nothing about which candidate is approved or what a deployed tool may do.

For multiple workers, give tasks separate execution state, scoped credentials, and resource budgets. Shared services still need access controls. Shared dependency caches and build artifacts need a trust policy. A clean worker should not import unverified executable state left by a different task.

Tie approval to a candidate and deployment to an artifact

A release record should connect the task, source revision, required verification results, reviewed configuration, artifact, target environment, and authorisation. An artifact is the versioned package or image you deploy. Its digest is a fingerprint of its contents, useful for checking that the reviewed output is the one being promoted.

SLSA’s provenance model describes verifiable information linking software artifacts to their origins and build process. For this workflow, retain that connection through staging and production. Rebuilding from a moving branch can produce something different from what was checked; promote the verified artifact or verify the new build explicitly.

Repository controls can require checks and reviews before merge. GitHub’s protected-branch guidance documents required reviews and status checks, stale-approval options, and bypass behaviour. Configure the intended rules and inspect the agent’s effective privileges. A protected branch provides little assurance if the maintenance identity can bypass its requirements.

If a candidate changes after review, re-establish the relevant evidence and approval. At deployment, check current authority and the target state. An approved code change does not grant an indefinite right to deploy it to any environment.

Verify behaviour during rollout

For the connector repair, staging should exercise the complete reporting request with controlled data and a test destination. Check pagination, retries, missing-source behaviour, report validation, and delivery status together. Startup and health checks alone will not reveal a summary that falsely claims complete coverage.

A limited rollout can reduce initial exposure. Depending on the workflow, this might use one approved account, a restricted recipient, or a bounded share of work. Shadow execution can compare outputs before they are used, but it still needs data permissions and should not trigger live messages or account changes.

Define the condition for stopping rollout: renewed incomplete reports, excessive provider calls, permission failures, or another relevant signal. The operator needs a route to pause new jobs and prevent pending delivery while investigating. Recheck the policies used by long-running or queued tasks; permissions can be revoked after a task starts.

Plan for state as well as code

A connector or harness update may change stored plans, session state, metric definitions, or result schemas. Decide how old and new versions interact before promoting the change. An older worker might misread a newly introduced status, and a rollback may encounter state it cannot interpret.

Use explicit versions and supported compatibility paths. When migration is required, preserve the evidence needed to recover and test restoration. Do not treat replacing a container image as proof that all prior state has been reversed.

Retry and cancellation also need clear ownership. After a timeout during deployment or delivery, inspect the real outcome before repeating the operation. A job may have completed even if the caller never received its acknowledgement. Record uncertainty and reconcile it rather than creating an uncontrolled second effect.

Improve the harness through reviewed changes

The strongest version of the self-evolving harness is a controlled learning loop. Operational evidence helps produce candidate improvements to skills, context, test selection, and runtime behaviour. Those improvements are evaluated and released through a process that preserves independent control.

The model need not change for this loop to be useful. A better procedure can save repeated diagnosis; a clearer tool result can prevent a recurring mistake. Improvement is still a hypothesis until measured against a baseline and checked for regressions.

Record what happened without letting the agent certify it

Keep the task request, relevant versions, tool outcomes, test evidence, reviewer corrections, release status, and observed result. Separate the agent’s proposed explanation from verified events. Collect consequential results through the runtime or external services, with records the candidate worker cannot silently replace.

This illustrative event record deliberately stops short of declaring the whole task successful:

{
  "task_id": "weekly-report-pagination-fix",
  "candidate_ref": "candidate-42",
  "active_harness_ref": "harness-7",
  "event": "verification_completed",
  "producer": "trusted-verification-runner",
  "required_checks": {
    "pagination_and_partial_results": "passed",
    "account_isolation": "passed",
    "report_consumer_compatibility": "passed"
  },
  "evidence_ref": "verification-record-42",
  "review_status": "pending",
  "deployment_status": "not_started"
}

The references are illustrative names; a real implementation should bind them to exact revisions and stored results. Setting producer in JSON does not authenticate a record. The receiving system needs to establish its origin and ensure that the evidence belongs to the candidate being considered.

Keep secrets and unnecessary client data out of routine telemetry. Redaction helps, but logging fewer sensitive values is a stronger starting point. Restrict detailed incident evidence separately from ordinary performance dashboards, and define retention and deletion responsibilities.

Turn one recurring problem into one testable proposal

A useful improvement cycle has six steps:

1. Observe. Find a repeated failure, unnecessary delay, reviewer correction, or costly intervention in actual task records.
2. Diagnose. Identify whether the cause is missing guidance, a tool contract, a runtime limit, a policy decision, an environment failure, or a weak test.
3. Propose. Produce a scoped candidate change and state the expected improvement and possible regressions.
4. Compare. Run the baseline and candidate against appropriate tasks under comparable conditions, including protected acceptance and security cases.
5. Review and release. Route changes to their owners and activate only the approved version through the normal release path.
6. Observe again. Check whether the improvement survives real use, then retain or reverse it based on evidence.

For the connector failure, the lesson might be that the verification procedure should check how partial source status reaches the report. Adding a blanket instruction to “retry harder” would treat the symptom and could increase provider load. Relaxing the report validator to accept incomplete figures would change the definition of success.

A reflection pass can be performed by the same model, another model, or a human. Its value comes from the evidence it examines and the proposals it produces. Calling it a critic does not make its judgment independent, and adding more agents does not establish better measurement.

Reviewer corrections also need context. A preference expressed for one account or one emergency should not automatically become a global rule. Preserve who made the correction, where it applies, and which authority can approve a lasting policy change. Treat operational logs as potentially untrusted inputs to the improvement process.

Protect the rules that govern improvement

The maintenance agent may prepare candidate edits to application code and tests. A harness-improvement task may prepare candidate edits to skills, prompts, or configuration. These are different task scopes, not permanent grants to modify the live system.

Protect the active tool policy, credentials, required checks, acceptance criteria, release rules, and audit retention from unilateral edits. A proposed change to any of them needs explicit review by the relevant control owner. An agent that can improve a skill must not thereby acquire permission to disable the restriction that made the skill necessary.

File paths alone cannot establish this separation. A directory called agents/security is ordinary writable content if the worker can edit it. Use effective filesystem and service permissions, repository rules, trusted verification definitions, and separate release credentials. Where instructions are read from the working tree, ensure candidate edits cannot silently become the active policy or bypass the controls enforced outside those instructions.

Keep the implementation small, but make ownership visible

One possible layout separates candidate material from active control and operational evidence:

candidate-checkout/
  src/                         Application patch under development
  tests/                       Candidate product tests
  harness-proposals/
    skills/                    Proposed skill changes
    configuration/             Proposed configuration changes

active-harness-bundle/         Reviewed version, read-only to worker
  operating-instructions.md
  skills/

trusted-verification/         Controlled outside candidate worker
  required-check-definitions/
  acceptance-cases/
  graders/

protected-services/           Separate identities and access controls
  task-and-evidence-store/
  release-controller/
  credential-service/

This is an ownership sketch, not an installable runtime layout. The active harness must be loaded through the chosen runtime’s supported configuration. The protected areas should be mounted read-only where needed or accessed through narrow services; putting these folders beside one another does not provide that isolation.

The worker can develop tests in its candidate checkout. Trusted verification can execute that candidate in a restricted environment while keeping decisive graders and privileged credentials outside its control. The release controller can inspect verified results and promote an approved artifact without handing the worker its credentials.

The improvement process can read appropriately scoped evidence and open a proposal. It does not need write access to historical outcomes or the active harness bundle. That separation allows the system to learn from failure without rewriting the record of failure.

Operate the maintenance system through failures and change

Assign an owner for worker health, stuck tasks, verification failures, credential expiry, and release incidents. Track whether a scheduled check actually ran and whether its result arrived. If the maintenance worker stops, an independent monitor must be able to notice.

Containment should work without a successful model conversation: stop new tasks, cancel or isolate workers, block further release or delivery, and revoke affected access. Preserve evidence and establish which external effects already occurred before resuming. A stopped process does not necessarily cancel a provider job or an already queued message.

If a credential was exposed, removing it from a file is only part of the response; revoke or rotate it and investigate its use. If bad code reached production, restore a known version where compatible, reconcile state changes, and inspect affected reports or account actions. Code rollback cannot unsend a client report or undo an advertising change by itself.

After recovery, add the observed failure to the appropriate test or evaluation set. Change guidance when guidance was inadequate. Change enforcement when a boundary failed. Change the grader when it rewarded the wrong outcome. More instructions are not a universal repair.

Start with one complete maintenance path

I would start with a reproducible connector defect, an isolated worker, scoped repository access, a verification skill, and independently required checks. Let the agent prepare a reviewed candidate. Establish how that exact candidate reaches staging, how its behaviour is observed, and how an operator can stop or restore it.

Add dependency audits and security review as those paths become relevant. Introduce automated harness proposals after there is enough trustworthy operational evidence to identify a recurring problem. Expand the scope when evaluations and operating experience support it, rather than promising improvement by a fixed day.

The maintenance handoff is a reviewed repair, its evidence, release status, and any candidate improvement to the harness. Portable Intelligence takes the next step: distributing the accepted workflow and its dependencies to teammates without assuming their hosts or permissions are identical.