PetV3 Agent Factory 1: Designing the Failures Before the Automation

PetV3 automation system, part 1 of 4

PetV3 did not begin as an agent control plane. The original goal was much smaller: put a character on the desktop, show what Codex and Claude were doing, and let me reply from the same surface when needed.

The first plan used Tauri and React. That was a reasonable way to build a desktop application quickly, but it optimized the wrong result. A browser-like control window appeared before the pet itself was reliably visible and interactive on my GNOME desktop.

That failure produced the first rule:

The real operating environment, not a mock interface, must be the first acceptance gate.

Let the product constraint choose the architecture

My machine runs Ubuntu GNOME Wayland with XWayland and two 6K displays. Instead of carrying a complete WebView runtime for a small overlay, I moved rendering and input to a native Rust boundary.

The architecture settled into this shape:

portable Rust core
        │
        ├── Linux: X11/XRender/XFixes/XRandR surface
        ├── Windows: future native surface
        └── macOS: future native surface

The portable core owns coordinates, state, animation, and IPC contracts. Platform code owns windows, input, monitors, and transparent composition. I did not implement every platform up front. I implemented the thinnest boundary that worked on the current machine and made the replacement seam explicit.

An early release demo ran for 20 seconds at 28.3 presented frames per second and 38.7MiB RSS. On the second 6K monitor, a requested position of (6500, 200) matched the actual position, with ARGB, XFixes, and always-on-top behavior verified. Those numbers are not a claim about current performance. They are evidence that the architecture was alive on the real desktop at that point in time.

Why an automation system became necessary

The hard problem was not the amount of code. It was the loss of truth as different tasks moved at different speeds.

• A branch could contain commits without having passed its gates.
• A feature could exist without being called by production code.
• The dashboard could run an old release binary against newer source.
• One worker could report that documentation placement was correct while another found three misplaced blocks.
• A file could change after a gate but before a commit, leaving a main HEAD that could not build on its own.

The goal changed from “run many agents” to “do not manufacture false success.”

The system now had to do four things:

1. Distribute work with visible overlap boundaries.
2. Re-read current facts from the repository and tests instead of trusting reports.
3. Make the verified bytes identical to the bytes that land.
4. Preserve context across conversations and providers without treating old snapshots as current truth.

I reduced the use of the word “done”

PetV3 deliberately uses question marks and negative statements in its status vocabulary.

• working?: recent file activity is a hint, not proof that a process is alive.
• no progress evidence: missing data is not a fabricated zero percent.
• “implemented but not called”: implementation and integration are different states.
• “human verification required”: if Wayland blocks a capture, the system does not claim a visual result.

This language is not caution for its own sake. It is a data model that preserves the resolution of facts when another agent takes over.

The first conclusion

What I built is not an infinite coding loop. It is closer to a small factory that connects product constraints, Git state, test evidence, usage budgets, and human authority.

The next post covers the factory floor: isolated worktrees, an overlap ledger, and a central landing gate.

Next: PetV3 Agent Factory 2: Safe Landing Before Parallelism