Orchestrating the Software Lifecycle

The working loop: shared task state, specialized workers, verification, review, and human oversight.

A feature request can fit in a sentence: “Try a grid instead of a list.” What follows is a chain of product and engineering work. The request needs to become a specification, a candidate implementation, and eventually an approved release. Someone has to keep the work moving between those stages and know when it needs another decision.

I have been building a system to take on that coordination using frontier AI tools such as Codex. It connects Infinite Queue, the ticketing platform I built, with specialized AI workers, automated checks, and human approval points. I want to be able to describe a change, let the authorized work progress through the loop, and return to the decisions and evidence that need my input.

In this system, an AI agent is a model session with a defined job, relevant context, and limited tool access. The overall loop also uses existing software for scheduling and verification.

The orchestrator runs a recurring loop around that work. It checks what is ready, which dependencies are satisfied, who owns each task, and whether there is capacity and permission to proceed. It advances existing work and selects new assignments as conditions allow. I can give it a defined scope and let the loop carry work forward, with decisions and blockers coming back to me.

I built this after expanding an earlier AI-managed project that ultimately failed because I had not established enough coordination discipline. Useful features shipped, but unfinished branches accumulated and I spent hours reconstructing what was ready. The new system makes task ownership and the evidence needed for each handoff explicit.

Infinite Queue holds the requirements, dependencies, ownership, and delivery state. It also accepts user feature requests. The intended intake flow is for an authorized AI PM to triage those requests into project work. GitHub holds the source code, pull requests, and repository checks. The execution host runs the AI workers, and the deployment provider establishes what is actually live. The orchestrator coordinates these systems so a worker's completion report can be checked against the resulting artifact.

Consider a request to change search results from a list to a grid. It needs enough definition to distinguish an acceptable implementation from something that merely looks plausible.

Tom PM, the product-management role, refines that request into an outcome, scope, dependencies, and observable acceptance criteria. It clarifies the intended interaction and the accessibility and measurement requirements. If it cannot resolve a product question within its assigned scope, it asks for clarification. The resulting ticket gives the next AI worker a defined assignment.

For complex or uncertain engineering work, the workflow now includes an architect role between the PM and developer. The PM defines the outcome; the architect prepares the approach, assumptions to test, affected interfaces, validation, and conditions for stopping. For a search-grid change, that could mean deciding how to reuse existing components and preserve navigation and accessibility. Small, well-understood changes can still go directly to a developer. This planning step is now part of the reusable skills; automating the architecture handoff remains future work.

Tom Dev receives the authorized task and works in a separate working copy of the repository. It gets the requirements, any architecture plan, boundaries, and expected checks, then returns a candidate and a checkpoint.

Tom Verify runs the project's configured checks against the candidate. This is deterministic software executing commands, rather than another model deciding whether tests probably passed. Tom Review then examines the code in a fresh, read-only model session, using the request and acceptance criteria. Code review looks for defects and failures to satisfy the request. Its findings include specific locations and supporting evidence.

A failed check or material review finding returns work to the developer through a bounded correction loop. The corrected candidate goes through checks and review again. Results belong to the particular code version that produced them, so a later change cannot automatically inherit an earlier approval. Repeated failure or an exhausted correction budget becomes a blocker requiring attention. The new planning approach also calls for repeated failed fixes to return to the architect before more implementation.

Tom Release covers the permitted delivery steps. The coordinator can publish a pull request and advance it through the repository's checks and merge rules. Opt-in production adapters support deployment and independent verification of the resulting version. The production path remains to be validated in this loop. In the website project used to exercise the loop, two workers operated concurrently and accepted changes merged into a dedicated project branch. I retained personal approval before that branch could enter main or production.

These handoffs are what let the agents work back-to-back. The next role receives the task, the candidate, and the evidence it needs from the preceding stage. The orchestrator records progress and determines the next permitted action. A task waiting on a decision can remain held while other eligible work advances. Project selection and worker concurrency are configurable, although broader parallel delivery across projects remains to be validated. The coordinator currently runs on one host, with manual intervention still needed for some recovery cases.

From feature request to release

A conceptual delivery sequence with example human approval points. Architect planning fits between specification and build. The deployment stage shows the intended full lifecycle; production delivery remains to be validated.

The established roles have versioned instructions, defined inputs, and an expected output. We can refine the prompts to make specifications, findings, and status reports consistent in tone and terminology while preserving their different purposes. Model and reasoning settings can also vary by assignment. Scheduling, ownership checks, and test execution use ordinary software where a model adds no useful judgment.

Human review can sit at the decisions we want to retain: the PM's specification, an architecture proposal, code-review findings, or a production release. The implementation and release authorizations in my current system provide concrete boundaries. Architecture and any new specialist-review stages need equally explicit approval records and enforcement. Permission to build a feature does not give the developer permission to publish it.

Security adds another responsibility. A security review examines access, data exposure, authorization, and new attack surfaces. The current implementation restricts worker network access, separates developer access from release authority, and uses read-only review sessions. Target projects retain checks such as secret scanning and dependency audits. A dedicated security specialist could add focused scrutiny, with accountable human ownership of the controls.

I also built a dashboard to follow along and understand how the loop is progressing. It shows assignments, models, handoffs, reported token usage, and work needing attention. A Blockers and Attention page clearly identifies blocked tickets, unresolved execution issues, and closed history, and shows how current its evidence is. It can queue a contextual request for delivery to the loop, where the coordinator handles it under the existing permissions.

The escalation process calls for engineering blockers to go through a principal engineering review and product questions through a principal PM review before reaching me. The dashboard leads with the problem, recommendation, AI owner, and any decision needed from me. The agents prepare the analysis so I can assess a recommendation without reconstructing the investigation.

The execution record feeds a learning loop too: failures and human feedback can become reviewed changes to the orchestrator, IQ, prompts, and regression checks. Feedback from running the loop becomes work to improve the loop itself.

The same loop could support changes across product surfaces: explaining why an item is recommended, trying a different app layout, or switching from 2:3 posters to 16:9 images. A recommendation explanation needs technical partners to validate its accuracy. An artwork change needs decisions about assets, cropping, text, and responsive behavior. Each request could follow the shared delivery process with its own acceptance criteria. A search-grid variant would still need an experiment to establish its effect on discovery.

Cost remains an open question. Choosing cheaper models for appropriate work helps address one part of it. I still want to understand cost per accepted outcome, including retries and human intervention; savings from proposed budget and routing controls remain unproven.

The opportunity I see is to let product teams contribute a request and inspect a developed specification, a reviewed implementation, and the evidence behind it, without manually relaying every handoff. For something like a search-grid change, that would let us spend more of our attention deciding whether the experience deserves to ship and what we need to learn from it.

---

This writing reflects my personal perspectives on product management, AI, and content discovery. It does not represent the official position of my employer or any affiliated organization.