From Scripts to Seats

One of the questions I keep getting about software factories is what I mean when I say “seats beat scripts.” It came out of running a factory long enough that the agents stopped looking like isolated executions and started looking like members of a very small development organization. With agent tooling now moving quickly toward goals, continuation, scheduled work, and automated evaluation, I think the distinction is becoming useful outside my particular experiment.

A script is something you run. A seat is something that holds responsibility.

The difference sounds small, but once agents persist beyond a single task, it changes how you design and govern the system around them.

Scripts work surprisingly well

Most agentic development systems begin with something that is effectively a script. Take an issue, give it to an agent, let the agent make a change, run some checks, review the result, and either accept it or try again. You can make that loop increasingly sophisticated with better context, tools, retries, evaluators, budgets, and permissions. Eventually you can give the agent a goal instead of a tightly specified task and let it continue until some acceptance condition has been satisfied.

That is already useful automation, and the tooling around it is getting much better. Goal-driven loops and scheduled agents are turning machinery that many of us hand-built into product features. I think that is a good thing. I would rather spend my time deciding how the system should operate than maintaining another bespoke loop.

But making the loop persistent exposes a different problem. If I have five automated loops working around a repository, one reviewing security, another checking architecture, another grooming product intent, another hunting maintenance work, and another reviewing implementations, I eventually need to know more than whether their last executions succeeded. I need to know whether each of them is actually good at the responsibility I have delegated to it.

That is where scripts stop being a useful abstraction.

A seat has a standing charge

The shift in my own factory happened when I stopped thinking about agents as anonymous workers that received instructions one invocation at a time. Instead, some of them acquired durable responsibilities. A product seat turned raw intent into well-formed work. Review seats attacked changes from particular perspectives. One might challenge feasibility while another challenged security. Their instructions, available context, expected evidence, permissions, and escalation paths differed because their responsibilities differed.

The important part was not giving the agents cute names or pretending they were people. A seat gives the system a stable unit of responsibility. The security seat has a standing charge regardless of which model happens to occupy it today. Its authority can be bounded, its decisions can be recorded, and its performance can be evaluated over time.

That last part turned out to matter a lot. If a reviewer objects to a change, I want to know which responsibility produced the objection. Later I can ask whether the finding survived scrutiny, whether the supposed problem ever mattered, whether that reviewer is producing useful dissent or mostly noise, and whether it has developed a tendency to agree with everything it sees.

A script has an execution history. A seat has a performance history.

That is the distinction behind the line I wrote after several months of running the factory: named seats you can calibrate beat anonymous runs you can only rerun.

The judges need judging

Agentic systems put a lot of emphasis on evaluation, and rightly so. More autonomy is only useful when the system has some way to determine whether the work is acceptable. An agent that can run for six hours instead of six minutes is not necessarily more capable. Without strong checks, it simply has six hours to produce the wrong thing.

The less obvious problem is that evaluators themselves become actors whose performance matters. A security reviewer that flags everything is useless. A reviewer that approves everything is also useless. A product seat that generates an endless stream of plausible improvements can look extremely productive while filling the factory with work nobody actually needs.

I eventually started keeping ledgers on some of these judgments and comparing old findings with what happened later. Some findings turned out to be theater. Some reviewers agreed with nearly everything, which is a defect, not a virtue. Some seats were consistently useful enough that I could trust their judgment more than I had initially expected.

That changes the question from “Did this run succeed?” to “Is this actor good at its job?”

Once you can answer that question, you can calibrate the seat. A reliable actor can earn more delegated authority. A noisy one can have its authority narrowed, its instructions changed, its evidence requirements strengthened, or the model occupying the seat replaced entirely.

This also separates the role from the implementation. Claude, Codex, or whatever model comes next is not the security reviewer. It occupies the security seat under a particular set of instructions, tools, permissions, standards, and checks. Models can change without redesigning the organization every time the leaderboard moves.

That separation is going to matter more as models become increasingly interchangeable infrastructure.

Verification determines where the seats move

There is a simple rule underneath how I think about delegation: work converts to agents where its output can be verified mechanically; people survive where their judgment is the verification.

“Mechanically” does not mean everything needs a perfect deterministic unit test. Verification can come from tests, policy checks, static analysis, runtime evidence, scenario evaluation, adversarial review, production telemetry, another model, or sometimes a human. What matters is that the acceptance mechanism is sufficiently independent of the actor doing the work that the actor cannot simply declare itself successful.

The stronger that mechanism becomes, the more authority I am comfortable delegating. If a change has clear acceptance criteria, strong automated evidence, constrained permissions, and a reliable recovery path, there is little reason for a human to inspect every line simply because a machine wrote it. Human attention can move upstream toward the places where judgment is still the scarce input.

This is why I think the discussion about whether agents will become “more autonomous” misses part of the interesting transition. Autonomy is not a capability you turn up globally. It is authority delegated to particular actors under particular conditions. A security seat might be trusted to block a merge but not change the security policy. A maintenance seat might be allowed to open and repair dependency issues but not redesign a public API. A product seat might propose work all day and still lack the authority to decide what enters the roadmap.

The goal is not maximum autonomy. It is calibrated autonomy.

The operator makes the handoff

This is also where the operator matters. A seat does not emerge fully formed because you gave an agent a clever prompt. You drive it there.

You begin with a script and your own knowledge of the SDLC, the repository, the standards, the risks, and what good work looks like. You run the loop, watch where it succeeds and fails, add evidence, improve its context, tighten its authority, and turn what you know into artifacts and controls the system can use without you standing beside it.

The handoff is the hard part.

You are not simply replacing a person with an agent. You are extracting enough of the operating knowledge around a responsibility that it can be delegated safely. What information does the person use? Which decisions are routine and which require judgment? What does good evidence look like? What failure modes do experienced people recognize almost unconsciously? Which decisions can be checked independently? Which actions need constrained permissions? When should the system stop and ask for help?

A lot of that knowledge already exists in the SDLC, even if we have historically been sloppy about making it explicit. Tests, architecture decisions, security policies, definitions of done, code-review expectations, deployment gates, incident procedures, product specifications, and operational standards all contain pieces of the job. The operator's task is to assemble those pieces into a working environment for the seat and fill the gaps where the organization has historically relied on tacit knowledge.

That is why the transition is rarely binary. Early on, the operator may drive the seat closely, approve most of its work, and fill in missing context. As the checks improve and the actor builds a performance history, the operator can progressively delegate more authority. The seat earns trust rather than receiving it because someone switched on an “autonomous” mode.

Some responsibilities will cross that boundary quickly. Others may never cross completely because human judgment remains the best available verifier. That is fine. The objective is not removing the operator. The operator moves up a level, from performing the work to designing and governing the system that performs it.

That makes the handoff a design problem, not simply a model capability problem.

Seats eventually become an organization

Once enough responsibilities move into seats, another thing happens. You stop building a workflow and start building a small organization.

There is work intake. There are responsibilities. There are rules. There is evidence. There are disagreements. There is memory. There are changes to policy. There are escalation paths. There are things some actors are allowed to do and things they are not.

Some actors can make decisions that other actors cannot. Some decisions require stronger evidence. Failures create new controls. Past decisions constrain future work. Actors can challenge one another, and eventually you need rules governing how those disagreements are resolved.

At that point I found that I was no longer building a clever pipeline. I was building a very small development organization.

That observation eventually became the model I call PAAA: Purpose, Articles, Actors, Artifacts. Purpose gives the organization direction. Articles define what must remain true, including its rules, constraints, gates, and obligations. Actors perform work under delegated authority. Artifacts preserve what the organization knows and produces, including decisions, evidence, specifications, code, and institutional memory.

A seat is an Actor, but it only makes sense in relationship to the other three. Without Purpose, an actor can become extremely productive at doing something nobody needs. I learned that one when I stopped feeding my factory fresh direction for a while and watched it happily manufacture its own busywork. Without Articles, it has authority without governance. Without Artifacts, every run has to rediscover lessons the organization already paid to learn.

Throughput without trust is Actors without Articles. The memory problem is Artifacts. A factory happily optimizing noise is a Purpose problem. The abstractions turned out to map surprisingly well onto the failures I had already encountered.

This is why I increasingly think of a software factory as a governed organization whose labor happens to be largely machine-executed, rather than as a collection of agents.

Scripts → Loops → Seats → Organization

There is a progression here that I think explains a lot of what is happening in agentic software development right now.

Scripts execute instructions. Loops pursue goals. Seats hold responsibilities. Organizations coordinate those responsibilities under shared governance.

The industry is moving very quickly through the first two. Agents can already work for longer periods, use increasingly capable tools, pursue goals, inspect their own results, ask other models to judge them, and wake up later to perform more work. Much of the orchestration machinery that required custom engineering a year ago is becoming something you configure.

That does not make the problems I encountered disappear. It gets more people to them.

Once the loop works, you have to decide who should be responsible for what. You need to know how much authority each actor should receive, whether a reviewer is actually useful, how two individually successful actors avoid creating system-level incoherence, how yesterday's failure becomes tomorrow's rule, and who has authority to change those rules. Eventually you need to decide when a machine seat has demonstrated enough reliability to inherit responsibility that previously belonged to a human one.

You also have to preserve what was valuable about the human process without blindly encoding all of its ceremony. The goal is not to reproduce every meeting, ticket state, approval chain, and handoff with agents. Some of those existed because human coordination was expensive. The interesting work is figuring out which parts represented real controls and which parts were compensation for the limitations of the old labor model.

Those are not primarily prompting problems. They look much more like organizational design.

That is why I keep coming back to seats. The model will change. The harness will improve. The loop itself is rapidly becoming commodity infrastructure. What remains is the responsibility you are delegating, the authority attached to it, the evidence required to exercise it, and the history that tells you whether the actor occupying that seat deserves your trust.

We started by writing scripts that could produce code. Then we taught them to keep working. Now the harder work is designing the system around them: deciding which responsibilities become seats, encoding enough of what the operator knows to make the handoff safe, and determining how much authority each seat has earned.