This note describes the public-safe architecture behind the engineering loop we use to improve xCloud's plugin-based WordPress migrations. It intentionally excludes credentials, customer data, internal endpoints, infrastructure details, raw logs, and private repository information.
The loop improved the recent terminal migration success rate from roughly 20% to 100% in the latest rolling 24-hour cohort. That latest cohort contained seven finished migrations and zero failed migrations.
A database status alone is not enough. We also checked whether each destination still existed, whether its server remained provisioned, whether the site responded over HTTP, and whether a missing site had shown credible post-migration activity before it was later deleted.
Our primary operational calculation is:
terminal success rate = finished / (finished + failed)
Canceled and unresolved migrations are reported separately. We also calculate a stricter rate against every launched attempt so cancellations cannot disappear from the picture.
This is a recent cohort result, not a permanent claim. The purpose of the loop is to keep measuring it.
A loop gives an agent a bounded objective, evidence from the environment, verification rules, and a stopping condition.
Our migration reliability loop is:
measure production cohort
-> verify claimed successes
-> collect failed-event evidence
-> sanitize and classify
-> choose the first unrecovered failure
-> request human approval
-> reproduce in Docker
-> add a failing automated test
-> make the smallest fix in the owning component
-> run focused tests and full migration QA
-> human review and release
-> measure the next production cohort
-> repeat
The agent does not decide that its own code is correct. Tests, destination checks, process exit codes, and human review provide the evidence.
A loop is one cycle. Graph engineering connects several specialized loops and deterministic checks into a controlled workflow.
In this system, each node has a narrow responsibility:
flowchart TD
A[Daily production monitor] --> B[Compare rolling cohorts]
B --> C[Verify finished destinations]
B --> D{Any failed migrations?}
D -- No --> E[Publish reliability report]
D -- Yes --> F[Recover authorized event evidence]
F --> G[Sanitize and classify patterns]
G --> H[Choose first unrecovered failure]
H --> I{Human approval to reproduce?}
I -- No --> E
I -- Yes --> J[Docker reproduction loop]
J --> K[Automated regression test]
K --> L{Owning component}
L --> M[WordPress source plugin fix]
L --> N[xCloud destination client fix]
M --> O[Focused tests and migration QA]
N --> O
O --> P{Human review and release decision}
P -- Approved --> Q[Measure next cohort]
P -- Rejected --> J
Q --> A
C --> E
R[Manual performance review] -. successful logs .-> S[Benchmark algorithm candidates]
S -. approved optimization .-> O
The graph contains multiple loops:
- Monitoring loop: compare current and previous production cohorts.
- Evidence loop: collect, sanitize, classify, and prioritize failures.
- Reproduction loop: recreate one failure until the trigger is deterministic.
- Implementation loop: failing test, minimal fix, focused verification.
- QA loop: run the real migration and destination checks.
- Release feedback loop: measure whether the next cohort actually improved.
- Performance loop: occasionally benchmark successful migrations for speed and resource improvements. This is separate from daily reliability work.
The graph controls how these loops connect, which steps may run automatically, where work must stop, and where a human decision is required.
Agent Bridge gives the investigation loop authorized access to event output. The raw evidence may contain customer-specific or security-sensitive information, so it never goes directly into issues, pull requests, reports, or agent memory.
The evidence pipeline keeps only bounded fields such as:
migration attempt identifier
plugin and client version
stage and timestamps
process exit code
retry count
sanitized error code
verified destination result
Before analysis, it removes domains, URLs, email addresses, tokens, credentials, database identifiers, customer paths, and raw commands. Reports use aggregate patterns and synthetic reproduction fixtures instead of customer logs.
An empty task-output field is not automatically treated as missing evidence. Some tasks intentionally avoid storing output in the application database while an authorized server-side event log still exists.
The local migration lab models the complete path rather than mocking the final status:
source WordPress container
-> migration plugin API
-> generated destination migration client
-> destination WordPress container
-> database import and finalization
-> destination verification
The fixture can vary:
- source and destination PHP versions;
- WordPress versions;
- file size and file count;
- database size and table count;
- permissions and ownership;
- WP-CLI plugin, theme, or drop-in failures;
- interrupted downloads and retry behavior;
- database connectivity and import errors;
- cleanup and destination HTTP failures.
For every issue, the first automated test must fail for the same expected reason before the product code changes. After the fix, the focused test and the complete source-to-destination migration must pass.
The first unrecovered failure determines the likely owner:
| Failure area | Likely owner |
|---|---|
| Source authentication, archive creation, dump generation, plugin API behavior | WordPress migration plugin |
| Chunk download, extraction, destination writes, database import | Destination migration client |
| Permissions, URL replacement, callbacks, progress, finalization | xCloud orchestration/client |
| Disk, DNS, TLS, or temporary database outage | Environment, plus product retry/preflight behavior where justified |
| Missing or unusable evidence | Observability path before product code |
We do not fix the last generic wrapper error if an earlier specific failure caused it. We also do not hide infrastructure failures merely to make the success percentage look better.
A migration is considered strongly verified only when applicable checks pass:
- client process exits successfully;
- no failed or canceled terminal state remains;
- expected files and database tables exist;
- destination URLs and configuration are correct;
- ownership permits normal site operation;
- required temporary artifacts are removed;
- destination HTTP check succeeds;
- progress belongs to the active migration and does not regress.
A code change must also pass:
- deterministic failing test before the fix;
- focused automated test after the fix;
- adjacent regression checks;
- complete Docker migration QA;
- credential and sensitive-output scan;
- human code review and release approval.
The daily monitor may query read-only metrics, verify finished destinations, retrieve authorized logs, sanitize evidence, classify patterns, and recommend the next action.
It must stop and request permission before it:
- starts reproduction work;
- changes plugin or client code;
- creates or publishes a fix;
- deploys or releases anything;
- changes production data or infrastructure.
Agents run the inner investigation and verification loops. Engineers own scope, risk, approval, release, and accountability.
Use a loop when all of these are true:
[ ] The input is observable.
[ ] Success and failure are measurable.
[ ] The environment can be reproduced or simulated faithfully.
[ ] Deterministic tests or checks can judge progress.
[ ] The agent has a strict tool and permission boundary.
[ ] A stopping condition exists.
[ ] A human owns risky actions and release decisions.
Move to a graph when one loop is no longer enough and the work needs specialized stages, parallel branches, retries, handoffs, shared state, or approval gates.
Avoid autonomous loops for vague goals such as "improve the product" or "refactor the codebase." A useful loop needs a narrow target such as "reduce this verified failure signature without weakening destination checks."
- Loop Engineering — Addy Osmani
- Loop Engineering: Three Key Loops for Building Great Software — Andrew Ng
- Humans and Agents in Software Engineering Loops — Kief Morris / Martin Fowler
- 3 Years of Graph Engineering with LangGraph — Sydney Runkle and Harrison Chase
The terminology is new, but the engineering principles are familiar: bounded workflows, reproducible environments, deterministic checks, observable state, small changes, and accountable release decisions.