Scale Signal

The project becomes a goal-regulated agentic engineering loop

September 20, 2026 · Will Larson
Apparition → SelectionContextCoordinationExecutionLearningObservability
Evidence boundary: This is a first-pass local experiment at Imprint. The source mentions about ten multi-repository workspaces and an existing orchestrated Agent Fleet, but does not report how many projects or tasks ran through the factory loop, how long it operated, or any comparative quality, productivity, cost, or human- attention outcomes.
Evidence record

Source → Observed → Interpretation → Model implication

SOURCE

Trying the Software factory pattern

View source →
OBSERVED

Larson defines the software-factory pattern as repeatedly pursuing a broad goal while relying on an agent harness to drive progress toward it.

Imprint's first implementation is a linear-project-loop skill that begins by auditing whether a Linear project has an RFC in Notion describing its goals, measures, and approach, together with a Datadog dashboard or Snowflake queries that measure progress.

When the project, goal definition, or measurement tools are missing, the skill iterates with the operator to create them.

The loop reviews project metrics and issues, adds newly identified work, updates issue state, and works on non-blocked tasks through actions such as writing or updating pull requests, requesting review, and asking clarifying questions.

After a task completes, the loop selects another task when the project description is fresh; when it is stale, the agent restarts from the goal and measurement audit.

Larson reports running the prototype locally and says it works well enough that he anticipates moving it to the same orchestrated harness used for one-off tasks.

Larson describes a possible lower-frequency post-release mode that would revisit shipped projects and detect changes in adoption or error rates, but presents this as an intended use rather than a demonstrated result.

Imprint's preceding adoption sequence included about ten local multi-repository workspaces, a company-wide migration from Jira to Linear, and deployment of an orchestrated harness called Agent Fleet.

Larson says the factory loop depends on Datadog MCP and Snowflake access for goal tracking, Linear as the shared work-state system, and a harness capable of operating independently from a developer laptop.

INTERPRETATION

Imprint's experiment moves selection from choosing the next isolated coding task toward regulating a project against an explicit goal and observable measures. Current metrics, task state, blockers, and the freshness of the project description influence whether the agent creates work, executes work, or returns to reassess direction. The prerequisites are environmental: goals and measures must be machine-readable, work state must be shared, tools must expose operational evidence, and execution must persist beyond a laptop. This supports Selection as a property of the surrounding engineering system. It is adjacent to Cooperation and Specialization, but the source does not establish multiple differentiated agents or a durable higher-order production unit.

MODEL IMPLICATION

SUPPORTS. Supports Selection by documenting a goal-regulated environment in which observable project state determines the agent's next action and periodically triggers renewed assessment rather than continued task execution. The source also identifies the Context, Execution, Coordination, Observability, and Learning capabilities required for that loop to operate. Because the report is an early qualitative prototype without comparative outcomes, it does not establish a cooperation advantage or stable specialization.

Epistemic boundaries

What this does not establish

OPEN QUESTION

Does a goal-regulated project loop improve engineering outcomes and reduce human steering compared with task-level agents once goal ambiguity, metric quality, stale state, review work, and post-release operation are included?