Using an Agent to Release wtproj

Idea

One of this weekend's projects was less par-baked and more “could we finally take this out of the oven?”. The goal was to clean up the wtproj repository, publish our task management tool on GitHub and add a few features shaped by our recent work with GPT 5.6.

wtproj helps organise work that will be handed to coding agents. That makes releasing it a useful test of the tool itself: could an agent help prepare, check and ship the project without turning release day into a long conversation with a YAML file?

The main feature we wanted to add was a suggested model for each task. We had already seen GPT 5.6 assess a to-do list, judge the difficulty of each item and recommend which model should handle it. Storing that decision with the task meant it could be made during planning, rather than rediscovered whenever the work was assigned.

Useful for: developers and small teams experimenting with AI-assisted task planning, delegation and open-source releases.

Status

It is out. wtproj 0.1.0 is available on GitHub for anyone who wants to try it.

The release adds version and update commands, along with a --model option for recording a suggested model against a task. That final addition came directly from using Codex with GPT 5.6. Some tasks need careful reasoning; others are routine enough for a faster or cheaper model. Treating every item as equal wastes time and budget in different but equally inventive ways.

With the model suggestion stored as task data, the workflow becomes easier to repeat:

1. Review the task list during planning.
2. Estimate the difficulty and type of work involved.
3. Record a suitable model for each task.
4. Send independent tasks to separate agent threads.
5. Keep the coordinating agent focused on progress, results and exceptions.

Model selection becomes an explicit planning decision, while execution can be handled consistently later. Codex does not need to reassess the whole queue each time it starts a task, and a human can inspect the choices before any work begins.

Problems Faced

The awkward part was CI, especially the jobs responsible for producing Windows builds. Errors appeared across repeated runs, and each fix exposed another small assumption in the release process. Nothing was individually dramatic, but together they consumed a sizeable part of our weekly agent budget. CI has a special talent for turning “nearly done” into a subscription service.

The expensive pattern was the feedback loop: wait for a job, inspect the failure, adjust the configuration, push again and repeat. An agent can make each step easier, but it cannot make a remote build finish sooner. Poorly bounded instructions also encourage it to keep investigating long after the likely cause is understood.

Checking the repository for unwanted secrets caused a similar issue. The request was sensible, but broad. Asking an agent to prove that nothing sensitive exists can lead to a large search with no natural stopping point. A better check needs a defined scope: which file types, generated outputs and secret patterns matter, which automated scanner should run, and what counts as enough evidence to approve the release.

The lesson from both problems was that agent time is still project time. A task may feel automated while quietly consuming budget, waiting on external systems or expanding its own definition of “done”.

Techniques That Helped

Monitoring helped most. We had not asked an agent to manage this release process before, so we kept the work visible and reviewed it at clear checkpoints rather than leaving it to run unattended in “yolo” mode.

The useful pattern was simple:

• Give each task a narrow outcome, such as fixing one Windows build failure or checking one release artefact.
• Ask for evidence at the end: the command run, the relevant log output and the result.
• Put limits around repeated CI attempts so a new failure triggers review instead of another automatic lap.
• Use deterministic checks for secrets and release files before asking a model to interpret anything unclear.
• Keep planning, execution and monitoring as separate jobs, with a model suited to each one.

This made it easier to see when the agent was progressing and when it was merely busy. It also gave us better hand-off points. If a task stalled, we could restart from a known result instead of asking a fresh thread to reconstruct the entire release story.

Monitoring did add human attention, so it was not free automation. It was still cheaper than discovering late that an agent had spent its allowance heroically fixing the wrong problem.

Lessons Learned

The final few percent of a release is rarely a few percent of the effort. Packaging, CI, security checks, release notes and versioning all sit near the finish line, and each can reveal assumptions that ordinary development never tests.

We also learned that the model best suited to evaluating work may not be the best one to coordinate it. GPT 5.6 Sol was strong at assessing task difficulty and suggesting an appropriate model. Once wtproj stored those suggestions, GPT 5.6 Luna became a better fit for dispatching the prepared tasks to background agents and tracking what came back.

That gave us a clearer division of labour:

• Use a strong reasoning model to assess, split and assign work.
• Store those decisions with the tasks so they remain visible.
• Use a lighter coordinating model to submit independent tasks and watch their state.
• Bring a human back in for repeated failures, security decisions and release approval.

The larger lesson is that delegation works better when judgment happens once and is recorded. Otherwise, every new agent spends time solving the planning problem again. wtproj now carries more of that context, which should make future multi-agent runs cheaper, clearer and easier to audit.

If you are working out how AI agents might fit your own development process, get in touch with holeaf and we can help you plan a setup that stays useful after the first impressive demo.