Work and orchestration

How factories represent work, coordinate agents, place deterministic gates, and improve their own harnesses.

Work and orchestration

A later Tessl conversation pins down when a workflow becomes a factory: the moment you stop using an agent directly and start writing code that makes agents do work, and, more precisely, the moment you treat work itself as a first-class entity, a substance you manipulate. Work moves through three views, public future work anyone can claim, exploded-open in-progress work you keep private, and a curated finished-work ledger, which the Beads tracker formalizes as a git-and-database work graph rather than a heavyweight issue tracker. The factory’s job is to push work through on a rhythm: spend tokens to generate work (a swarm files reports and bugs), then swarm to fix it, then swarm to review it, and repeat.

At that velocity work becomes almost uncountable, so a factory can accidentally do the same task twice with divergent outcomes (forcing a judge call) or lose a token-funded run entirely, and every factory grows an ongoing hygiene job, dedicated maintainer agents (“the dogs” in Gastown) that spend tokens keeping skills, rules, and maps from bit-rotting, since skills are the new documentation and decay each time the system is used. The shape of the factory is itself discovered stochastically: you add agents until a dozen are humming, realize the topology is wrong, drain them, reshape the scripts and directories, and reboot, so fast setup and teardown is what lets you find the right shape; the conversation’s recurring answer is a small crew of deep-context design agents on one side and throwaway, well-specified, parallelizable fleet work on the other (Inside a Software Factory (opens in a new tab), 2026).

Tessl’s own factory makes the mechanics concrete. Two founding goals, no human-written code and no interactive coding-agent sessions, are enough on their own to force the factory shape. Everything starts as an issue in Linear; a background orchestrator polls for tickets delegated to the factory agent, which picks up the work and, rather than having deterministic glue open the PR (that “frequently broke”), is simply handed the GitHub CLI and opens its own PR. The team’s standing discipline is to fix the harness before correcting the agent: before leaving any PR comment, a reviewer must at least once rewind and change a skill, add a unit test, or alter the architecture and let the agent retry, and only if it fails to one-shot the second time may they comment.

On top of that core issue-to-PR unit run scheduled sweeps outside any diff, an architecture agent flagging duplication and hard-to-test seams, a test-quality agent running coverage and mutation testing (which catches the boundary cases coverage misses, like a list tested at 5 and 50 but never at 0), and documentation agents. Verification leans on pedantic, cheap linting: a fifty-line rule that asserts one module never imports another is worth writing because agents frequently invert the architecture, and Tessl packages the LLM-powered version as “verifiers”, focused semantic checks like “every JSX element carries Aria attributes”.

The counterintuitive finding is on determinism: Tessl started with deterministic orchestration ferrying comments between phases and ripped almost all of it out, because every piece of deterministic code that tries to orchestrate becomes a source of brittleness once roughly 15 percent of features break the assumed pattern (stacked PRs the orchestrator had made impossible); they kept determinism only at the ends, as hooks and CI gates that block a commit or a session-stop until tests pass and required skills loaded, and moved what orchestration remained into the task tracker itself (a parent task with blockers is the execution DAG). This refines rather than contradicts the rule that stage handoffs are deterministic scripts: determinism belongs at the gates and the glue, not in the middle of a single agent’s run (same source).

The practitioner framing makes the complete information path the design unit, not the loop alone. Production implementations separate agent instructions from deterministic code so each node and handoff stays inspectable and replaceable (FORGET Loop Engineering. Agentic Engineering is about THIS (opens in a new tab), July 2026, practitioner and course vendor).

Automation starts after a manual end-to-end run exposes the real handoffs. Diagram the path, automate one agent plus one deterministic check, then add specialization when observed failures justify it. This keeps the first implementation small enough to test while leaving room for worktrees or stronger sandboxing as concurrency grows (FORGET Loop Engineering. Agentic Engineering is about THIS (opens in a new tab), July 2026, practitioner and course vendor).

A factory is also a closed feedback loop: intent and production signals feed a work queue, a harness builds the change, automated checks and review gate it, and deployment telemetry, incidents, and requests feed the next cycle. Queue intake and production monitoring are therefore part of factory orchestration, not merely infrastructure around it (Software Factories, Light and Dark (opens in a new tab), published July 22, 2026).

A conference talk by Warp’s founder walks the same loop stage by stage. Intake is a set of named channels: the task tracker, chat, the terminal or IDE, and monitoring. Triage is the stage to start a factory with. An agent implements an easy, clear issue directly and hands a complex one to a spec agent, which writes a product spec stating the product invariants and a second spec for the architecture and shape of the code. Review starts with an agent, and deciding where a human still reviews becomes risk management over time. For user-facing work a verification stage has an agent use the built product through computer use and record videos and screenshots. CI/CD follows, and a monitoring stage feeds what it sees in production back to intake (AI Engineer - Software Engineering Is Becoming Factory Engineering (opens in a new tab), September 2026, vendor talk).

The same talk lists what a factory needs at scale: intake channels, a control plane that distributes the work, cloud sandboxes where it runs, a choice of agent and model per task, and a data plane underneath that lets agents remember and improve. Its advice is to build a simple version yourself and, for the scaled one, to buy and keep engineering time on the product. Improvement runs through loops. In a skill loop, observer agents watch how the factory’s skills are applied, and when a senior engineer corrects a review agent’s comments, an observer improves the review agent for its next run (AI Engineer - Software Engineering Is Becoming Factory Engineering (opens in a new tab), September 2026, vendor talk).

In a later conversation the same founder makes the factory itself an artifact. It is defined in code, the way Terraform defines infrastructure. A file and folder structure states the shape of the work, its agents, their skills and MCP servers, where they run and which models they use. An orchestration runtime executes that definition. Because the definition is code, a team can branch it to test a variant. Improvement agents that find patterns in failed runs propose their fix as a diff against the definition, down to one of its Markdown files. Any recorded task can also be promoted to a benchmark. A team builds its own Terminal-Bench or SWE-bench from real work and draws its own curve of model performance. The stated hazard is leakage. A replayed task can reach the finished pull request or later commits, and tasks with side effects open pull requests. Each rerun therefore needs a clean environment (Boundary - How to Build an AI Software Factory That Ships Faster (opens in a new tab), October 2026, practitioner and vendor).

A practitioner conversation shows the intake stage built for user reports. The team treats every report as untrusted. An agent first checks whether the latest version already fixes it and tells the user if so. It then searches for a duplicate and tries to write a clear reproduction, and only a reproduction becomes an issue. Deduplication is expected to stay imperfect and still pays if it catches half. Every reproduction then runs on every pull request, which is cheap because most need only CPU time, so the team always knows whether each issue is fixed. A report that cannot be reproduced, or that depends on external data, goes to a named human through chat with the reproduction or a plan attached. An agent also classifies each issue’s difficulty and is evaluated against a database of past issues. The team hoped for at least 60 percent accuracy and corrects by diff size: a fix classified as small that grows to hundreds of lines is reclassified. The trust boundary also shapes the infrastructure. Only agent-written reproductions execute and raw feedback never does, so the team runs these agents on its own machines without a sandbox (Boundary - How to Build a Software Factory for AI Coding Agents (opens in a new tab), August 2026, practitioner and vendor).

The dark-factory account pushes the pattern to its autonomous end state and, usefully, catalogs the failure modes. A human manually directing every agent (the “circus ringmaster”) is a manual process with an agentic facade; an operator who fixes recurring errors by hand instead of codifying the fix (the “mechanic”) never advances; production volume without mature validation infrastructure is a “bullshit factory”, because agents optimize to pass whatever gates exist and weak gates are easy to pass. The constructive counterpart is the automation ratchet: every human error correction is immediately codified as a fitness function, test scenario, or agent rule, so the fix is simultaneously a system upgrade (Dark Factory Patterns).

Resources

Work and orchestration

• FORGET Loop Engineering. Agentic Engineering is about THIS (opens in a new tab) - Practitioner guidance mapping complete execution paths, separating agent judgment from code, and advocating incremental automation.
• Software Engineering Is Becoming Factory Engineering (opens in a new tab) - Conference talk by a terminal-agent vendor’s founder walking a software factory stage by stage, from triage through monitoring to skill-improvement loops.