I built Yin’s Background Studio through a semi-automated conversation: AI proposed bounded changes, I ran them on a live WordPress server, and the resulting logs and screenshots determined the next move. The system eventually grew from one repeating background into classic mosaics, scattered collage, persistence, density and colour controls. Now I want to try the next workflow seriously: let an agent inspect, edit, run, see and verify the project itself.
The existing method is my evidence base, not the method I am trying to preserve. Much of my participation was valuable product judgment, but much of it was also mechanical transport—copying a command into the VPS, waiting, and carrying the output back into the conversation. A managed agent can absorb that loop, including browser-based visual checking. The real question is therefore how far the workflow can move into the harness, what improves when it does, and which remaining human decisions are genuinely meaningful instead of inherited habits.
The old workflow is a baseline, not a preferred endpoint
I do not begin with the conclusion that the semi-automated workflow should survive. If an agent can inspect the actual repository, reproduce the WordPress environment, revise its own candidate after a failed check, open the page, evaluate the visual result and prepare a recoverable deployment, then repeatedly transferring commands by hand has little engineering value. It may have been the available bridge during the original project, but availability is not a design principle.
At the same time, replacing the transport loop does not require discarding everything learned through it. Exact saved-record counts, parser-specific validation, candidate construction outside the live theme, timestamped checkpoints, public-page checks and explicit rollback instructions are useful because they constrain failure. In an agentic workflow they should become reusable harness policies and automated evaluations. Their value does not depend on my manually invoking them.
I therefore approach the comparison without assigning moral superiority to either level of automation. The managed workflow should be preferred wherever it is more complete, faster, safer or easier to verify. The semi-automated history remains useful because its real failures reveal what the managed system must observe and test. This is also practical: I am interested in trying such a workflow now, beginning with a controlled development environment and widening its authority when the evidence supports it.
The concrete project behind the comparison
Yin’s Background Studio is a custom module inside a modified WordPress theme. Its initial job was modest: choose one enabled background, apply its saved colour, dimensions, repetition and position, and keep the website content readable above it. The captured environment was Debian 13 with kernel 6.12.101, PHP 8.4.24, WordPress 7.0.4 and a customised Penscratch 1.0.3 theme on a small VPS. Node.js was absent at first; version 20.19.2 was installed later when JavaScript syntax checking became part of the deployment gate.
The live handoff contained six saved background records. I often described these conversationally as “six GIFs,” but the source evidence was more precise: one record used SVG, one used GIF, and four used WebP, with two records referring to different configurations of the same Hilbert asset. This distinction matters in a performance discussion. Six records do not necessarily mean six simultaneously decoded GIF animations, and repeating one cached image is not equivalent to downloading it twenty-one times.
The original module lived primarily in these theme paths:
/var/www/example-site/wp-content/themes/penscratch/inc/background-studio.php/var/www/example-site/wp-content/themes/penscratch/js/background-selector.js/var/www/example-site/wp-content/themes/penscratch/js/background-studio-admin.js/var/www/example-site/wp-content/themes/penscratch/css/background-studio-admin.css/var/www/example-site/wp-content/themes/penscratch/style.css/var/www/example-site/wp-content/themes/penscratch/functions.php, which loaded the module
The WordPress option was named yin_background_studio. In simplified and anonymised form, the saved structure looked like this:
{
"enabled": true,
"mode": "random",
"random_method": "equal",
"persistence": "page",
"static_id": "chemical",
"reduced_motion_id": "chemical",
"items": [
{
"id": "background_example",
"name": "Example background",
"enabled": true,
"attachment_id": 100,
"url": "https://example.com/wp-content/uploads/background.webp",
"weight": 1,
"color": "#000000",
"size_mode": "custom",
"width": "auto",
"height": "225px",
"repeat": "repeat",
"position_x": "right",
"position_y": "top",
"attachment": "scroll",
"scope": "all"
}
]
}
PHP remained the authority for saved settings. It sanitised IDs, URLs, colours, weights, dimensions and allowlisted values. A later authoritative dimension validator converted a unitless value such as 256 into 256px, accepted supported CSS units and auto, and rejected invalid input with an explicit error while preserving the previous valid value. The administration JavaScript improved the interaction by switching to Custom mode when dimensions were edited, but it did not become the data-integrity authority.
On the public side, PHP first removed disabled, empty or out-of-scope records and localised the resulting configuration to JavaScript. The selector used window.crypto.getRandomValues() when available, falling back to Math.random(). Equal selection chose uniformly; weighted selection traversed the positive weights. Page persistence selected on each load, session persistence stored an ID in sessionStorage, and daily persistence stored an ID plus the UTC date in localStorage.
The main source boundaries were already visible in the function names. yin_background_studio_sanitize() and the later authoritative dimension sanitizer protected saved data; yin_background_studio_frontend_assets() assembled the scoped public configuration; and the browser functions choosePersistentRandom(), applyImage() and applyVideo() selected and rendered one item. Composition therefore needed to extend both the server-side schema/configuration path and the browser-side choice/rendering path without allowing two selectors to compete for the same decision.
Reduced motion was evaluated before normal static or random selection. The configured reduced_motion_id was used when prefers-reduced-motion: reduce matched. The system did not automatically put an animated GIF into that fallback; choosing a suitable still asset remained an administration decision. Images, SVG, GIF and WebP were applied through CSS custom properties on the root element. Video was recognised from the URL extension and mounted as a muted, looping, inline, non-interactive fixed layer with aria-hidden="true", metadata preloading and a configured fallback colour. Video support remained available in the original single-background modes, although the later collage work deliberately concentrated on images.
The feature request was visual, but the architecture was not trivial
The next idea sounded simple: instead of repeating one selected background, show two, three or perhaps more distinct backgrounds together. The important word was “together.” Stacking several full-screen CSS backgrounds would technically load several media items, yet the top opaque layer could hide everything below it. That would satisfy the array length and fail the design.
Three architectures were considered. CSS multiple backgrounds were attractive because they required little DOM, worked naturally with images and could later be useful for scattered copies. They were a poor primary representation for the first mosaic, however, because full-screen layers overlap and become difficult to reason about when each item needs its own visible region, saved sizing and position.
A fixed DOM container using CSS Grid was the strongest starting point. Each selected item could occupy an explicit tile; two- and three-item arrangements could be seen simultaneously; the container could sit behind the page, stay out of document flow, use pointer-events: none, and carry aria-hidden="true". Because it was fixed from the moment it appeared, it did not need to move the content or create cumulative layout shift. The browser, after all, understands a rectangle very well. It has had years of practice.
Canvas was also considered and rejected for this case. It would have introduced a custom rendering loop, more difficult GIF and video behaviour, extra accessibility and resizing work, and a less inspectable relationship between each saved item and its visual result. Canvas becomes worthwhile when pixels must be composited, transformed or simulated in ways that CSS cannot express. A few independently placed backgrounds did not cross that threshold.
The result evolved into more than one rendering strategy. Classic Two and Three layouts used deliberate regions. Full Random Collage generated less regular geometry. An optional Separate random panels mode then used controlled CSS background layers to scatter repeated copies, inherit each record’s configured size and avoid intentionally joining identical images into one large block. This mixed architecture was reasonable because the modes represented different visual promises.
How the semi-automated development loop actually worked
The development process was conversational but strongly procedural. I described the next behaviour, often in visual language. The AI analysed the current handoff or the latest installer output and produced one complete Bash command. I ran it as an authorised administrator on the VPS, then returned the log or a screenshot. Each iteration was expected to inspect before changing, build away from the live theme, validate candidates, checkpoint the current state, deploy only after the checks passed and verify WordPress afterward.
A representative transaction had this shape:
set -euo pipefail SITE_ROOT="/var/www/example-site" THEME_DIR="$SITE_ROOT/wp-content/themes/penscratch" STAMP="$(date -u +%Y%m%dT%H%M%SZ)" CHECKPOINT="/var/backups/example/pre-background-change-$STAMP" # 1. Verify exact live files and current PHP syntax. # 2. Read and count the saved Background Studio records. # 3. Copy affected files into the timestamped checkpoint. # 4. Build candidates outside the live theme. # 5. Validate PHP, JavaScript and CSS candidates. # 6. Deploy only the validated paths. # 7. Bootstrap WordPress and test the public page and assets. # 8. Confirm the saved record count and print rollback instructions.
Python frequently performed exact, counted text transformations. The point was not that Python possesses morally superior string replacement. It made a brittle assumption visible and executable:
from pathlib import Path
source = Path("/tmp/candidates/background-extension.php")
text = source.read_text(encoding="utf-8")
old = "expected exact source anchor"
new = "validated replacement"
count = text.count(old)
if count != 1:
raise SystemExit(
f"Expected exactly one patch anchor; found {count}."
)
source.write_text(
text.replace(old, new),
encoding="utf-8",
)
This method prevented a guessed patch from silently landing in the wrong place. It also exposed a recurring weakness: the patch program only knew the source version and anchor shape encoded into it. When that assumption was wrong, a safe installer stopped, but another conversational round was required to inspect the actual form and produce a correction.
The failures were part of the specification
The first mosaic installers did not deploy. One reported ERROR: Could not find Random method row.; another reported ERROR: Existing frontend enqueue call not found. The checks did their job: PHP remained valid, the six records remained present, and the live checksums were unchanged. The eventual solution stopped trying to force every addition into fragile positions inside the original module. It added an isolated extension loader and separate PHP, JavaScript and CSS files.
The principal PHP extensions became inc/background-mosaic-extension.php, inc/background-separate-panels-extension.php, inc/background-scatter-controls-extension.php and inc/background-collage-layout-mix-extension.php, with corresponding public and administration JavaScript and CSS assets. This incremental shape was easier to checkpoint and roll back than a large rewrite of the working base module, although it also created a later consolidation question.
That decision reduced overlap with working code. The first successful extension added Mosaic mode with two or three distinct eligible backgrounds, then Random + Mosaic with a 50/50 choice between the original single selection and a mosaic. Equal and weighted selection continued, with composition drawing without replacement so that different eligible records appeared together. Full Random Collage later allowed a maximum from two through six, with three as the conservative default. Per-record composition eligibility kept unsuitable items out of mosaics. The user-facing idea kept growing, but each addition remained optional so the original static, random and video behaviours were preserved.
Adding Separate random panels produced another informative sequence. The first installer stopped because Node.js was unavailable for JavaScript validation. A replacement used PHP structural checks, but a later guard still failed. Node 20.19.2 was then installed and the isolated candidates passed both Node syntax and structural checks. Node arrived late to the party and immediately became the bouncer.
Even a successfully validated candidate did not automatically survive deployment. One post-deployment public test called a WordPress CLI command with an invalid format value. The feature files were sound, but the test command was not. Because the transaction treated any final verification failure as grounds for restoration, it rolled the live theme back. The correction fixed the verifier and redeployed the same validated candidates. This episode is useful because “test failed” did not mean “feature was wrong.” Tests are software too, with all the usual opportunities for character development.
The first Separate panels behaviour then revealed a product misunderstanding. It placed each selected image once, independently. I had meant something else: selected images should repeat across the viewport, keep their configured dimensions, remain scattered, and avoid deliberately merging equal images into one giant repeated rectangle. A new renderer repeated every selected image several times, inherited saved dimensions, spread identical copies apart and limited the visible CSS copies to twenty-one.
That version was much closer, but screenshots showed large empty regions. Nothing had “broken”; pure random placement had clustered layers. Randomness has no contractual duty to look evenly random to a human eye. The next update distributed placements across viewport regions, added Light, Balanced and Dense settings, and provided an optional fixed or persistent random colour behind the scattered images. The colour filled gaps only in Separate panels and did not rewrite the colours of individual records or affect the other modes.
The most subtle bug concerned the relationship among Full Random Collage and the original layouts. I wanted Full Random Collage optionally to include Classic One, Classic Two, Classic Three and the scattered collage. A combined Two/Three checkbox was difficult to test visually, so it became two independent controls. Yet with Two unchecked and Three enabled, the browser still sometimes rendered Two. Saved PHP settings were correct. The remaining problem was overlapping client-side selection and persistence logic.
The final correction moved the layout decision to a server-authoritative selector, versioned its persistence state and disabled the obsolete browser selector. Exact test branches demonstrated that Three-only choices excluded Two and that the forced methods produced the corresponding counts. A final independent checkbox added the original One-background repeat. At the stopping point, Full Random Collage could choose among every explicitly enabled classic layout and the scattered layout, while the main display could still remain ordinary Mosaic instead of Random + Mosaic.
These rounds did more than repair code. They clarified what “random,” “separate,” “full collage” and “include the old modes” meant. A final specification could now express those ideas precisely. At the beginning, neither a human nor a model possessed that final specification in full.
What “managed agent” and “harness” mean here
The vocabulary is easy to blur. An agentic model can decide to call tools, examine their results and continue over multiple turns. An agent harness is the software around that model: the loop, tool definitions, workspace, state management, policies, hooks, retries, approvals, traces and evaluators. A managed agent usually means that a product or cloud service operates a substantial part of that harness and execution environment for the user.
The core loop is broadly shared:
objective ↓ observe repository and environment ↓ form or revise a plan ↓ call a tool and change candidate state ↓ run checks and inspect the result ↓ continue, recover, ask for approval, or stop
At this level, the major systems do share broadly similar principles: observe, reason, act, evaluate and continue. My initial intuition was therefore largely correct. Their operational differences remain significant. The model influences diagnosis, code quality, planning and visual judgment. The harness determines what evidence reaches the model, which actions exist, what persists across runs, when another evaluator appears and whether an incorrect decision can touch production.
| Layer | Responsibility | Background Studio consequence |
|---|---|---|
| Foundation model | Reasoning, source comprehension, implementation and tool choice | Understands the PHP/JavaScript boundary and proposes a coherent renderer |
| Harness | Repeated model–tool–observation loop | Keeps inspecting, patching and testing without another pasted command |
| Execution environment | Repository, shell, browser, packages and fixtures | Runs WordPress, Node, PHP and visual tests against candidates |
| Policy layer | Path, network, secret, budget and approval limits | Prevents arbitrary root writes or unapproved option changes |
| Evaluation layer | Parsers, tests, performance budgets and independent review | Detects record loss, persistence conflicts, sparse coverage and motion regressions |
| Persistent state | Plans, artifacts, traces, decisions and resumable work | Preserves which layout semantics and failures have already been established |
What the current managed-agent landscape changes
I researched this landscape on 14 August 2026 because product names and capabilities now change faster than a WordPress plugin menu. OpenAI’s current model guidance recommends GPT-5.6 Sol for complex reasoning and coding, with Terra and Luna variants for different cost and throughput needs. The same guidance describes programmatic tool calling for bounded tool-heavy work and a beta multi-agent capability. The OpenAI Agents SDK supplies agent loops, tools, handoffs, sandbox workspaces, sessions, human approvals, guardrails and tracing, while current Codex material emphasises durable objectives and long-running engineering work.
Google’s product uses the term most literally. Its Gemini API Managed Agents documentation describes reasoning, code execution, package installation, file management and web retrieval inside an isolated cloud sandbox. A July 2026 update added environment hooks that can block, lint or audit tool calls, token budgets that pause while preserving state, scheduled triggers and environment management. This is close to the imagined replacement for my repeated copy–run–paste cycle, although a cloud sandbox still needs an authorised connection before it can establish facts about a private VPS.
Anthropic’s March 2026 harness report is particularly relevant to a visual WordPress feature. It describes a planner, generator and evaluator arrangement; the evaluator used Playwright through MCP to navigate and screenshot the implementation before scoring it. The report is refreshingly candid about cost: an early full harness ran for six hours and cost more than twenty times its solo comparison, while a later simplified run remained nearly four hours. It also reports that self-evaluation was too generous until evaluator prompts and criteria were tuned. Managed does not mean free, instant or epistemically immaculate.
The model market reinforces the separation between model and harness. Moonshot’s official Kimi K3 release presents a native multimodal, long-horizon, one-million-token model, but its benchmark notes pair models with Kimi Code, Claude Code, Codex and other harnesses. Z.AI’s GLM-5.2 report similarly distinguishes a fixed evaluation harness from the “best reported harness.” DeepSeek’s official API change log exposes deepseek-v4-pro and deepseek-v4-flash through OpenAI-compatible and Anthropic-compatible interfaces, which makes the models portable into different orchestration systems; it does not by itself supply the same managed workspace, policy and evaluation layer.
This is why a leaderboard number is not a complete forecast for my project. A strong model inside a weak tool loop may repeatedly misunderstand the live source. A slightly less capable model inside a well-designed harness may inspect the right files, run the right browser cases and recover safely. Kimi K3’s published comparisons are unusually useful here because they make the harness pairing visible instead of treating the model as if it coded in a metaphysical vacuum.
How a managed agent would change the Background Studio process
The first improvement is direct inspection. The early installers failed because they searched for source shapes that did not exist. A managed coding agent with access to the actual repository could search the current PHP and JavaScript, map loader relationships, discover enqueued object names and inspect saved-option fixtures before designing the change. It would still be capable of misunderstanding them, but the misunderstanding would no longer begin with an incomplete transcript.
The second improvement is continuity. Instead of constructing a new temporary harness inside every Bash command, the workspace could retain the theme source, six-record fixture, tests, screenshots and previous evaluator findings. A failure such as “configuration object not recognised” could trigger another search and candidate revision in the same run. I would receive the corrected diff, trace and remaining uncertainties instead of another command whose main purpose was to obtain the missing line.
The third improvement is counterfactual testing. The live site showed only one saved configuration at a time. A managed sandbox could cheaply generate a matrix of states:
{
"display_modes": [
"static",
"random",
"mosaic",
"random_mosaic"
],
"collage_layouts": [
"classic_one",
"classic_two",
"classic_three",
"scattered"
],
"persistence": [
"page",
"session",
"day"
],
"random_method": [
"equal",
"weighted"
],
"reduced_motion": [false, true],
"viewport": [
"mobile",
"tablet",
"desktop",
"wide"
]
}
The complete Cartesian product would be wasteful, so a test planner could select pairwise coverage plus high-risk exact cases. Three-only must never produce Classic Two. Session mode must persist the selected composition across navigation. Daily mode must roll over on the UTC date boundary. Reduced motion must choose the explicit fallback before mosaic construction. Weighted selection without replacement must never duplicate an item unless duplication is explicitly allowed. The six saved records must remain equivalent except for intentionally added schema fields.
A managed agent could also build regression fixtures when evidence exposes a new semantic boundary. Once the server/client conflict appeared, a test could assert that exactly one layer owns layout selection. Once the invalid WordPress CLI format option appeared, the verification command itself could become a tested script. Once Node absence caused a stop, JavaScript validation could run in the managed sandbox image instead of changing production merely to gain a parser.
The visual part can also become agentic
Background Studio is an unusually good example of why syntax and unit tests are insufficient. PHP lint could confirm that a renderer parsed. Node could confirm that JavaScript parsed. Neither could decide whether a sea-lion image and a Hilbert pattern had fused into a visually dominant block, whether three panels felt sufficiently separate, or whether the lower half of the viewport looked abandoned. That does not mean visual verification must remain manual. Current agentic systems can control a browser, inspect the DOM, take screenshots, compare viewports and use vision-capable models to evaluate what they see.
A managed browser evaluator could load deterministic seeds, capture the DOM and screenshots at several viewports, and calculate useful measurements: uncovered viewport area, overlap ratio, minimum spacing between equal-media copies, number of visible distinct items, content occlusion, and whether the background container changed layout metrics. A vision-capable evaluator could compare the screenshots with a written design rubric, send concrete criticism back to the implementation agent and repeat the cycle until the candidate passed. This is a genuine agentic loop, not merely a screenshot generator waiting for me to do all the interpretation.
{
"criterion": "separate_random_panels",
"requirements": {
"distinct_selected_media_visible": 3,
"intentional_full_grid": false,
"same_media_large_joined_block": false,
"configured_dimensions_inherited": true,
"maximum_uncovered_ratio": 0.35,
"content_layer_interactive": true,
"background_pointer_events": "none"
},
"automatic_actions": [
"reject failed geometry",
"capture another random seed",
"revise placement algorithm",
"rerun viewport and performance checks"
],
"escalate_when": [
"the visual objective is still ambiguous",
"evaluators disagree",
"a new aesthetic direction is proposed"
]
}
The numeric threshold above is a proposed evaluation contract, not a confirmed property of the final plugin. It could initially be calibrated against screenshots I accept and reject, then operate automatically for later changes within the same design language. Anthropic’s harness report makes the same general point: subjective evaluation improves when taste is translated into concrete criteria, and an evaluator can use Playwright and screenshots to drive another implementation round. The evaluator itself still needs calibration and regression testing, just like any other component.
This could have shortened several conversational rounds. The agent might first generate strict non-overlap, balanced scatter and dense scatter variants, score them, discard candidates that violate objective constraints and continue refining the strongest one. If the written requirement still allowed several genuinely different aesthetics, it could present that smaller decision to me. After my choice entered the rubric, similar future changes could be evaluated without another mandatory human round. Human judgment supplies missing product meaning; it need not duplicate visual work the agent can already perform.
Performance could be measured instead of discussed abstractly
The original conservative recommendation was two or three simultaneous animated items. That remains sensible. Several GIFs can increase decoding, painting, memory, CPU and battery use even when HTTP caching prevents repeated downloads. Twenty-one CSS layers are a visual ceiling, not a recommendation to animate twenty-one independent GIFs. Static WebP and SVG copies are a different workload from animated media.
A managed browser environment could collect performance traces for representative fixtures and compare them with budgets. It could test mobile emulation, reduced-motion mode, background-tab behaviour and slow-network caching. The exact budget should be established empirically instead of invented in prose. Useful evidence would include transferred bytes, decoded image memory where observable, animation frame consistency, long tasks, style/paint time and the number of composited layers.
The agent could then recommend and enforce a policy based on media type: allow Dense scattering for lightweight stills, warn when several animated GIF records are selected, default Full Random Collage to three, and require deliberate confirmation before a higher animated-media ceiling. The best code path may also reuse one decoded URL across repeated CSS layers. Browser caching helps, but caching is not a sacrament that absolves every compositor cost.
How the real failures would look inside a managed run
| Observed iteration | Semi-automated response | Managed-agent response |
|---|---|---|
| Expected PHP administration row was absent | Installer stopped; I returned the log; another command used a different anchor | The agent searches the checked-out source, revises its patch and reruns candidate tests in the same task |
| Expected frontend enqueue call was absent | Second safe failure and another conversational round | A repository map identifies the actual enqueue function and loader relationship before implementation |
| Node.js unavailable | Installation stopped; alternative structural checks were attempted; Node 20.19.2 was later installed | An ephemeral test image supplies the parser; production gains no package unless it has an operational purpose |
| Invalid WP-CLI public-test parameter | Post-deployment verification failed and automatic restoration returned the site to safety | An evaluator tests the verifier in staging before promotion; rollback remains the final production guard |
| Separate panels rendered only one copy of each image | A screenshot and explanation changed the product interpretation | Visual variants and an acceptance contract expose the ambiguity before deployment |
| Random scatter left large empty areas | Further screenshots led to region balancing, density controls and a gap colour | Seeded screenshot tests measure coverage and drive automatic placement revisions |
| Three-only still produced Two | Settings were audited, client selection was disabled and authority moved server-side | State-machine tests enumerate owners, cookies and persistence keys, then reject multiple selectors for one decision |
The managed column is not a claim that the first generated solution would be perfect. It describes where the corrective loop would execute. In the original method I manually transported each failure back into reasoning. A managed agent could retain the candidate, interrogate more evidence and perform several repair cycles before returning. That is a genuine gain.
There is also a different risk: an autonomous agent could perform several wrong repairs before I saw the first one. Requiring a click after every rg search would not solve that well. Isolated candidate work, retained traces, protected tests, path and token budgets, and a separate production capability give the system room to iterate without giving each intermediate hypothesis production consequences.
The architecture I would choose now
I would use a managed development plane and a deterministic production plane. The managed side would contain a canonical private repository, anonymised option fixtures, a disposable WordPress environment, browser automation and test artifacts. The live server would expose a small deployment bridge instead of a general root shell.
Managed development plane
├── repository and architecture map
├── planner for the requested behaviour
├── implementation agent
├── deterministic PHP, JavaScript and CSS checks
├── WordPress option and bootstrap fixtures
├── browser and screenshot evaluator
├── performance test cases
├── preserved traces and candidate diffs
└── immutable deployment bundle
│
│ approved or policy-authorised request
▼
Restricted production bridge
├── inspect named theme files
├── read sanitised Background Studio settings
├── report saved-record IDs and count
├── create timestamped checkpoint
├── deploy allowlisted bundle paths
├── run named WordPress and HTTP checks
└── restore named checkpoint
│
▼
Deterministic live WordPress site
├── PHP validation and option schema
├── ordinary JavaScript selection
├── CSS/DOM background rendering
├── page, session and daily persistence
└── reduced-motion fallback
This architecture avoids two unnecessary limitations. A repository-only agent can write and test the plugin safely, but it cannot establish that production uses the expected theme, option or asset URLs. A root-connected agent can inspect everything and change anything, which converts an implementation mistake into a server-administration event. The narrow bridge supplies the missing evidence and deployment actions without expanding authority to the whole VPS.
The deployment bundle should be immutable and reviewable:
{
"change_id": "background-collage-layout-v4",
"expected_record_count": 6,
"expected_record_ids": [
"chemical",
"hilbert",
"background_example_1",
"background_example_2",
"background_example_3",
"background_example_4"
],
"affected_paths": [
"inc/background-collage-layout-mix-extension.php",
"js/background-collage-layout-mix-admin.js"
],
"validation": {
"php_lint": "passed",
"node_syntax": "passed",
"option_round_trip": "passed",
"layout_state_matrix": "passed",
"browser_screenshots": "passed",
"performance_budget": "passed",
"wordpress_bootstrap": "pending-production"
},
"rollback": true,
"requested_action": "deploy_allowlisted_bundle"
}
The identifiers above are anonymised examples, and the manifest is a proposed design instead of an artifact that existed during the original work. In production, the bridge would recompute hashes, compare the current live source with the bundle’s expected base, count the records before and after, create its own checkpoint, deploy only the declared paths, rerun local parsers and return structured evidence.
One agent, several agents, or a simpler loop?
I would not begin by assigning a committee of five frontier models to every CSS adjustment. Anthropic’s experiments show that planner/generator/evaluator structures can produce meaningful gains on difficult long-running builds, but they also show substantial time and cost. OpenAI’s current multi-agent capability likewise makes parallelism useful when work divides cleanly. More agents create more handoffs, duplicated context and opportunities for confident consensus around the same bad assumption.
For a bounded Background Studio correction, one strong coding agent plus deterministic tests and a separate visual evaluator may be enough. A planner becomes valuable for a multi-mode redesign or consolidation of the extension files. A specialist evaluator becomes valuable when the generator is operating near its reliable frontier: cross-browser persistence, visual placement and performance regression are good examples. A cheaper model can classify logs or summarise traces; a stronger model can investigate the server/client authority conflict. Model routing should follow measured task difficulty.
The open and proprietary model choices also create deployment options. GPT-5.6, current Claude models, Gemini, Kimi K3, GLM-5.2 and DeepSeek V4 Pro all participate in the broader agentic engineering landscape, but they do not arrive with identical environments or policies. Kimi, GLM and DeepSeek can be placed inside third-party coding harnesses; Google’s Managed Agents provides a hosted sandbox loop; OpenAI offers both Codex and an SDK for custom orchestration. The optimal choice depends on where the source may travel, which tools are required, latency and cost, vision quality, audit requirements and how much harness code I want to own.
I would therefore benchmark candidate systems on a small Background Studio evaluation suite instead of choosing by brand reputation. Give each system the same base repository and tasks: add an allowlisted field without losing six records; diagnose a stale client selector; render and visually inspect a three-item composition; preserve reduced motion; reject an invalid dimension; and produce a deployment bundle without touching unrelated files. The system that performs those tasks reliably under the required policy is more relevant than the system with the most impressive general benchmark.
What I would automate, and what I would gate
| Action | Recommended default | Reason |
|---|---|---|
| Read repository source and build an architecture map | Automatic | Low impact and essential to avoid invented anchors |
| Create fixtures, patches and screenshots in a sandbox | Automatic | Reversible, inspectable and isolated from visitors |
| Run PHP, Node, CSS, WordPress and browser checks | Automatic | These are executable acceptance conditions |
| Retry after a classified transient tool failure | Automatic within a budget | No new product decision is normally required |
| Generate, inspect and rank visual variants | Automatic when the rubric is established; escalate genuine ambiguity | Browser geometry and vision evaluation can resolve most repetitions of a known design goal |
| Deploy an allowlisted, tested bundle with rollback | Focused approval initially; automatic for proven change classes | Production impact is real but tightly bounded |
| Change the option schema or migrate saved records | Automatic candidate and migration tests; production gate until proven | The agent can do the engineering, while durable-data promotion receives stronger evidence |
| Install production packages or grant a new capability | Explicit approval | It changes the agent’s future authority and the server’s operational surface |
| Use an unrestricted root shell or modify unrelated WordPress data | Unavailable | The Background Studio task does not require that authority |
The approval boundary can evolve. After repeated successful deployments of the same class, an exact file update with a valid rollback and green test bundle might be promoted automatically. A new database migration, media deletion or privilege expansion should still stop. This is progressive autonomy based on evidence, not a ceremonial insistence that my finger touch every Enter key.
A WordPress “one-click AI deployment” plugin could also be built. It could display a signed candidate summary, request an administrator nonce, invoke the restricted controller, stream redacted status and expose rollback. It should not accept arbitrary generated PHP from the browser and execute it as root. The plugin would be an interface to the capability bridge, while the managed agent performed the actual development and evaluation in its workspace.
What should remain deterministic
The public background selector does not need a managed model. Equal and weighted sampling, selection without replacement, persistence keys, reduced-motion precedence and CSS rendering are ordinary application logic. They are cheaper, faster and more reproducible when expressed in PHP and JavaScript. An LLM deciding the visitor’s background on every request would add network dependency, privacy questions, latency and a new failure mode to a problem already solved by a few random numbers.
Server-side sanitisation should also remain deterministic. An allowlist can prove that a submitted mode is one of the accepted values. A dimension parser can prove that 256 becomes 256px and that unsupported text is rejected. A record-count assertion can prove that six records did not become five. The agent can write, improve and call those checks. It should not replace them with “the option array looks plausible.”
Persistence deserves the same treatment. The earlier Three-only bug existed partly because more than one layer attempted to own a choice. The final design moved authority server-side and versioned the client state. A managed agent can diagnose and test that architecture, but the production decision should remain an explicit state machine instead of an inference.
This distinction is important. Agentic development does not imply that AI must inhabit every layer of the finished application. The agent can autonomously design, test and improve deterministic software. In many cases that is the better result: a highly capable development process producing a simple and dependable runtime.
Human agency in a more autonomous workflow
In the semi-automated workflow, my participation was highly visible. I formulated the request, ran each script, observed whether the terminal remained open, pasted the log, looked at the page and answered “so?” when a technically elaborate result still did not match the visual goal. Some of that activity was substantive. Some was simply data transport.
Managed execution would remove much of the transport and could also reduce my day-to-day involvement in diagnosis, coding and visual checking. That can be an improvement. My most consequential contributions in the original project were identifying the desired relation among images, protecting all six records, rejecting a full-screen overlay that hid lower layers, accepting a mixed DOM/CSS architecture, deciding that occasional adjacency was fine but intentional giant blocks were not, recognising excessive empty space, requesting density and gap-colour controls, and insisting that Classic One, Two and Three remain independently selectable. Once these choices are encoded, the agent need not ask me to repeat them.
Those decisions shaped the object being built. An agent could have implemented the final specification faster if I had possessed it on day one. I did not. The specification emerged through seeing real outputs and revising my own language. An agentic workflow can support this discovery more efficiently by generating controlled variants, measuring them, explaining their trade-offs and updating its rubric from my response. It may also propose a better design than my first idea. The important test is whether its reasoning and evidence are inspectable enough for that change of direction to be understood.
Human disagreement is not the only evidence of agency. If an evaluator demonstrates that a grid gives better coverage, lower paint cost and clearer separation than my first idea, accepting that result after inspection is also a human decision. The goal is not to win arguments against the model. It is to retain meaningful influence over purposes, constraints and consequences while allowing technical evidence to change my mind.
Approval fatigue complicates the picture. Clicking “allow” for every file read can make participation visible while making judgment disappear. A well-designed harness should automate low-risk reads, sandbox writes, browser interactions and deterministic checks, then interrupt me for unresolved aesthetic ambiguity, new authority, irreversible operations or unfamiliar production consequences. Fewer approvals can create more agency when each approval corresponds to a real decision.
The educational value depends on inspectability
A managed agent could compress the entire Background Studio history into a clean pull request. That would be useful engineering. It might also remove the moments in which I learned why CSS multiple layers differ from visibly partitioned regions, why randomness clusters, why a verifier can be wrong, why server and browser persistence can conflict, and why a safe patch anchor should fail loudly.
The answer is not to preserve manual inconvenience for educational theatre. It is to retain an inspectable record: the initial objective, architecture map, proposed plan, capability policy, important tool calls, candidate diff, failed tests, screenshot comparisons, evaluator criticism, human decisions and final acceptance evidence. A student or maintainer should be able to explain why the system chose a fixed grid for classic mosaics, controlled layers for scatter, and no Canvas; why reduced motion precedes composition; and why production never needed a model in its page-load path.
An “agency ledger” for one visual iteration might look like this:
| Field | Example |
|---|---|
| Observed state | Three selected images formed a visually continuous block |
| Initial AI interpretation | Render each selected item once in an independent panel |
| Human clarification | Repeat the selected images across the viewport, inherit saved sizes and avoid deliberately adjoining equal copies |
| Candidate result | Scattered repetitions with a twenty-one-copy ceiling |
| New evidence | Screenshots showed excessive uncovered space under some random seeds |
| Revised design | Balanced regions, selectable density and an optional gap colour |
| Future agentic equivalent | Seeded browser runs measure coverage, the evaluator rejects sparse candidates, and the implementation agent iterates automatically |
| Final validation | PHP, JavaScript, CSS, WordPress bootstrap, public page and six-record preservation all pass |
This record shows collaboration without pretending that code authorship and accountability are identical. In the original process, the AI generated most implementation text, deterministic tools established syntax and runtime facts, the live browser supplied visual evidence, and I clarified what counted as an acceptable background. In a managed version, much of that evidence cycle could occur autonomously while remaining available for later inspection.
The agentic experiment I would run now
I would begin with a real managed run, not another conceptual comparison. The current working theme source and a sanitised six-record option fixture would enter a private canonical repository. A reproducible workspace would match the relevant versions—PHP 8.4, WordPress 7.0, Penscratch and Node 20—and include safe SVG, GIF and WebP test assets plus a static reduced-motion fallback. The agent’s first task would be to reconstruct the architecture and prove that its description matches the source.
Its second task would be to turn the development history into a regression suite. The suite would cover option round trips, invalid dimensions, equal and weighted distinct selection, page/session/day persistence, reduced motion, Classic One/Two/Three, scattered density, fixed and random gap colours, the disabled feature path and preservation of all six records. Browser automation would run seeded randomness at mobile, tablet, desktop and wide viewports, recording screenshots, geometry and performance evidence.
I would then give the agent one bounded improvement to complete end to end. A suitable experiment might be consolidating one pair of overlapping extension scripts without changing behaviour, or adding a warning when a selected composition exceeds an established animated-media budget. The agent would inspect, plan, patch, run deterministic checks, visually evaluate the result, revise failures and produce a final diff and evidence bundle. I would not carry intermediate shell output between turns.
The success condition would be stronger than “the agent wrote code.” It would need to demonstrate that the six records survived, every layout and persistence branch behaved correctly, reduced motion still took precedence, screenshots met the established rubric, the public page loaded without layout shift and rollback material existed. If the agent repaired its own failed tests or visual result during the same managed run, that would be direct evidence that the new workflow had replaced the old relay instead of merely wrapping it in a new interface.
After that sandbox run, a production bridge could initially expose read-only comparison: live hashes, WordPress version, theme state, option count and public assets. The next step would add exact checkpoint, deployment, verification and rollback actions for allowlisted theme paths. A bundle that matches the expected base and passes the established suite could receive one focused approval at first; after repeated successful changes of the same class, promotion could become automatic.
This sequence is not a concession to the semi-automated workflow. It is ordinary engineering separation between development and production. The agent remains autonomous across inspection, implementation, testing and visual evaluation. Production authority grows according to observed reliability, just as CI/CD systems earn broader deployment roles after their invariants are established.
Risks and unresolved questions
A managed workflow does not remove hallucination; it changes the feedback available after one. A model can misread a screenshot, overfit a coverage metric, edit tests to accommodate its own bug or accept an evaluator’s superficial approval. Independent deterministic checks, protected tests and sceptically tuned evaluation remain necessary.
Cloud execution also creates data-governance questions. Theme source may be harmless enough for a private hosted workspace, while production options, logs or unpublished media could require stricter handling. The capability bridge should redact secrets locally and send only the data required for the task. Open-weight models such as Kimi K3, GLM-5.2 and DeepSeek V4 broaden deployment choices, but self-hosting a very large model is not automatically simpler than using a managed service. Operations have a way of returning through the side door carrying a GPU invoice.
Visual tests can become brittle. Exact pixel diffs may fail after a browser update even when the design remains good, while loose vision evaluation may miss a real regression. The best suite will combine DOM assertions, geometric thresholds, selected reference screenshots and vision evaluation. Human review remains available for a genuinely new aesthetic direction, but it does not need to be the normal verifier for every iteration.
Performance remains device-dependent. A desktop trace cannot guarantee acceptable battery use on every phone. The twenty-one-copy ceiling and default maximum of three are conservative design controls, but further real-device measurement is still needed if several animated GIFs are enabled together. A future improvement could classify animation and warn about expensive combinations without automatically altering the saved choice.
Finally, the current extension architecture grew incrementally. That protected working code during a risky live development process, but several extension loaders and overlapping scripts are harder to maintain than one deliberately designed module. A managed agent with complete regression coverage could propose consolidation. It should first prove behavioural equivalence across every persistence and layout branch. Refactoring because the file tree looks untidy is not yet evidence that the resulting system is safer.
How my workflow would actually change
The largest change is that one request could contain several engineering rounds. The agent would inspect the whole codebase, maintain a durable plan, build fixtures, run PHP and Node checks, launch WordPress, capture screenshots, compare performance, receive criticism from a separate evaluator and revise before returning. My current pattern of command, log, correction, new command would contract into one observable managed task.
Checkpointing, candidate validation, record preservation, public testing and rollback would stop being regenerated inside every installer. They would become reusable harness capabilities, tested centrally and invoked automatically. The same applies to visual verification: seeded browser runs and evaluator criteria would become part of the normal definition of done instead of an informal inspection after deployment.
My interaction with the AI would move toward objectives, product semantics and exceptional decisions. I could still steer a running task when a screenshot revealed a new preference, but I would not need to approve each search, parser call or corrective patch. When the rubric already covered the situation, the agent could perform the visual iteration itself.
The live renderer would remain deterministic and server-side PHP would remain authoritative because those are sound application boundaries, not remnants of manual development. Invalid administration input must still be rejected, media records must not be silently rewritten, and the saved-record invariant must remain machine-enforced. Agentic engineering improves how the code is developed and verified; it does not require turning every runtime decision into an AI request.
In practical terms, the old workflow would become the source of tests for the new one. Its successful constraints would move into code, its failures would become fixtures, and its manual transport steps would disappear. That is the change I would now want to evaluate in a real managed run.
Conclusion
Yin’s Background Studio reached a satisfying result through an inspectable semi-automated process. The original single-background selector survived. Mosaic and Random + Mosaic became optional. Full Random Collage gained a conservative maximum, distinct eligible selection, scattered repetition, saved-size inheritance, balanced coverage, density and fixed or random gap colours. Classic One, Two and Three became independent choices. Reduced motion, equal and weighted selection, page/session/day persistence, images, SVG, GIF, WebP and the original single-video behaviour remained part of the system. Every successful deployment preserved six saved records and passed PHP, JavaScript, CSS, WordPress and public-asset checks.
A contemporary managed agent could improve this workflow substantially. It could read the actual source before patching, carry state across corrections, generate counterfactual fixtures, use a browser and vision model as evidence, separate implementation from evaluation, measure performance, and return a verified bundle instead of another monolithic installer. The strongest current models make that prospect more credible; the surrounding harness determines whether their capability becomes reliable engineering.
For this project, the better next workflow is a managed development agent with direct repository access, reusable deterministic evaluations, browser-based visual verification and a reversible production bridge. That arrangement can remove most of the command relay, diagnose several failures within one task, and test many more states than I could reasonably inspect by refreshing the live site.
My agency would become less visible at the level of individual terminal commands and more visible in objectives, product meaning, evaluator criteria and authority design. It would also be reasonable for the agent to change my initial technical preference when its evidence supported a better solution. The important question is no longer whether I or the AI “made” the feature. It is whether the managed process produced a background system that is correct, recoverable, understandable and responsive to the purpose I was trying to achieve.
Sources and further reading
- OpenAI: GPT-5.6 model guidance, including programmatic tool calling and multi-agent beta
- OpenAI Agents SDK: agent loops, sandbox agents, guardrails, sessions, human-in-the-loop and tracing
- OpenAI Agents SDK: tracing agent runs, tool calls, handoffs and guardrails
- Google: Antigravity managed agent in the Gemini API
- Google: managed-agent hooks, budgets, triggers and environment controls
- Anthropic: harness design for long-running application development
- Anthropic: evaluating AI agents
- Anthropic: official model system-card index
- Moonshot AI: official Kimi K3 repository and evaluation notes
- Z.AI: GLM-5.2 and long-horizon agentic engineering
- DeepSeek: official API change log for DeepSeek V4 Pro and Flash