Skip to content

A cheap worker deciding something expensive

Capability is dialled down for cost and nothing distinguishes the tasks where that is prudent from the ones where it is expensive.

→ let a fast, cheap session make a decision the whole codebase now lives with

cost when it happens
high
how often
occasional
area
cost
recognised by
research-team
engineering-lead
solo-builder
enterprise

The moment

A session set to the fast, cheap configuration is asked a question that turns out to be structural: how the records relate, where the boundary goes. It answers reasonably. The answer is now in the schema, and it will be there in two years.

Why it happens

The dial is set per session, not per task, and the tasks arrive mixed. Nothing marks the moment at which a question stopped being routine, so the configuration that was correct for the last three changes is applied to the one that matters. Cost pressure makes this the default direction of the error.

Why a better model does not fix it

Trivially, a better model here would fix this instance — which is exactly the point: the failure is that nothing chose. The next task will be mis-dialled in whichever direction the previous one left it, and half the time that direction is expensive.

What it costs

Asymmetrically. A rename done at maximum effort wastes a few cents. A boundary chosen by an under-powered session is paid for by every change that crosses it afterwards.

What Majordomus does

A profile is a small file that sets capability class, reasoning effort, verbosity, presentation, the context to load, the verification required and the checkpoint interval, independently. A task names one at start, and the generated instructions state which is in force. deep-work makes a decision record a condition of finishing, so a structural choice made under it is written down with its reason and its rejected alternative. Where a profile allows escalation, it is a recorded event after a stated number of blocked attempts.

Before and after

before   (cheap, because the last task was cheap)  -> the data model

after    $ majordomus start "choose the record boundary" --profile deep-work
         $ majordomus finish --outcome completed --verify-command "make test"
         FAIL profile  deep-work requires a decision record for this task

What it does not do

Majordomus never selects or invokes a model, and cannot observe what a worker actually ran. Profiles are projected into the instructions and validated as configuration; every profile-related claim is marked advisory for that reason.

What this looks like

Concrete situations, one per audience. Each is declared in the moment's front matter, so the before and the after are data rather than prose a page could drift from.

  1. A schema chosen in passing solo-builder

    before
    A quick session picks a data shape that the next six months are built on; the choice was never framed as a decision.
    after
    A task names a profile; `deep-work` requires a decision record before it can be finished, so the choice is at least stated.

  2. Optimising the wrong axis enterprise

    before
    Cost pressure moves all work to the cheap setting, and the saving is spent several times over on one bad interface.
    after
    Capability class and effort are per-profile fields, so cheap is a default for routine work rather than a policy for all work.

  3. Grinding instead of escalating research-team

    before
    An under-powered worker retries a problem it cannot solve, twenty times, at low cost each time.
    after
    Escalation is a recorded event after a stated number of blocked attempts, not a mood.

How you would know

The observable symptoms this moment declares. They are the questionnaire on the index and the input of majordomus why diagnose; nothing else defines them.

  • Everything runs on the cheap setting, including work whose consequences outlive the session. cheap-by-default
  • There is no defined point at which a blocked worker should escalate rather than continue. no-escalation-path
  • A structural choice was made by whichever session happened to be open. structural-choice-by-accident

Where this lives in the tool

Everything below is read out of this moment's own front matter and resolved against the repository. A name here that did not exist would fail validation.

the commands that answer it

the capabilities of the executable that answer it

what it supervises — derived from the claims below

the claims that back this page, and the evidence behind each

the rules that govern it

  • majordomus.justified-escalation
  • majordomus.profile-requirements
  • majordomus.decision-threshold
  • majordomus.depth-is-not-verbosity

the use cases that show the way out

If this one is familiar, so is the next

What this moment names, what names it, and what shares its area, audience or tags. The second and third are derived; only the first is written down.

All 38, and how they connect to the tool →