PetV3 Agent Factory 3: From Curiosity to an Operating Dashboard

PetV3 automation system, part 3 of 4

I did not begin this experiment with a mature plan for an agent control system. I began with curiosity. I already had subscriptions and usage available, I could see people in the community building agent systems, and I knew the underlying capabilities existed. I wanted to find out whether I could make them work together in a system I could actually use.

I had never used Rust or MCP before, and I had never designed or operated a multi-agent system through prompts and conversations. I did have a software-development background and was familiar with concepts such as clustering and distributed systems. What was new was applying those ideas through the formal procedures and internal mechanics of multi-agent operation. I learned that through ongoing conversations, prompts, and hands-on use, gradually forming an approach to controlling the work.

That starting point matters because the result was neither a one-prompt miracle nor a finished autonomous control plane. It was a practical learning process: I gave direction, the AI implemented much of the work, I tested what appeared, and then I revised the plan or the prompt when reality did not match the idea.

Applying a familiar coordination model to agent work

Before this project, I already knew how larger organizations coordinate substantial work through tickets, separated work streams, pull-request review, and merging. The question behind the Git workshop in the previous post was whether I could attach that familiar coordination model to the actual work of AI agents in a personal project.

Branches and worktrees separated agent tasks and preserved changes in progress. Pull requests and merging provided a safer, reviewable boundary for bringing an agent-produced change back into the project instead of mixing it in as soon as it was reported complete. The ledger could record who had claimed what, while checkpoints could leave the project in a state that another prompt or provider could understand.

This was a purposeful application of an existing collaboration pattern, not a discovery of what Git records or how merging works. What I had not done before was operate that pattern formally with prompt-driven agents. Because those agents worked asynchronously, I still had to experiment with task boundaries, overlapping files, review order, and how their work would eventually come back together.

At one point I stopped the system because the agent-management layer itself had become the problem. I wanted one supervising model to watch commits and subtask states, notice when agents drifted from the current code, anticipate collisions, and redistribute the recorded queue. That change of direction came from operating the workflow, not from drawing a perfect architecture in advance.

An operating approach emerged

Prompting was only one part of my role, but I did not begin with a complete philosophy. A rule about what “done” should mean became clearer as I watched the system work: a task is not acceptable merely because the process ended. If an agent fails, that failure should remain visible. It should be reviewed, retried when appropriate, or deliberately accounted for. A system that quietly turns failure into apparent completion is not useful to me.

That developing approach shaped the dashboard. I did not want a polished but invented percentage such as “73% complete.” I wanted states supported by observable evidence from Git and the ledger: working? · fresh claim, WIP commit · working?, committed · waiting to land, or no progress evidence. Even the question mark mattered. A recent claim or file timestamp was evidence of activity, not proof that a process was healthy.

As the experiment grew, my role became planning the work, giving direction, setting constraints, and deciding what needed testing or review. The AI turned many of those decisions into code, but it could not take responsibility for whether the decisions were sound. The accountability boundary remained mine.

The clearest example was stopping work safely. When I chose to hand the project from one provider to another, I did not simply say “stop.” I directed the system not to start new work, commits, merges, cleanup, or builds; asked active workers to stop at a safe boundary; required the worktrees and uncommitted state to be inventoried; and preserved unfinished changes for the next session. Later, the workflow also recorded a safe pause at a usage cap and the material needed to resume. Continuity was part of correctness.

What working with the AI actually looked like

The implementation process was iterative and uneven. I would describe the behavior I wanted, inspect the result, explain what had failed, make the instruction more precise, and try again. Models did not follow every instruction consistently. Some attempts failed during hands-on use, and sometimes I chose a route that was much longer than it needed to be.

At those moments, using AI could feel like doing a large part of the work myself. I still had to identify the real problem, break it into tasks, decide what evidence would count, and keep steering when the output drifted. The model produced much of the implementation, but planning, judgment, test standards, and review did not disappear.

That does not make the implementation assistance trivial. The surprising part was how much work a large reasoning model could complete once the direction and constraints were clear. The speed could be remarkable, even after counting failed attempts and prompt revisions. But the experience made me careful about confusing fast implementation with autonomous engineering.

Making the work visible

The immediate dashboard problem was simple to state: branches, worktrees, backlog entries, ledger claims, and session records were scattered across separate views. I wanted near-real-time visibility, including ASCII activity indicators for ChatGPT/Codex and Claude sessions, without adding a heavy browser runtime to a system already based on local Git, processes, and terminals.

The dashboard eventually presented task → worker → file relationships in a bounded terminal view:

TASK R-3  enforce overlay tick order
 └─ WORKER work/r3-tick-order  committed · waiting to land
     └─ 3 files · 0 conflicts

The first versions were not this manageable. One expanded every file and conflict, made scrolling effectively unbounded, and caused mouse targets to move under the pointer. Reaching a usable structure required observing that behavior and steering the implementation toward progressive disclosure.

There were moments when the experiment clearly crossed from mockup to tool. Once the interactive dashboard began working, I immediately asked for deeper navigation: clickable commit details, task-queue drill-down, mouse-controlled operating modes, and an ASCII speed-gauge metaphor for resource intensity. Periodic state collection was separated from the faster animation refresh, so activity could remain visible without rescanning Git and session candidates for every frame.

The dashboard and distributed workflow did operate well enough to build and manage work. That claim needs the next sentence, however: operation was inconsistent. At other points the dashboard disappeared, failed to reflect a stage change, or required another installation or retry. The feature intended to modify an agent did not work as I expected. Some instructions were misunderstood even after I thought the scope was clear.

When something failed, I could not always determine whether the cause was ChatGPT or model behavior, a cloud constraint, or simply the difficulty of the task. Repeated prompting was not an edge case; it was part of operating the system.

Operating did not mean finished

I cannot describe PetV3 as a standardized, reliable, autonomous control plane. I could not leave it alone and assume that every task would be assigned, completed, reviewed, merged, and recovered correctly. The uneven behavior and the failed agent-modifying feature are important counterexamples.

But saying that it never worked would also be false. I moved from wondering whether I could build an agent system at all to using an imperfect one to distribute work, preserve separate work areas, inspect progress, stop safely, and continue across sessions and providers. It crossed the line from an idea into an operating experiment.

Local Git history puts the span from the first project scaffold and overlay demo on the afternoon of August 29 to a safe-pause checkpoint on the evening of September 1 at about 76 hours—just over three days. During that time, I watched demos begin to work, useful structure accumulate in the project, and development continue through the workflow. The scaffold, pipeline, and visible progress became tangible much faster than the cadence I would normally expect from human-only development. This did not prove autonomy or perfection. It gave me a grounded sense that AI-assisted development changes how quickly a real project can take shape—and, without turning that feeling into hype, that the AI era had genuinely begun to arrive.

For me, the real achievement was learning how to direct, evaluate, and operate AI-assisted work in a real project. I combined an existing software and distributed-systems perspective with new Rust, MCP, and prompt-driven multi-agent practices, while AI accelerated much of the implementation. My role was to set scope and constraints, choose what to try next, maintain review standards, keep failures visible, and decide when to stop or retry. I ended with more respect for the human judgment agent systems still require—and more surprise at how much large reasoning models can already build when that judgment is present.

Method note: This is a first-person reconstruction, not a complete transcript. I cross-checked it against available Codex work records and the local Claude Code histories associated with the PetV3 repository, using those histories as records of prompts, retries, reported results, and handoffs rather than as independent proof that every reported feature worked exactly as described.

Next: PetV3 Agent Factory 4: Budgets and Checkpoints for Autonomous Work