A typical managed-Hermes conversation
Current runtime contract: ADR-046.
The cast
| Person | Role |
|---|---|
| Amy Liu | Client Admin at Acme Financial |
| Eleanora | Acme's named client-facing Specialist |
| David Kim | Expert with optional observation/correction access |
| Sarah Chen | Account Manager for the client |
Eleanora is the identity Amy sees. Hermes is the internal managed runtime that acts as Eleanora; David is not a mandatory reviewer between Hermes and Amy.
1. Amy sends the real request
Amy sends this message through the client portal or a connected channel:
Hi Eleanora, customer JS-4821 failed KYC verification. Please review the current evidence and tell me whether an override is appropriate.
The platform authenticates the channel, persists the inbound message, and sends Hermes that exact text. If Amy attached a document, the API commits its bytes to the conversation's cloud AgentFS and adds a native structured resource block. It does not prepend KB snippets, history, policy prose, tool grants, or a JSON response contract.
2. Hermes resumes the session
The resident Bun machine resumes the existing Hermes SessionDB session. Stable persona and configured skills were established in AgentFS when the session was created; Humanwork does not render them again for this turn.
Hermes decides what the request needs. It may retrieve current KYC evidence, read a file, browse, or call another tool. Normal terminal/filesystem, HyperSH Git, browser/network, image, and configured provider tools are primary. MCP supplies a capability only when no normal tool provides it.
3. The successful reply is delivered
Hermes returns its canonical reply and exact SessionDB locator. Humanwork persists the locator and delivers the reply once as Eleanora. Confidence, risk, clarification, review state, and Expert availability do not hold or replace it.
If Hermes fails, the platform reports the real failure. It does not invent a safe-sounding Eleanora reply or create a queue item as a substitute.
4. A real external write remains explicit
Reviewing evidence is not the same as changing an external system. If Amy later explicitly authorizes an override, Hermes invokes the appropriate normal tool, or an MCP capability when the normal tool is absent.
A server-owned policy may opt that concrete external write into the isolated approval compatibility carrier. In that case the bound side effect executes once after its authorized decision. The carrier does not alter Amy's message, narrow Hermes' tools, fabricate an ACP continuation, or turn unrelated successful replies into drafts awaiting release.
5. Optional Expert work is after delivery
David may inspect the delivered conversation, investigate a genuine failure, add an internal note, or correct delivered Specialist text when authorized. A correction targets the exact Hermes SessionDB assistant locator; a genuine human-authored follow-up is appended once and uses the locator SessionDB returns. Humanwork never creates a synthetic delivered-message projection.
6. Files remain in cloud AgentFS
Hermes and its normal tools read and write the conversation's AgentFS workspace. The API also accesses that cloud authority directly when it accepts an attachment or serves the same generated object by managed virtual file URI. It does not publish a second R2/base64/host/AgentFS copy. File bytes and file-operation RPCs never travel through the public hermes-run socket, and no host workspace is hydrated or flushed back.
Principles illustrated
- The client sees one consistent Specialist identity.
- The turn input is the actual message and attachments.
- Hermes owns history, context retrieval, skills, and tool choice.
- Native tools are primary; MCP fills only missing capabilities.
- Every successful reply is delivered once.
- AgentFS and SessionDB are the only session file/transcript authorities.
- Explicit side-effect approval, when configured, is narrow and is not a general reply gate.