Creating the first agent

hermetic agent create atlas                          # medium size, bedrock, no extra secrets
hermetic agent create atlas --size small
hermetic agent create atlas --rollback-on-failure    # undo what the run made instead of leaving it to re-run

A create that fails leaves the agent half-made on purpose: the row names what exists in AWS, and re-running hermetic agent create atlas finishes it (or hermetic agent destroy atlas --yes clears it). --rollback-on-failure chooses the other answer — the run unwinds only what it itself created, in reverse, and rethrows the original error, so you are left with nothing rather than something to finish. It is worth passing in scripts and on a first attempt at a name; it never deletes a volume or an instance the run found rather than made, and on a resumed create it leaves the row, the SSM slots and the config alone. If one undo step fails, the rest still run and the row survives, with an event telling you to run hermetic agent destroy atlas --yes. Interrupting a create with ctrl-C does not roll it back — an interrupt means stop, and the row it leaves is the resumable one you would want.

Takes about 8 minutes end to end (AMI boot, package install, Hermes setup). Watch it with hermetic agent status atlas or the dashboard’s create-progress drawer, which reattaches to the running op if you close and reopen it. An agent created with no flags is a complete, sealed agent — zero inbound rules, Tailscale-only access, Bedrock through the instance role.

Configuring Hermes itself

An agent created with no Hermes flags is already usable: hermetic writes the provider wiring, and seeds a model and sane defaults into the agent’s own config on first boot. Naming a setting changes who owns it:

hermetic agent create atlas --model anthropic/claude-opus-5
hermetic agent create atlas --terminal docker --max-turns 200 --reasoning high
hermetic agent set atlas --model us.anthropic.claude-haiku-4-5-20251001-v1:0

hermetic manages what you tell it to manage. A setting you name goes into the agent’s managed config (/etc/hermes/config.yaml), is rewritten on every apply, and cannot be changed on the box — hermes config set refuses a managed key, and hermetic agent set is what moves it. A setting you leave out is seeded once into the agent’s own $HERMES_HOME/config.yaml and is then the agent’s: change it from its dashboard, and hermetic will not write it again.

The model id is spelled the way the provider spells it, and hermetic does not translate: claude-sonnet-5 on the Anthropic API, anthropic/claude-sonnet-5 on OpenRouter or the Nous Portal, a us.-prefixed inference-profile id on Bedrock. A Bedrock model must also be one the fleet’s role may invoke — the foundation policy grants DEFAULT_BEDROCK_MODEL_IDS and nothing else.

agent set re-renders and re-uploads the agent’s config, but nothing reaches a running box on its own: until it is applied, the agent reads as config-drifted. Apply it in place with a rollout (hermetic plan rollout --agent atlas --json > rollout.json, then hermetic apply rollout.json), or let the next agent rerun or agent recreate carry it.

The agent boots but the first message fails

No inference provider configured. Run 'hermes model' … means Hermes started with no provider or no model. 06-verify now catches this at bootstrap — hermeticd stage verify-hermes fails the stage and names which of provider / model / key is missing — so a newly created agent cannot reach you in this state. An agent created before that check existed can:

hermetic agent set atlas --model anthropic/claude-sonnet-5   # or the right id for its provider
hermetic agent rerun atlas

If the missing piece is the key rather than the model, hermetic secrets push atlas --provider-key fills the slot and the next rerun materialises it.