How to build an accountable AI employee with Buzz and Hermes

The finished build is one named Hermes Research Director that works inside designated Buzz channels, remembers only approved business knowledge, uses only authorized tools, asks for approval before consequential actions, posts progress without being chased, and returns proof receipts for completed work.

The agent is an employee-shaped operating unit, not a free-form chatbot. It has a job, a manager, a workspace, memory rules, permission limits, escalation behavior, and acceptance tests.

Buzz owns visible collaboration: the organization, channels, role identity, requests, approvals, decisions, proof, and escalation trail. Hermes owns the persistent agent runtime: memory, reusable knowledge, research behavior, and skill improvement inside the allowed boundary.

Credentials should stay isolated to the system that needs them. Buzz should preserve what was requested and approved; Hermes should not silently expand scope because it has local memory or tool access.

Give the operator a business name such as Hermes Research Director. Define company, role, responsibilities, allowed channels, activation phrases, manager, escalation owner, allowed source types, and disallowed actions.

A good role statement is narrow: watches a market-intelligence channel, researches approved topics, posts sourced findings, stores reusable knowledge only after approval, and escalates uncertain claims to a human.

The default permission set should be read approved Buzz channels, write progress and research reports, store approved durable knowledge, and run approved research tools. It should not email, message customers, spend, publish externally, delete records, change credentials, or approve its own work.

High-risk work requires approval before consequential actions. That includes external outreach, credential changes, production writes, payments, legal or pricing claims, customer commitments, destructive actions, and memory promotion that changes company doctrine.

A safe workflow is trigger, context, decision, approval, action, proof, completion. The request starts in Buzz. Hermes reads the channel context, drafts a plan, asks for approval when needed, executes only authorized research, posts findings with sources, and records the proof receipt.

The guide's first test mission should be safe and repeatable: request a competitive report in a test channel, require a plan, approve the research, receive a sourced report, promote one approved memory item, and verify the failure path by asking for an unsupported claim.

The installation is not complete because Hermes replied. It is complete when the system produces a request record, agent identity, plan or decision, approval record, action result, supporting evidence, timestamp, and failure state when applicable.

The proof receipt should make the next operator able to answer: who asked, what was authorized, what the agent did, what evidence supports it, what changed, what failed, and what still needs a human decision.

Before production use, verify channel membership, trigger phrase, memory boundary, source policy, tool allowlist, approval gate, timeout, kill switch, logging, proof format, escalation owner, and rollback instructions.

Only after the safe test mission passes should the agent touch real business systems. Even then, consequential actions should remain owner-gated until enough accepted receipts justify expanding authority.