After building a multi-site WordPress backup system through a long patch-and-verify conversation, I wanted to revisit the entire process without assuming that its present form deserved to survive. Managed agents can now maintain state, operate tools inside sandboxes, enforce hooks, delegate evaluation and continue for hours. What would happen if that infrastructure were applied to the same project? Which manual loops would disappear, which controls would move into code, and where would human judgment change?
This is a comparison, not a defence of the old workflow. The project began with four independent WordPress installations on a small Debian VPS. Each site needed a complete filesystem and database backup in a separate private Git repository. The server had limited disk space, native IPv6 connectivity and no dependable native IPv4 route to GitHub. A temporary WARP tunnel supplied IPv4 during repository operations, while IPv6 and existing SSH sessions had to remain outside the tunnel. Maintenance mode could be enabled briefly during capture, but every exit path had to disable it again.
Over many iterations, the system developed into a central root-owned backup engine with four configuration files, isolated status and log directories, private repositories, restricted controllers, systemd service instances, a global lock, a central WordPress dashboard and a sequential daily timer. It eventually completed and remotely verified all four backups.
The development workflow itself was semi-automated. I described the objective and constraints in conversation. The AI examined pasted evidence, proposed an analysis and generated a complete Bash program. I ran the program on the VPS, returned its output and decided whether the next operation should proceed. Each program usually audited the server, constructed candidate files, validated them, created a rollback checkpoint, deployed the change and checked the final safety state.
That workflow worked, but the point of this article is not to preserve it ceremonially. I want to ask what a contemporary managed agent could do better. Perhaps much of my manual involvement was valuable judgment. Perhaps some of it was merely transport work—copying a command into a terminal and bringing the log back. Those two activities should not be confused simply because my fingers performed both.
What a managed agent actually adds
The central principles of current managed-agent systems are indeed broadly similar. The agent receives an objective, inspects available context, forms or revises a plan, calls tools, observes the results, evaluates progress and repeats the loop until it reaches an accepted stopping condition or requires escalation. Product interfaces differ, but this basic observe–act–evaluate cycle appears across managed coding agents, research agents and general-purpose agent platforms.
The important differences lie around the loop. One platform may provide an ephemeral Linux sandbox, while another operates directly in a local repository. Some preserve files between sessions; others reconstruct state from structured handoffs. Some expose pre- and post-tool hooks, network allowlists, budget limits, scheduled triggers, subagents or approval policies. The model determines much of the reasoning quality, but the harness determines what the model can observe, what it can change and how its claims are checked.
| Component | Function | Why it matters |
|---|---|---|
| Foundation model | Interprets the problem, reasons, writes code and chooses actions | Stronger models can retain more context, diagnose deeper causes and require fewer corrective rounds |
| Agent harness | Runs the repeated model–tool–observation loop | Turns a response generator into a system capable of sustained work |
| Execution environment | Supplies files, shell commands, packages, browsers and other tools | Determines whether the agent can test its ideas against reality |
| Policy layer | Limits paths, networks, credentials, budgets and destructive actions | Constrains the consequences of an incorrect decision |
| Evaluation layer | Runs tests, parsers, reviewers and acceptance criteria | Separates a plausible solution from an evidenced one |
| Persistent state | Preserves plans, artifacts, logs and progress across sessions | Allows long tasks to survive context resets and interruptions |
Google’s Gemini Managed Agents, for example, can provision an isolated Linux environment in which an agent reasons, manages files, installs packages, runs code and retrieves web material. Later updates added tool hooks, budget controls and scheduled triggers. OpenAI’s account of harness engineering describes agents using repository tools, worktrees, browser automation, logs, metrics and automated reviewers. Anthropic’s work on long-running harness design uses planner, generator and evaluator roles, plus structured handoffs between fresh contexts.
The exact product is less important here than the architectural change. In my earlier workflow, the conversation suggested actions while I manually connected it to the environment. In a managed workflow, the environment and its tools become part of the conversation’s execution loop. I was effectively acting as the network cable between the reasoning system and the server. It was a highly educated network cable, admittedly, but still a cable.
How my patch-and-verify loop worked
A typical iteration began with evidence copied from the VPS. This might include a systemd journal, a status document, an exact source block, repository metadata, service states and a mandatory safety report. The AI then constructed a single Bash program intended to perform one bounded correction.
The program generally followed this sequence:
- Acquire the global backup lock.
- Confirm that no backup service was active.
- Check WARP, website services, maintenance markers and SSH continuity.
- Inspect the exact installed source and expected anchor text.
- Construct candidates in a temporary directory.
- Apply deterministic transformations, often through Python.
- Validate Bash, PHP, JSON, systemd and sudoers artifacts with their real parsers.
- Create a timestamped rollback checkpoint.
- Deploy the approved files.
- Reload or reset only the affected services.
- Run a non-destructive preflight or status query.
- Verify the mandatory final safety state and print the result.
Python was frequently embedded in Bash to make exact, counted replacements. This avoided imprecise manual editing:
from pathlib import Path
import shutil
installed = Path("/usr/local/sbin/example-backup")
candidate = Path("/tmp/candidate/example-backup")
checkpoint = Path("/tmp/checkpoint/example-backup")
text = installed.read_text(encoding="utf-8")
old = 'EXPECTED_MODE="600"'
new = 'EXPECTED_MODE="640"'
count = text.count(old)
if count != 1:
raise SystemExit(
f"Expected exactly one patch anchor; found {count}"
)
shutil.copy2(installed, checkpoint)
candidate.write_text(
text.replace(old, new),
encoding="utf-8",
)
After construction, the candidate was submitted to the relevant authorities:
bash -n /tmp/candidate/example-backup php -l /tmp/candidate/example-plugin.php systemd-analyze verify /tmp/candidate/[email protected] visudo -cf /tmp/candidate/example-sudoers python3 -m json.tool /tmp/candidate/status.json >/dev/null
This method created strong boundaries around individual changes. It also repeated a large amount of orchestration. Every new correction rebuilt another miniature framework for inspection, patching, validation, checkpointing, deployment and cleanup. In other words, I was repeatedly generating temporary harnesses because no persistent harness yet connected the agent to the system.
Translating the workflow into an agentic process
A managed implementation could absorb most of that orchestration. The human would provide the objective, environment policy and acceptance criteria. The agent would inspect the source and current state directly, reproduce the problem inside an isolated workspace, patch the candidate, run the validators, obtain independent evaluation and return a change bundle. If production deployment were authorised, a narrow controller could apply the verified bundle and report the result to the same agent.
Semi-automated workflow
Human objective
↓
Conversational analysis
↓
Generated Bash program
↓
Human copies program to VPS
↓
VPS executes audit, patch and validation
↓
Human copies result back
↓
New analysis and correction
Managed-agent workflow
Human objective and policy
↓
Planner
↓
Managed sandbox and environment tools
↓
Implementation agent
↓
Deterministic validators
↓
Independent evaluator
↓
Verified change bundle
↓
Production policy gate
↓
Restricted local deployment controller
↓
Telemetry returned to the agent
The new workflow would not simply make the old one run faster. It would change where decisions occur, how evidence moves and what the human sees. Instead of receiving a fresh monolithic script for every correction, I could inspect a persistent plan, live tool calls, candidate diffs, evaluator reports and a final deployment request.
Environment inspection could happen directly
During the original development, each diagnosis depended on the evidence I pasted. Sometimes the evidence was enough. Sometimes another audit was needed because the first report omitted the decisive line. This happened when the dashboard displayed an old successful backup log alongside a newer failed systemd result. The status file, unit state and log described different events, but the conversation initially saw only part of that timeline.
A managed agent connected to a read-only observability interface could query all three sources itself. It could correlate them using service invocation IDs and timestamps, then construct a structured event history:
{
"site": "example-main",
"latest_attempt": {
"invocation_id": "example-invocation",
"state": "failed",
"stage": "local-validation",
"started_at": "2026-08-13T21:11:11Z"
},
"latest_verified_backup": {
"state": "completed",
"commit": "example-verified-commit",
"completed_at": "2026-08-13T10:40:37Z"
}
}
That would remove many separate “please run this audit” rounds. The agent could ask the environment follow-up questions immediately, while the failed state was still fresh.
Planning could become an executable artifact
My earlier commands contained plans, but the plans were encoded inside hundreds of Bash lines. A managed agent could maintain a separate task graph showing dependencies and acceptance criteria. For a repository rename, the graph might include repository identity verification, history ancestry, availability of the new name, configuration discovery, boundary-aware replacement, parser validation, deployment and remote confirmation.
The human could review or alter that graph before execution. If a new fact invalidated one step, the agent could revise only the affected branch. This is more flexible than regenerating the entire transaction script.
The agent could construct its own tests
Stronger recent models materially change what is possible inside the loop. Anthropic’s official announcement for Claude Opus 5 describes improved root-cause analysis, self-verification and sustained iteration. One reported example involved the model building its own test harness when no live data source was available. Another described it correcting an underlying package-manager bug that a surface-level patch had missed.
These capabilities would have been highly relevant to my Unicode-path failure. A backup failed with exit code 141 during Git capture. The eventual diagnosis involved display-quoted Unicode filenames, newline-oriented parsing and an upstream process receiving SIGPIPE. A capable managed agent could preserve the failed candidate, create a small repository containing Chinese filenames, spaces, tabs and other edge cases, and test alternative validators before touching production.
mkdir -p fixture/site/uploads touch "fixture/site/uploads/普通话文件.jpg" touch "fixture/site/uploads/file with spaces.txt" touch $'fixture/site/uploads/file\twith-tab.txt' git -C fixture/site init -q git -C fixture/site add -A git -C fixture/site ls-files -z | python3 validate_paths.py --input-separator=nul
A stronger model might generate this regression itself. The harness still matters because the test must run somewhere, observe real Git behaviour and reject a patch that fails. The server does not award points for an elegant explanation of SIGPIPE if the pipeline still exits with 141.
Evaluation could be separated from implementation
One weakness of both humans and models is attachment to their own solution. Anthropic’s harness research found that agents often evaluated their own output too generously. Its long-running architecture therefore separated planning, generation and evaluation. The evaluator received concrete criteria and returned criticism to the implementation agent.
That structure would improve my workflow. After an implementation agent modified the backup engine, a separate evaluator could inspect the diff, run regression fixtures and attempt to disprove the claimed fix. A security evaluator could examine privilege boundaries, while an operations evaluator checked cleanup and systemd state.
The evaluators would not all need to use the most expensive model. Deterministic parsers should handle syntax. A fast model could classify logs. A stronger reasoning model could investigate cross-layer failures involving shell behaviour, Git, networking and systemd. The model choice becomes part of the harness design instead of a single decision applied to every task.
Context handoff could become deliberate
The original conversation accumulated a long history containing successful decisions, obsolete assumptions, superseded commands and partial fixes. That history was valuable, but it also made context management difficult. A managed harness can periodically start a fresh agent with a structured handoff containing the current architecture, unresolved task, relevant evidence, prohibited actions and validated checkpoints.
This differs from merely summarising an ever-growing conversation. A clean handoff can exclude irrelevant attempts while preserving the facts necessary for the next agent. The handoff itself can be versioned and tested for required fields.
{
"objective": "Correct Unicode-safe Git path validation",
"confirmed_root_cause": [
"display-quoted Git paths",
"newline-oriented validation",
"upstream SIGPIPE"
],
"current_production_state": {
"maintenance": "off",
"backup_service": "inactive",
"repository": "private-and-empty"
},
"prohibited_actions": [
"start-backup",
"push",
"change-network-registration"
],
"required_evidence": [
"bash-syntax",
"nul-path-regression",
"unicode-path-regression",
"cleanup-state"
]
}
How the original failures might change under managed execution
The repository commit mismatch
An early audit compared the last backup commit stored in the status file with the current remote main commit. They differed because a manually edited README had added two newer commits. Both values were correct, but they represented different concepts.
In the semi-automated process, I had to explain that the newer remote commit was expected and ask for a more nuanced audit. A managed agent with GitHub access and local state could independently inspect the commit graph, discover that the remote head descended from the last verified backup, examine the intervening changes and revise the acceptance rule from equality to ancestry.
This is a case where increased autonomy would probably improve the workflow. The agent would not need a human to transport every Git query. Human involvement would become important only if the intervening changes required a judgment the policy could not express—for example, deciding whether a manual documentation change was legitimate.
The generated README overwrote permanent documentation
The backup engine regenerated README.md for every snapshot. I had also used that file for a long manual technical history. The next backup replaced my documentation because two different forms of content shared one path.
A managed agent could trace all writers of README.md, compare generated output with repository history and identify the ownership conflict. It might then propose the same eventual architecture: a generated snapshot README plus a permanent document under docs/, backed by a root-owned authoritative copy.
This correction does not intrinsically require human execution. Once the desired preservation policy is explicit, an agent can implement and test it. The human contribution lies in defining that the historical document has permanent value and should remain part of every future backup.
The optional documentation directory
The first additional site failed because the engine expected an extra documentation directory that did not exist when documentation was disabled. The fix initially addressed that assumption, but another Unicode-related failure then appeared.
A managed agent could generate a configuration matrix and exercise both branches before deployment:
Case 1: documentation enabled and source exists Case 2: documentation disabled Case 3: documentation enabled but source missing Case 4: empty documentation directory Case 5: documentation contains Unicode paths
This is a straightforward improvement. The earlier workflow tested the state that happened to exist. A managed sandbox can cheaply create states that do not yet exist and discover branch-specific defects earlier.
The full-log problem
The first WordPress dashboard exposed only allowlisted log lines. That protected secrets but omitted details needed for diagnosis. I then had to run another root-only audit and paste its result. Later versions returned a much fuller operational log after deterministic redaction.
A managed agent could receive detailed protected logs through a narrow connector without displaying raw secrets to the browser or copying them through conversation. A redaction service could run locally before the data entered the agent environment. The dashboard could continue showing the complete protected operational log to administrators.
Here the managed workflow would reduce human labour without necessarily increasing access. The agent receives better evidence, but the credential boundary stays outside the model.
The GitHub Internal Server Error
The first Experimental-site backup completed its database export and Git commit, then GitHub rejected the push with an Internal Server Error. A later bounded retry succeeded with a newly generated snapshot.
A managed agent could classify the error, inspect the remote state, apply exponential backoff and retry according to policy. It could preserve the distinction among a locally created commit, an attempted push and a remotely verified backup. The dashboard would update only after the authoritative remote reference matched the expected commit.
This is another area where autonomous handling is beneficial. A transient service failure does not require a human decision each time. It requires a reliable retry budget and an escalation threshold. Even GitHub is occasionally entitled to a bad afternoon; the engineering task is to prevent its mood from becoming our data model.
The exact documentation mode
The main-site backup later failed because the protected history document had mode 0644. One correction changed it to 0600, which still failed because the engine required exactly root:root:0640. The problem was not a lack of effort. The correction implemented an assumed security rule instead of reading the predicate enforced by the installed engine.
A managed agent with direct source access could search for the actual check, inspect the relevant configuration and run the real preflight against a candidate. An independent evaluator could ask whether the patch changes the condition or the file metadata and whether that matches the system’s design.
The strongest improvement here is epistemic. The agent can move from discussing what the mode probably should be to interrogating what the running system actually requires. A more capable model such as Opus 5 may be less likely to stop at the surface symptom, but the harness gives it the source, shell and evaluator needed to prove the conclusion.
The scheduler installation failure
The first scheduler installation candidate failed systemd verification because its unit referenced a sequence runner that had not yet been installed. The validator correctly reported that the command did not exist, but the installation script treated this as an unexpected failure.
A managed environment could stage the complete candidate filesystem before running unit verification. The service file, runner, timer and configuration would exist together inside the simulated root. This would make the validation environment resemble the post-deployment state instead of the pre-deployment host.
That is a subtle but important shift. Managed sandboxes can test a proposed future state. My original scripts often validated individual files while the host still represented the old state.
The stale remote read after a successful push
A documentation commit was pushed successfully, but an immediate follow-up query returned the old remote head and the wrapper declared failure. The mutation had succeeded; the confirmation path observed stale state.
A managed agent could retain the push receipt, poll the authoritative reference within a bounded consistency window and classify the result as confirmed, pending or failed. It should not repeat the push merely because one immediate read was stale.
This kind of temporal reasoning is well suited to a long-running agent. The agent can wait, recheck and preserve context without requiring another human round trip.
What could be automated more aggressively now?
If I redesigned the development workflow today, I would allow the managed agent to perform substantially more of the engineering loop. Read-only discovery, source inspection, reproduction, candidate construction, syntax validation, regression testing, diff review, status correlation, retry handling and documentation generation could all run without a human manually relaying each result.
The agent could also deploy certain changes automatically if the capability were narrow, the mutation reversible and the acceptance criteria fully executable. For example, updating a canonical plugin inside a controlled staging WordPress installation could be automatic. A successful test bundle could then be promoted to production through a local controller whose permissions covered only the expected files.
More consequential actions would receive explicit gates. Repository deletion, force-pushes, changes to WARP registration, unrestricted root commands, destructive database operations and alterations to network policy should require a higher level of authority. Those boundaries are not eternal moral categories. They can move as the harness accumulates stronger evaluations, safer credentials and better recovery mechanisms.
| Action class | Possible default | Reason |
|---|---|---|
| Read-only inspection | Automatic | Low impact and necessary for complete diagnosis |
| Sandbox patching and testing | Automatic | Isolated and reversible |
| Documentation and candidate generation | Automatic with diff retention | Reviewable before promotion |
| Retry after classified transient failure | Automatic within a budget | No new design decision is normally required |
| Deployment through an exact scoped controller | Conditional automation | Can be safe when hashes, paths and rollback are verified |
| New privileged capability | Human approval | Changes the agent’s future blast radius |
| Destructive or difficult-to-reverse external action | Explicit human approval | Consequences extend beyond the candidate environment |
The system could gradually earn more autonomy. A new workflow might begin with mandatory approval for every production bundle. After repeated successful deployments, low-risk classes could become automatic while unusual changes continued to stop. This resembles progressive deployment in ordinary software engineering: trust is supported by observed performance and bounded consequences.
What should remain deterministic?
Managed agents can technically schedule and run recurring jobs. That does not mean every recurring job benefits from model reasoning. The production backups already have a known sequence, global lock, fixed cleanup procedure and exact success conditions. Systemd can perform that work locally, cheaply and without depending on an external agent service.
The managed agent could supervise the sequence, inspect anomalies and propose adaptations. It could notice that one site’s backup duration has doubled, that available disk is approaching the preflight threshold or that several pushes are failing in the same stage. The actual nightly command sequence can remain deterministic until there is a real reason for adaptive planning.
Using a frontier model merely to remember that four known services should run in order would be like appointing a theologian to ring the church bell. It may produce an interesting reflection on time, ritual and distributed consensus, but the bell was doing fine with a clock.
The same principle applies to maintenance cleanup, lock acquisition, status-file schema validation and remote commit verification. These are executable invariants. The agent should call them, interpret them and improve them when necessary. It should not replace a reliable predicate with a conversational impression.
A managed architecture for the same project
I would divide the new system into a managed development plane and a deterministic production plane. The two would communicate through a narrow capability bridge.
Managed development plane
├── Planner
├── Implementation agent
├── Operations evaluator
├── Security evaluator
├── Persistent task state
├── Synthetic WordPress and Git fixtures
├── Candidate files
├── Test reports
└── Immutable deployment bundle
│
│ scoped request
▼
Production capability bridge
├── Read service status
├── Read protected operational logs
├── Run non-pushing preflight
├── Verify candidate bundle hash
├── Apply approved paths
├── Reload named units
└── Execute rollback
│
▼
Deterministic production plane
├── Root-owned backup engine
├── Per-site configuration
├── Global lock
├── systemd services and timer
├── WARP safety controller
├── Maintenance cleanup
├── Private Git repositories
└── WordPress status dashboard
The managed development plane
The managed environment would contain the canonical source, tests, synthetic fixtures and selected configuration metadata. It would not contain production database exports, private keys or unrestricted server credentials. The agent could freely inspect and modify its candidate workspace.
A planner would decompose the objective. The implementation agent would make the changes. Evaluators would attempt to falsify the proposed solution. Hooks would run parsers and policy checks after writes or before sensitive tool calls. The environment would preserve artifacts across model context resets.
The production capability bridge
The bridge would expose exact actions instead of a general shell:
status(site-id) read-log(site-id, invocation-id) preflight(site-id) verify-bundle(bundle-sha256) deploy-approved-bundle(approval-id) rollback(change-id)
Each action would validate its arguments against an allowlist and execute a root-owned implementation. The model would never construct an arbitrary string for sudo bash -c. If the agent needed a new capability, adding it would itself become a reviewed engineering change.
The deployment bundle
A completed agent run would produce an immutable bundle containing the patch, file hashes, validation results, affected paths, rollback material and remaining uncertainties:
{
"change_id": "unicode-validator-v2",
"objective": "Support byte-safe Git path validation",
"affected_paths": [
"/usr/local/sbin/example-backup"
],
"candidate_sha256": "example-candidate-hash",
"validation": {
"bash_syntax": "passed",
"unicode_fixture": "passed",
"nul_stream_fixture": "passed",
"cleanup_fixture": "passed"
},
"rollback_available": true,
"unresolved_risks": [],
"requested_action": "deploy-scoped-candidate"
}
The production controller would recompute the hash, check the allowed paths, rerun local validators, create its own checkpoint and apply the bundle. The agent could then inspect the post-deployment state.
Where stronger models change the calculation
Harness design should not obscure the importance of model progress. A better harness cannot turn a weak model into a reliable systems engineer. It can provide useful structure, but the model still has to understand ambiguous evidence, maintain causal hypotheses, recognise incorrect assumptions and choose appropriate tests.
Claude Opus 5 is relevant because Anthropic reports improvements precisely in root-cause analysis, verification and long-running agentic work. Its announcement includes examples of the model building missing validation infrastructure, catching edge cases and pushing back on an engineer’s proposed design. GPT-5.6, Gemini and other current systems likewise place increasing emphasis on tool use, sustained tasks and agentic execution.
A stronger model could reduce the number of iterations in my project. It might have discovered the exact documentation-mode predicate before proposing 0600. It might have connected exit code 141 with a prematurely terminated pipeline earlier. It might have modelled Git ancestry correctly instead of comparing two commit identifiers for equality.
However, these improvements are probabilistic. Opus 5’s stronger self-verification does not make external evaluation obsolete. Anthropic’s own harness research separates generation from evaluation because models tend to favour their own work. The optimal design combines improved model judgment with independent tests and constrained execution.
The balance will continue to change. As models become steadier, some approval gates may add more delay than safety. As harnesses acquire stronger policy enforcement, agents can operate longer without supervision. Engineering should respond to measured capability instead of preserving a fixed amount of human intervention for symbolic reasons.
Comparing the two workflows objectively
| Dimension | Semi-automated patch-and-verify | Managed-agent workflow |
|---|---|---|
| Environment access | Human transports selected evidence and commands | Agent queries authorised tools directly |
| Continuity | Conversation history, pasted logs and checkpoints | Persistent workspace, structured state and resumable tasks |
| Planning | Embedded in explanations and generated scripts | Explicit task graph that can be revised during execution |
| Testing | Constructed separately for each corrective script | Reusable fixtures, hooks and evaluator agents |
| Human effort | Frequent execution, observation and evidence transfer | Concentrated on goals, policies, exceptions and acceptance |
| Auditability | Excellent when scripts and logs are preserved, but fragmented | Potentially comprehensive if tool calls, artifacts and decisions are retained |
| Safety boundary | Human decides whether to execute the complete program | Sandbox, capabilities, hooks, budgets and action-level approvals |
| Failure recovery | New conversational round and corrective program | Agent can inspect, revise, retry or escalate within the same task |
| Risk of hidden error | Long generated Bash may conceal an assumption | Long autonomous execution may conceal a chain of assumptions |
| Scalability | Limited by human attention and round-trip time | Supports concurrent investigation and long-running tasks |
The managed workflow is likely better for sustained inspection, reproduction, candidate development and repetitive validation. It reduces delays caused by moving evidence manually and can explore several hypotheses before returning. It can also improve safety if its permissions are narrower than the authority embedded in a copied root script.
The semi-automated workflow has one natural advantage: every major state transition is visible because a human must execute it. Managed agents need to reconstruct that visibility deliberately through plans, event streams, diffs, evaluation artifacts and approval gates. Otherwise, efficiency can make the process harder to understand.
This does not mean that manual execution is intrinsically safer. A human can approve a dangerous script without reading it, especially after twenty successful iterations. Conversely, a managed policy can mechanically block all writes outside two approved paths. Security depends on the quality of the boundary, not on whether a human’s hand touched the Enter key.
Human agency after the workflow becomes more autonomous
The academic question becomes more interesting once managed agents can perform a substantial part of the intermediate process. In my semi-automated workflow, human participation was continuously visible. I asked the next question, ran the next command, interpreted the result and redirected the project. A managed agent could collapse several of those cycles into one task.
That does not automatically remove human agency. It changes its location. Agency can move from individual command execution toward problem formulation, environment design, capability allocation, evaluation criteria, interpretation of exceptions and acceptance of consequences. In some cases, this may increase human agency because the person can pursue a more ambitious project and compare more alternatives.
There is also a real risk of losing agency. If the managed environment, tests, model routing and stopping criteria remain invisible, the person may receive a polished result without understanding how the problem was framed or which alternatives disappeared. The human then becomes an outcome consumer instead of a collaborator.
UNESCO’s discussion of AI operators and creators is useful here. It asks whether people merely operate systems designed elsewhere or acquire the understanding needed to shape those systems. In a managed-agent project, the student who designs the harness, validators and authority boundaries exercises a different and potentially higher-level form of technical agency than the student who only asks for a finished application.
The intermediate process is still educational evidence
Higher education should therefore avoid assessing only the final repository. A managed agent may produce a technically excellent artifact, but the final artifact alone does not show whether the student understood the system, designed the tests, recognised the risks or simply accepted the output.
Useful evidence could include the original objective, agent plan, capability policy, significant tool calls, rejected hypotheses, evaluator reports, diffs, regression fixtures, human interventions and the final acceptance argument. The student should be able to explain why the solution is correct, what evidence would falsify it and which remaining risks were consciously accepted.
An oral defence could select one unexpected event from the agent trace. The student might have to explain why 0640 passed while 0600 failed, why a remote commit needed ancestry rather than equality, or why a NUL-delimited path stream solved the Unicode failure. This evaluates situated understanding without requiring the student to pretend that AI was absent.
Human disagreement with the agent is not the only sign of agency
It would be another mistake to define human agency only as resisting the machine. A capable agent may present a better design than the human’s first proposal. Anthropic reports that Opus 5 can challenge an engineer’s approach and sustain a reasoned objection. Accepting that criticism after examining it can be an exercise of agency too.
The important issue is whether the person can understand and evaluate the alternative. Human authority should not mean that the human must always be right. It means that responsibility for the project’s purposes and consequences remains traceable, while technical reasoning can be genuinely collaborative.
Approval fatigue can imitate participation
A workflow can contain many human clicks while containing very little human judgment. Anthropic’s security research has reported high approval rates for repeated permission prompts, suggesting that users become less attentive as confirmations accumulate. A student who approves every action automatically is not exercising much more agency than a mechanical Enter key with a tuition invoice.
Managed systems should reserve human interruption for decisions that are meaningful. Routine reads, sandbox writes and deterministic tests can proceed automatically. New privileges, destructive operations, unresolved ambiguity and major production consequences deserve focused attention.
What I would automate now
I would automate the collection and correlation of read-only evidence. The agent could inspect source files, service state, protected logs, status documents, repository history, timers and disk capacity through restricted tools.
I would automate reproduction and candidate construction inside a managed sandbox. The agent could generate edge-case fixtures, patch the source, run validators, compare alternatives and preserve its workspace across iterations.
I would automate independent evaluation. One agent could implement, another could challenge the diagnosis, and deterministic tools would remain the final authority for syntax and executable invariants.
I would automate bounded retries, eventual-consistency polling, status reconciliation and documentation derived from verified state. These operations require patience and accurate bookkeeping more than human judgment.
I would allow scoped production deployment when a candidate bundle modifies known paths, passes established regressions, includes rollback material and can be applied through a narrow controller. The system could earn broader autonomy through repeated successful evaluation.
I would keep deterministic services for routine backups, locks, cleanup and schedules. Their behaviour is already expressible as code and does not benefit from fresh model reasoning every night.
I would retain explicit human involvement when the operation creates a new capability, changes the security boundary, affects external identity, risks data loss or contains a genuine policy ambiguity. That boundary can evolve. The goal is not to maximise either automation or human clicking; it is to assign each decision to the mechanism best equipped to make and verify it.
Conclusion
My patch-and-verify workflow was effective because it connected AI reasoning to deterministic evidence through carefully bounded command sequences. It also required repeated human transport, rebuilt temporary orchestration for each change and sometimes discovered incorrect assumptions only after another production-facing iteration.
Managed agents could substantially transform that process. They can inspect authorised environments directly, maintain long-running state, build their own tests, use separate evaluators, enforce hooks, control budgets, retry transient failures and return a verified change bundle instead of another monolithic script. Stronger models such as Claude Opus 5 make this transformation more significant because they improve root-cause analysis, sustained reasoning and self-correction.
The resulting workflow would probably be more autonomous than my original one. That is not a concession or a threat; it is an engineering opportunity. The important work is designing the environment in which autonomy operates: what the agent can see, what it can change, how it is evaluated, how it recovers and when it must escalate.
For higher education, the same shift changes the meaning of technical participation. Students may execute fewer individual commands while taking greater responsibility for system goals, evaluation design, delegation and governance. That possibility is valuable, but it depends on keeping the intermediate process inspectable. If managed AI hides the process, it can reduce learning to outcome consumption. If the harness exposes plans, evidence, failures and decisions, it can become a richer environment for human–computer collaboration.
The most useful question is therefore no longer whether a person or an agent “did the work.” A real engineering system distributes work among models, tools, tests, schedulers, policies and people. The better question is whether that distribution produced a correct, recoverable and intelligible result—and whether the people involved still understood enough to take responsibility for it.
Sources and further reading
- Anthropic: Introducing Claude Opus 5
- Anthropic: Harness design for long-running application development
- Anthropic: How we contain Claude across products
- OpenAI: Harness engineering in an agent-first environment
- OpenAI: Introducing the Codex app
- Google: Introducing Managed Agents in the Gemini API
- Google: Managed Agents, environment hooks, budgets and triggers
- UNESCO: AI operators or creators?