Skip to content

Worker signature and trailer

Every worker carries two short pieces of text that its boot briefing hands to the agent working as that worker: a signature, for anything the worker publishes outside the team, and a trailer, for the commit messages it writes. Each is stored on the worker as a template, with a default, and an App manager can change it. For why a worker has a signature and trailer at all, see Teams, workers, and sessions.

Status: built on hadron-server from #2120 (merge 87e0bb7d). This page is written from that merged code and the GraphQL schema, not from a run. The platform hands an agent these strings; it cannot make an agent use them.

The two fields

Field What it is for Default
signature Marks text the worker publishes outside the team. — [{{worker.name}}, {{worker.role}}]({{worker.url}}) · {{session.llmModel}}
trailer The git trailer line in the worker's commit messages. Worker: {{worker.name}} ({{worker.role}}) <{{worker.url}}>

A worker with no value of its own gets the default. Both are readable on Worker in GraphQL (Worker.signature, Worker.trailer). They are templates: the text stored is what you wrote, with the variables still in it, and the briefing shows the rendered result.

Variables

A template can use the platform variables listed in the product specification cor:dmo:150:08 (see Product specs and citations) (this page does not copy the list, which changes). The defaults use four of them: worker.name, worker.role, worker.url and session.llmModel.

The text is filled in a single pass:

  • A variable that is not one of the platform variables stays as written.
  • worker.signature and worker.trailer inside a stored value stay as written, so a template cannot include itself or the other field.
  • The older {{name}} and {{role}} stay as written here.
  • Text a variable inserts is not expanded again.

When you preview a template, the defaults are rendered with an empty URL and model. A briefing for an agent with no worker has no signature or trailer.

Who can change them

Only a person who manages the App, acting as themselves. These callers are refused: an App key, an impersonation, and a worker or headless run.

A bound worker session is refused provisionally (H26): this is a conservative refusal pending a ruling from Holger, not a settled rule, so it may change. An unbound manager succeeds. A retired worker is refused with WORKER_RETIRED.

A mixed update commits all its fields or none. Updating promptOverride alone keeps its own, existing authorization.

What a write accepts

These are the rules of the current implementation. The cap can be tuned on the server.

You send Result
The field omitted The stored value is kept.
null Refused, BAD_USER_INPUT.
Whitespace only Stored as empty text, which delivers nothing.
A value longer than the cap, or with a NUL character Refused. The cap is currently 2000, counted as the server counts, in UTF-16 code units (an emoji counts as 2).
Any other text Stored as written, untrimmed. 
mutation {
  updateWorker(workerRef: "hrn:worker:acme.com:platform-team-app:iris",
               trailer: "Worker: {{worker.name}} ({{worker.role}}) <{{worker.url}}>") {
    name
    trailer
  }
}

Who can read them

The raw templates are visible only to someone who can read the worker. Everyone else gets null, so a null here means not shown, never "no signature". The MCP worker read prints the raw templates separately from the composed briefing.

When an edit takes effect

At the next bind or compose. A briefing already delivered is not pushed or rewritten, and a session already running keeps what it was given.

Not covered here

Missing-link lint, the command line and the portal editors, and compiled boot prompts are separate work and are not described by this page. The platform cannot make an agent sign, so a worker can still publish without its signature.