Curating Design and Decision Intention in a Modern Agentic Software Factory

Anyone who has spent an evening in conversation with an AI assistant has had the experience of describing a change to a piece of software and receiving, a few seconds later, something that works. The first occasion is startling. By the tenth it has become unremarkable, and it is the unremarkableness, rather than the startlement, that deserves our attention.

Consider the same arrangement at a larger scale. In place of a single conversation there are several hundred of them, distributed across a dozen separate bodies of code and carried on over a period of months. Some of that work was done by a person, some by an assistant under supervision, and some by an assistant working through the night while its supervisor slept. The software runs, and customers have come to depend upon it.

Let us consider a hypothetical case. One morning you open a file and find a line establishing that a security token expires fifteen minutes after it is issued. You have no difficulty understanding what the line does; what you cannot determine, by any amount of reading, is why the interval is fifteen minutes rather than five or fifty.

The Work That Surrounds the Writing

Writing code is the visible portion of building software in much the same way that pouring concrete is the visible portion of building a bridge. The greater part of the undertaking lies elsewhere: in determining what ought to be built, in reviewing what has been built, in testing it, in delivering it, and in living with the consequences for years afterward. The industry has long referred to this entire cycle as the development lifecycle, and it was thoroughly described in the professional literature decades before anything resembling a neural network was applied to it.

What has changed in the last several years is that machines have become capable of taking genuine shifts within that cycle. One agent reads an incoming defect report and determines which portion of the system it concerns. A second composes a correction. A third reviews the correction and objects to whatever it finds objectionable. A person then reads the finished proposal and decides whether it is to be delivered.

Today the commercial service I have described is called an agentic software factory. Several large firms operate one in production, and the freely available implementations have become entirely serviceable. Every serious version of it, whether sold or given away, has arrived at the same division of labor, in which machines prepare the work and human beings approve it. The labor has not been eliminated so much as relocated, and the relocation is on the whole a considerable gain.

What I have set down so far is common knowledge among those who follow the field, and I have rehearsed it only in order to arrive at the matter I should like to call to your attention, which is the curation of Design and Decision Intention, exemplified here by the choice of fifteen minutes for some timeout.

A Question the Source Cannot Answer

Suppose you put the question to an AI assistant, as one now naturally would. If you ask what a piece of code does, it will tell you correctly, and it will do so faster than you could have read the code yourself. The assistant has the whole text before it, and the answer is contained in the text.

If you ask why the code is as it is, the character of the transaction changes entirely, though nothing in the assistant's manner will indicate as much. You will receive an answer that is fluent, confident, technically literate, and formed in every respect like a genuine explanation. It may also be an invention.

The reason for this deserves to be stated plainly, because everything that follows depends upon it. Design and Decision Intention is recorded nowhere in the software. The fifteen-minute interval was a judgment, arrived at on a particular afternoon by a particular person, who weighed the time a legitimate user might reasonably require against the time an attacker would be given to work with, and who settled upon a figure that struck an acceptable balance between the two. That deliberation occupied perhaps an hour and existed only in one mind. If no one troubled to write it down, it is now irrecoverable, and no quantity of subsequent analysis will restore it.

The assistant, invited to explain, will supply a plausible reason rather than confess the absence of one. Should that invented reason then be filed away as documentation, it will be indistinguishable a year later from an authentic account of the decision. The institution will have poisoned its own memory with a statement that carries every outward mark of truth.

Here, I think, lies the real difficulty in delegating an increasing share of the work to machines. The machines are competent and grow more so. What has grown scarce is Design and Decision Intention, which is to say the record of why anything is as it is.

Two Kinds of Knowledge

I turn now from the difficulty to the remedy we have adopted in our own factory. We have built a memory for it, and the shape of that memory follows from a distinction between two sorts of knowledge that behave in opposite ways.

The first sort is easily obtained. If one asks which portion of the system is responsible for a given concern, the answer may be recovered from the code itself, automatically, whenever anything changes. Knowledge of this kind remains current without effort, and when it is mistaken the mistake announces itself at once, since the software will fail to behave as the map has promised. It is cheap to produce and self-correcting in operation.

The second sort is Design and Decision Intention, and it is far harder to come by. It can only be captured, and it can only be captured at the moment it stands exposed, which is to say when a person is reviewing a change and already holds the reasoning in mind. Requested at that moment, it costs almost nothing to obtain. Requested an hour afterward, it is generally beyond recall. Knowledge of this kind accumulates rather than regenerates; it is set down once and never afterward discarded.

The asymmetry between these two constitutes the whole of the design. The first is a map that we redraw continually and without ceremony. The second is a ledger to which we may only add.

Each entry in that ledger carries with it a statement of its own origin, and there are only two origins it may declare. An entry composed by the human operator stands as doctrine. An entry proposed by an agent stands as opinion, which is to say that it remains visible and useful without ever becoming authoritative. An agent may propose intention into the memory; a human being determines what is admitted as doctrine. The structure of the record enforces this distinction, rather than the good intentions of anyone involved, and the reliance on structure is deliberate, since good intentions have compiled an indifferent record when set against a system whose entire occupation is the production of confident prose.

An Agent With a Budget

The memory I have described resides in a graph database, and the agents that consult it are charged for every question they ask. Each agent maintains a balance of bitcoin funded in advance, and each query draws that balance down. It carries a second purse besides, for the reasoning that consumes what the graph returns, and either may run dry. When one of them does, the agent ceases to write and waits upon a person to replenish it.

This will strike many readers as a gratuitous complication, and I should like to defend it, because it is the most considered element of the arrangement.

An agent granted unlimited access to a resource has no means of choosing among the uses to which it might be put. Every alternative costs the same, which is to say nothing at all, and where there is no difference in cost there is nothing to be weighed. Grant that same agent a budget and its conduct alters immediately. It puts the broad question first, and it pays for the deeper descent into recorded intention only when the broad answer has failed to satisfy.

Readers acquainted with Menger and Mises will recognize the principle without further assistance. Prices are the instrument by which a mind economizes, and calculation becomes possible only where prices obtain; deprived of them, even a highly capable actor is reduced to guessing. We did not instruct our agents in frugality. We gave them budgets, and they worked out the remainder for themselves.

Funding in advance also disposes of a difficulty that afflicts most metered services, namely the constant interruption for authorization. A single decision is taken at the outset, after which some thousands of calls proceed without further consultation. No one is asked to approve anything in the middle of a thought. We call this principle Don't Pester Your Customer™, and it is the foundation upon which Tollbooth DPYC™, the metering layer beneath all of this, has been built.

The Actors and their Stage

If you are a fellow agentic software factory architect, you may have a few questions. Where do these agents live, and what keeps their knowledge once they have finished?

The first answer is simpler than you might expect. A GitHub repository already announces its own changes: notifications are raised when an issue is filed, a branch is pushed, or a proposal is opened for review. GitHub Actions has had notification handlers for years and can start a program in response to any of them. These agents, therefore, require no standing platform to watch over them and no service running perpetually in anticipation of work; they are realized as GitHub Actions runners. The event is the summons. The agent comes into being when there is something to do and ceases to exist a few minutes later, having done it.

Our factory employs three such actors, and we introduce them properly, since everything that follows is a description of their conduct.

The Porter stands at the door. When a defect report arrives, the Porter determines what the report is really about, which portion of the estate owns the concern, and whether the matter is worth anyone's further attention. The Porter writes no software whatever.

The Journeyman does the work. Given a matter the Porter has admitted, the Journeyman composes a correction, submits it for review, and records what it learned in the course of doing so.

The Inspector objects. It reads the Journeyman's proposal in an adversarial temper, hunting for whatever it finds objectionable, and it does so before any person has been troubled to look. Like the Porter, it writes no software.

Each is a patron in the sense the metering layer intends: each holds its own cryptographic identity and its own funded balance, and each is charged for what it consumes. None has any memory of its own. All are gone within the quarter hour.

Behind the three stands the Reviewer, who is a person and who holds the operator's key. The three prepare, and the Reviewer disposes.

The permanence resides elsewhere, in a graph database held by an operator we call the Cypher-MCP, which is the sole custodian of the curated intention. The actors reach it by calling a small set of published questions and statements, each one written in advance and admitting only parameters. No agent ever composes a query of its own, which closes an obvious avenue of mischief, since an agent that reads text submitted by strangers on the public internet should not also be trusted to compose the instructions that text might influence. Which identities may write, and what each may write, is settled by the operator rather than by the agent asking.

The arrangement, then, is a persistent memory attended by fleeting servants.

A Day in the Agentic Software Factory

Let us return to the example reported issue regarding timeout and watch the machinery work.

A report is filed against the estate one morning by an integrator: sessions expire far too quickly, users are being turned out in the middle of their work, and would we kindly raise the interval to an hour. The complaint is sincere, well described, and entirely reasonable on its face.

GitHub Actions observes the new issue and summons the Porter, which comes into existence holding an identity and a balance of a few thousand satoshis.

The Porter asks the broad question first: which portion of the estate owns session expiry. The graph answers immediately, naming the capability and the service that realizes it. Only then does the Porter pay for the deeper descent, which is what we already understand about why that capability behaves as it does.

Here the morning turns. The graph returns a recorded intention, composed by a person and marked as doctrine: the fifteen-minute interval was chosen deliberately, as the longest window a legitimate correspondent should require and the shortest that an attacker in possession of a stolen token would find useful. The entry is bound to an invariant governing the credential path, and the invariant is grounded in the filed specification.

The Porter has now understood the matter without having opened a single file. It records its triage, marks the issue as touching a protected decision, and hands the work forward with the recorded intention attached.

The Journeyman is summoned by that label and reads what the Porter has left. It is thereby in a position that no assistant working from the source alone could occupy: it knows that the change requested would repeal a considered security judgment, and it knows who made that judgment and on what grounds.

So it declines to make the change as asked, and proposes something else. The interval remains at fifteen minutes and the session renews itself quietly while the correspondent is still working, so that the integrator's complaint is answered and the attacker's window stays shut. The proposal is submitted for review with the reasoning attached, and the Journeyman records the intention it formed while working, marked as its own opinion and nothing more.

The Inspector takes it up next, reads it adversarially, and finds nothing to object to. Only then is a person troubled.

The Reviewer reads the proposal that afternoon and agrees with it. Merging it is the smaller of the two acts that follow. The larger is curatorial: the Reviewer, writing under the operator's key, records the intention as doctrine in their own name. The distinction is worth dwelling upon, because the merge button confers no authority whatever. Authority rests in the key, and the key rests with the operator. The graph now holds a second recorded intention beneath the first, explaining why renewal was introduced and what it was meant to preserve. The three actors are long since gone. The memory is a little larger than it was at breakfast.

Consider what happens in a factory without such a memory. A capable agent reads a clear, courteous, well-argued request to raise a timeout, finds nothing anywhere in the source to contradict it, and does exactly as it was asked. The change is small, the tests pass, and the reviewer, having no reason for suspicion, approves it. A security decision has been repealed by a machine that had no idea it was making one, and the commit message will explain the reasoning in fluent and confident prose.

Some Upcoming Features

Every recorded intention will be bound to a particular element of the system, so that when that element changes we are in a position to ask whether the intention still holds. A decision whose subject has quietly disappeared will then cease to be a stale document and will become an alarm, raised by the factory itself before the change is delivered.

Another feature will address the matter that this essay opened with. The conversation you hold with an assistant is at present a private affair, and whatever is concluded in it reaches the factory only when you trouble to carry it there yourself. We intend to give that conversation a patron of its own, called the Scout, a fellow DPYC Patron that bears an identity and a balance like the others and is permitted to file a report into the repositories on your behalf. (In GitHub, even for a public repository, anonymous strangers are not permitted to raise new issues, issue authors must be GitHub subscribers. Scout will be one.) An evening's discussion with Claude.ai might raise some issues or feature requests that would then arrive at the Porter's door by morning, already framed as a matter for triage, and the distance between having a thought about a system and that system's beginning to act upon it would be shortened to something near nothing.

A factory that curates Design and Decision Intention, in the manner this article highlights, has stopped pushing more and more paper into a messy filing cabinet and has begun to gain and use recollection, which is a considerable difference. It is an intention that we set out to achieve.