Skip to content

Nobody can say why that worker was chosen

Provider and model selection is made implicitly, per session, and recorded nowhere, so it cannot be reviewed or repeated.

→ could not say why one provider was used for that work and another for this

cost when it happens
medium
how often
common
area
cost
observability
recognised by
research-team
enterprise
agency
engineering-lead

The moment

Two providers have been in use for a quarter. Somebody asks which one to standardise on. The available evidence is that one of them "feels better for refactors", and nobody can point at a single piece of work and say which produced it.

Why it happens

The choice is made at the moment a window is opened, which is not a moment anybody thinks of as a decision. It leaves no artefact: the code looks the same whoever wrote it, and the commit records a human author.

Why a better model does not fix it

This failure is about the absence of a record, not the quality of the work. Every model involved may have performed well; the point is that nobody can demonstrate it, so the next choice is made on the same basis as the last one — impression.

What it costs

A recurring, unresolvable argument, and a spend allocation that cannot be defended. Where a policy exists about which work may go to which provider, its application cannot be shown at all, which makes the policy decorative.

What Majordomus does

An execution episode is a record: when it opened, when it closed, what it was for, and what happened under it. A task names the profile it ran under, and that profile — capability class, effort, verbosity, context — is projected into the instructions the worker reads, so the intended configuration is a written fact rather than a habit. The ledger carries the outcome, the verification command, its exit code and its duration, so work done under different configurations can be compared on something.

Before and after

before   commit author: a person.   worker: unknown.   profile: unknown.

after    $ majordomus session list
         s-20260905T2214Z  closed  profile=deep-work  tasks=2  outcome=completed,partial

What it does not do

It does not select, invoke or measure a model, and it cannot see what a provider actually ran. It records what this repository decided and what happened, which is the half that is missing today.

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 comparison nobody can settle research-team

    before
    Two providers are used side by side for a quarter, and the question of which was better is answered by preference.
    after
    Each task records the profile it ran under; the outcome, the verification and the duration are events, so the comparison has data behind it.

  2. The client asks what wrote this agency

    before
    The honest answer is a shrug and a guess based on the date.
    after
    The tool the session ran under is identifiable, and the task record and ledger carry what happened under it.

  3. A routing policy with no evidence of application enterprise

    before
    A policy says which class of work may use which provider; nothing records whether it was followed.
    after
    The profile in force is projected into the instructions and recorded with the task, so the policy has an observable trace.

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.

  • Which assistant is used for which work is decided by habit, not by a stated rule. chosen-by-habit
  • Nothing records which model or provider produced a given piece of work. no-record-of-choice
  • Two providers have been used for months and nobody can compare how they did. cannot-compare

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.session-records
  • majordomus.justified-escalation
  • majordomus.ledger-integrity
  • project.never-author-identity

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 →