Meet Quartergremlin

The factory has a gremlin named Quartergremlin. It scaffolds new projects. The name is a joke. The job is not.

I want to use it to explain a claim I will keep making across this series: a playful name is fine, and a bounded role is mandatory, and the second one is what makes the first one safe.

The useful part of the joke

The name is load-bearing in exactly one way. It is memorable. When I say “Quartergremlin did the scaffold,” I know precisely which bundle of behaviour ran, what it was allowed to touch, and where it stopped. A name turns a vague capability (“the AI sets up projects”) into a specific actor with a contract.

That is the only work the whimsy is allowed to do. The moment the name starts doing more than that, the moment it becomes a character whose charm excuses fuzzy behaviour, it has to be cut. A gremlin you cannot pin to a contract is just an unaccountable process with a marketing department.

What a bounded role actually is

A bounded role is four plain things written down: what it takes in, what it puts out, what it must never do, and when it stops. Miss any of the four and you do not have a role, you have a vibe with a job title.

Most agent demos give you the first two. The inputs and outputs are the exciting part, the part that produces output you can screenshot. The forbidden actions and the stop condition are the boring part, and they are the entire reason you can leave the thing running without watching it.

What Quartergremlin owns

Quartergremlin’s territory is narrow and complete. It classifies the project, creates the documented container, lays down the governance and traceability files, sets up the repo-local mirror of the knowledge base, validates the structure against the conventions, and writes the first set of next actions.

That is a real amount of work, and all of it is the same kind of work: setting up a place for the real work to happen. Everything Quartergremlin does is reversible, inspectable, and free of product decisions.

What Quartergremlin must never do

Here is the part that makes it trustworthy. Quartergremlin must not build the product. It does not write feature logic, it does not make architectural calls that belong to a human, and it does not touch an existing project’s contents without explicit approval.

The stop condition is the sharpest line of all: once the container is built and validated, Quartergremlin hands off to a human and stops. It does not helpfully keep going. A scaffolder that starts writing your application because it was on a roll is not helpful; it is an unscoped agent that happened to start with a folder.

The contract, on a card

All of this fits on a single card, which is the form a public version of the role should take.

Why the name survives the review gate

Plenty of teams would look at a gremlin called Quartergremlin and assume the work behind it is unserious. The opposite is true, and the reason is the contract. The name makes the role easy to talk about; the contract makes it safe to trust. The joke survives contact with a serious review gate precisely because, when you pull back the whimsy, there is a plain responsibility underneath, written down, with a hard stop.

The rule generalises to every named role in the factory: pair every playful label with a concrete responsibility. If you cannot write the responsibility, you do not get the label. This is a validated pattern in the small, across a handful of roles. Whether it scales to a zoo of fifty gremlins without turning into lore is a question I have not earned an answer to yet.