Hermes managed agents should default to a bare runtime profile

[mostlydev]

Problem

Clawdapus-managed Hermes agents still inherit consumer/personal-assistant first-run behavior from the upstream Hermes image. On a fresh HERMES_HOME, a normal domain question can trigger an introduction, /help guidance, and an offer to build a user profile instead of simply following the agent contract.

Clawdapus already suppresses several individual Hermes UX surfaces—busy acknowledgements, tool progress, memory and lifecycle notifications, cron response wrapping, and selected onboarding prompts. That piecemeal approach does not establish a stable invariant: when Hermes adds another consumer default, it can leak into managed agents until every downstream image or Clawfile is patched.

This happened in a production multi-agent pod after runtime materialization rotated the Hermes home directories. The durable downstream workaround was to add this to every active Hermes image:

CONFIGURE hermes config set onboarding.profile_build off

That fixes the profile offer, but it is still not the desired product boundary. Hermes also injects a first-contact introduction/help prompt when profile building is off, and future upstream UX keys could create the same class of regression.

Desired invariant: bare managed behavior

A Clawdapus-managed Hermes agent should default to a single bare runtime profile:

• no unsolicited first-contact introduction, /help mention, profile offer, or tutorial
• no first-time tips or onboarding prompts
• no busy acknowledgement or status chatter
• no lifecycle notifications
• no cron response wrapper
• no native tool-progress narration
• no generic Hermes/personal-assistant identity or unsolicited user-profile policy
• no new upstream consumer UX leaking into managed agents merely because Hermes adds a config key

The agent's explicit contract, SOUL, persona, config, and invocation should be the authority for identity and behavior.

“Bare” should disable unsolicited policy and chatter, not remove capabilities. Memory, tools, commands, explicit user-requested workflows, and hard safety blocks remain available. Consumer/personal-assistant UX should remain possible through an explicit opt-in.

Suggested product shape

Please establish a versioned, testable managed-mode boundary rather than adding only onboarding.profile_build: off to the current list. Possible shapes include:

• an upstream Hermes managed/bare profile selected by the Clawdapus driver; or
• a Clawdapus-owned bare profile in hermes-base, with the driver generating the complete config/environment contract.

The precise mechanism is open, but Clawdapus should own the invariant and detect upstream drift.

Acceptance criteria

• A fresh minimal CLAW_TYPE hermes agent with an empty HERMES_HOME answers its first normal message using only its configured contract—without an introduction, /help guidance, profile offer, or tutorial.
• The same remains true after claw up or any runtime/home rotation.
• No unsolicited gateway, lifecycle, cron-wrapper, tool-progress, busy-ack, or status chatter appears in bare mode.
• An explicit opt-in restores the consumer/personal-assistant experience.
• Contract/SOUL/persona content remains the source of identity and behavioral policy.
• Driver tests assert the generated bare configuration and environment.
• A hermes-base release canary starts with an empty home and exercises the first message and subsequent/busy-state behavior, failing when a Hermes upgrade introduces a new unsolicited UX surface.

Related work

This consolidates and completes the product boundary addressed piecemeal in:

• Hermes driver should replace runner default identity prompt for managed agents #187
• Hermes Discord tool-only mode can silently drop replies and publishes tool progress by default #190
• Hermes driver should default managed pods to non-interactive gateway UX #276
• Hermes managed pods should suppress gateway lifecycle notifications #278
• Default cron wrap_response to false (or expose it as a knob) #282

In particular, #276 established that managed pods should default to non-interactive gateway UX. A bare profile makes that promise durable across fresh homes and future Hermes image upgrades.

[mostlydev]

Supporting census from the production pod (tiverton-house @ hermes-base v2026.6.19-claw.3) quantifying the current suppression burden the bare profile would retire:

Per-Clawfile env suppressions (12): HERMES_SUPPRESS_RUNTIME_FAILURE_FINAL, HERMES_SUPPRESS_LIFECYCLE_STATUS, HERMES_SUPPRESS_EMPTY_RESPONSE_WARNING, HERMES_SUPPRESS_TRANSIENT_CRON_FAILURE, HERMES_SUPPRESS_AUXILIARY_WARNINGS, HERMES_SUPPRESS_BACKGROUND_REVIEW_STATUS, HERMES_SUPPRESS_TRANSIENT_EMPTY_FINAL, HERMES_TOOL_PROGRESS_MODE=off, HERMES_CHAT_STATUS_DELIVERY=off, HERMES_AGENT_NOTIFY_INTERVAL=0, HERMES_ALLOW_SILENT_FINAL=1, HERMES_DEFAULT_AGENT_IDENTITY=<contract override>.

Build-time site-package patches (4, re-anchored on every hermes-base bump): silent-final gateway fallback; transient-cron-failure delivery suppression; status-delivery hotfix; capability-policy hotfix (skill authoring removal).

Dated incidents from the defaults leaking:

• 2026-08-24: operator asked the coordinator agent a market question and received the first-contact flow ("/help shows commands … offer to build a short profile") — runtime rotation had reset the user store, so every deploy re-strangers every user.
• 2026-08-19: trader agent delivered a raw ⚠️ Cron job failed: <full provider error> to the production trading-floor channel for a transient 502.

Acceptance suggestion: a minimal Clawfile (CLAW_TYPE/AGENT/MODEL/HANDLE, zero suppressions, zero patches) should behave identically to today's fully-suppressed pod agent, making all 16 suppressions above deletable — with a canary test asserting the invariant so new upstream consumer keys fail loudly instead of leaking.