Engineering / After hours

Agent infrastructure and the repository factory

Policy-driven agents with tools, memory, and verification gates; a typed knowledge substrate they can navigate; and a prompt-driven factory that turns an architecture into a finished repository through dependency-ordered build contracts. This site was built by it.

agentsMCPknowledge graphsverificationClaudedeveloper tooling

The thesis

Chat is an interface. It is not an operating model. The interesting question is what it takes for an AI system to be a structured worker: bounded by policy, equipped with tools, able to remember, and obliged to prove its work.

Three pieces, built to fit together.

The agent runtime: workers, not chats

An agent runtime where every agent has a role, a tool surface exposed over the Model Context Protocol, an explicit policy describing what it may and may not do, and a memory it reads and writes through typed objects rather than free text. Approval boundaries are first-class: an agent that reaches a consequential action stops and asks, and the ask is logged. Observability is not an afterthought; every turn, tool call, and decision is a record with a cause.

The design principle borrowed from reliability engineering: an agent is a service. It has an SLO, a runbook, a failure mode analysis, and a way to be turned off.

The knowledge substrate: knowledge as a living system

A personal and organizational knowledge substrate built on plain files, hierarchical knowledge objects, and graph relationships. The point is not note-taking. The point is that a machine and a human can navigate the same structure: a decision links to the evidence that produced it, an architecture links to the runbooks that operate it, an essay links to the sources it drew on. Agents read from it and, under policy, write back to it.

The repository factory: engineering discipline applied to creation itself

Given a product vision or a half-finished repository, the factory establishes repository truth, infers the smallest architecture that can fully manifest the product, and writes a dependency-ordered graph of build contracts. Each node names its targets, its upstream contracts, its verification gate, and the evidence it must leave behind. A session executes nodes in order, replaces contracts with real implementation, runs the gate, and records the receipt. A fresh session resumes from the manifest.

The rule that makes it work is the same rule that makes infrastructure work: verification is part of construction, not a ceremony at the end. A gate that fails blocks its dependents. "Done" means the production completion gate passed, or the only things left are genuinely outside the engineer's control.

Why this matters for the business side

The three workers in the catalogue are configurations of one shared codebase. That claim is only credible if the codebase, the agents, and the factory that produces them are real. They are. This site, including the intake agent on /start, was produced by the factory from a written blueprint, and its own factory manifest lives in the repository.