February 8, 2026 • Systems Engineering

The Foreman’s Desk: Schedule Discipline in the Age of AI

In our previous discussions, we characterized AI as a high-capacity excavator—a powerful engine capable of moving mountains of earth. But as the industry races toward multi-agent systems, we are seeing a new challenge emerge: uncontrolled orchestration. It's not enough to have a fleet of excavators; you need a site plan, or you'll just end up with a lot of holes in the wrong places.

At Pairti, our answer to this is BP6—a tool that brings the mindset of the "Foreman's Desk" to the speed of AI. This isn't about directing entities with no idea; it's about coaching a team of highly capable rugby players. These players know how to score tries; we just need to tell them where the try line is and ensure they have a solid game plan.

Standing on the Shoulders of Giants

Our philosophy doesn't exist in a vacuum. It is a synthesis of traditional engineering discipline and the bleeding edge of AI orchestration. We are seeing convergent evolution across the industry:

• The Ralph Loop: Geoffrey Huntly’s Ralph Loop demonstrated the power of iterative, context-controlled loops. By restarting with fresh context and clear errors, AI can solve problems that baffle long-context "memory" chains.
• Gas Town: Steve Yegge’s Gas Town thesis highlights the emerging need for orchestration. He describes the risk of "vibes-based" coding and the absolute necessity of a "Mayor" (or Foreman) to coordinate the work of specialized agents.

We aim to take these concepts of orchestration and iterative loops and ground them in the structure of Systems Engineering.

The Systems Engineering Process (SEP)

Traditional Systems Engineering Handbooks describe the SEP as a "comprehensive, iterative and recursive problem solving process, applied sequentially top-down by integrated teams." Its goal is to transform needs into product descriptions and generate information for decision-makers.

However, the "teams" in the age of AI are different: they are not integrated in the traditional sense but are dynamically adapting AI agents, each with potentially differing roles at different points in the development lifecycle. This presents a similar challenge of control and coordination, but with a completely new algebra.

Historically, this "top-down" approach was a risk management strategy. You planned heavily because building the wrong thing was prohibitively expensive. In the age of AI, the economics have flipped, but the value of the process has arguably increased.

Top-down is now an accelerant.

We don't plan to avoid building; we plan to build faster. Because we can build, rebuild, throw away, and restart with negligible cost, we can use the SEP loop to define a slice of functionality, generate it with AI, test it, and refactor it immediately. If the definition was wrong, we change the definition and regenerate. The "Foreman's Desk" (BP6) allows us to define these slices and glue them together, managing the complexity that defeats flat "to-do" lists.

Rediscovering Discipline: The BP6 Philosophy

To implement this, we looked backward to the gold standard of heavy industry: Primavera P6. BP6 (BERT P6) is our oversight layer for the Beads issue-tracking system.

However, there is a critical distinction to be made. In traditional heavy industry, P6 is largely about managing time. In the age of AI, time is malleable. You can summon a horde of AI excavators to do your bidding in almost no time at all. But while you can compress time, you cannot cheat logic. Dependencies and logic still rule. No matter how many agents you deploy, you cannot paint a wall that hasn't been built. And it's still risky to do some things before others, life us just like that sometimes.

BP6 provides the "tracks" for this logic-driven orchestration:

• WBS as Context: The WBS hierarchy is more than just a list; it is the human equivalent of an AI's context window. We are natural decomposers and abstractors. By isolating work within a WBS, we create rock-solid context that allows us to focus. Crucially, we can then pass that same isolated context to the agent, ensuring it works on a bounded problem rather than getting lost in the noise of the entire codebase.
• Logic-Driven Gantt: Dependencies ("Blocks" / "Blocked By") are the primary drivers. The schedule enforces the order of operations, ensuring that the "hoarde" works in concert rather than in chaos.
• Critical Path Management: We use longest-path algorithms to identify which tasks actually matter. This prevents the "Spaghetti Speed-Run" where AI generates mountains of low-value code while the core bottlenecks remain.

Git-Native Planning

Crucially, this planning doesn't happen in a separate SaaS tool. BP6 treats the schedule as code. Our task data lives in `.beads/issues.jsonl` within the repository. This `.beads` structure is inspired by the memory and context management concepts (often referred to as 'beads') popularized by Steve Yegge in his "Gas Town" work. It is branch-aware and version-controlled. When you switch a git branch to explore a new architectural idea, your schedule switches with you.

By bringing together structured work planning, the iterative power of the Ralph Loop, and the orchestration vision of Gas Town, we are building a workflow where AI is not just a coding assistant, but a reliable partner in systems delivery.

The excavator is running. The foreman has the map. And for the first time, we can see exactly where we’re going.