Agent operations and organizational memory
Period —
The lead agent runs continuously on Hermes Agent and handles infrastructure monitoring, incident investigation and operating decisions. Role agents divide up accounting, development, listings, customer support and advertising. Execution is controlled by actual tool permissions and completion conditions, not role descriptions. Incidents are kept as records that survive restarts, and reviewed business facts are kept as Git documents.
A lead agent assigns work to role‑specific agents,
and keeps incident and business records across restarts
- A machine‑readable permission list per role covering allowed work, forbidden actions and result and retry rules
- A hook that checks tool calls in advance so the finance role can use only designated lookup scripts and read‑only tools
- Incident records and alerts that log incidents under fixed IDs per cause and do not count restarts as new incidents
- Unattended operation that starts automatically after outages, reboots and automatic updates, and confirms messenger connections
- Git documents holding reviewed business facts, with conversation memory and search indexes rebuilt from them
- Search that looks in current‑state documents first for questions about the present and never presents past decisions as current facts
The same incident alerting again on every redeploy
- Problem
- Each restart or redeploy sent the same supply collection failure again as a new alert.
- Solution
- Incidents are recorded under fixed IDs by supply scope and cause, keeping the last success, the start of consecutive failures, occurrence count and alert status. Logs going quiet is not treated as recovery; recovery needs official evidence. Each incident alerts once and closes in the thread where it was first reported.
Messenger connection lost after an automatic update
- Problem
- After an automatic update, the agent restarted its messenger connection service itself and lost the connection entirely when the service registration went missing.
- Solution
- A separate runner handles updates and records success only when the service registration and the running process are both confirmed. An independent watcher checks the state and recovers it. In a test that took the service down on purpose, the watcher recovered it with a new process, and Telegram and Discord reconnected.
Recovery after outages and reboots
- Problem
- After an outage or reboot, the agent and search server stayed down until someone logged in.
- Solution
- The machine boots automatically when power returns, and after auto login it starts the agent, the search server and job workers. A post‑boot script checks the processes, messenger connections and search server state. A real reboot passed all post‑boot checks.
Search that made past decisions look current
- Problem
- Search results mix past and current decisions.
- Solution
- Questions about the present search current‑state documents first and rank them above older records. For important decisions, the agent rereads the source, and archive folders are left out of default search.
Architecture
Single entry point for requests · final decisions
InterpretPlanAssignExecuteVerifyDecide
Knowledge and memory
- Business record
Goals · decisions · status · roadmap
Never changed automatically outside the defined procedure
- Agent rules
Principles · workflows · operating log kept in Git
Kept apart from the business record
- Runtime memory
Built‑in Hermes Agent memory · fallback when the search layer is down
- Derived search
OpenViking · re‑indexes Git documents and conversation memory
Never used as the record of truth
Execution and control
- Task‑specific execution systems
Commerce backend · operations console · sourcing collector · infrastructure · DB · each system checks permissions before it runs anything
A role agent's report alone never marks work done
- Task ledger
Only for long‑running work, handoffs, retries and audits
- Permission levelsL0 · L1
L0 read · classify · draft / L1 run a step of a defined workflow
A level alone grants no external writes
- Operations alerts
Outage alerts are a signal that wakes the lead agent
Alerts never make the decision
Development‑only roles
- Root‑cause researchL0
Reads code, logs and official docs to gather evidence
No edits or state changes
- Ticket implementationL0
Implements, tests, commits and verifies locally within the ticket
No merges or deploys
- QA and security reviewL0
Judges finished changes for regressions and security
No implementation or release decisions
Domain roles
- Product listingL1
Product planning · detail pages · official re‑check after listing
No direct DB or channel writes, no purchase orders
- Customer messagesL0
Classifies customer messages · gathers facts · drafts replies
No sending, refunds or compensation
- Finance lookupL0
Reads and reconciles revenue, cost, settlement and cash‑flow sources
No transfers or orders · unconnected sources are never filled with zero
- Ad decisionsL0
Ad and marketing decisions from confirmed evidence
No spend, budget or bid changes
- Supplier noticesL0
Observes and normalizes supplier notices · keeps the source
No price, stock or order changes
Result flow
Role agent runsResult in a fixed format · evidence, checks, risksLead verifies against real sourcesBusiness system runs after a permission checkOfficial re‑check confirms completion