[portfolio](https://geonwoo.kim/en/portfolio) › deepeet # Agent operations and organizational memory https://geonwoo.kim/en/portfolio/deepeet-agent-ops Period: 2026.07 — 2026.08 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 Team: Solo Role: Role and permission design · Unattended operation and recovery · Incident records and alerts · Organizational memory Built tools: [vat](https://geonwoo.kim/en/portfolio#tools) Hermes Agent · Codex CLI · Python · Shell · Telegram · Discord · launchd · OpenViking · Git - 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 Lead agent Single entry point for requests · final decisions Interpret → Plan → Assign → Execute → Verify → Decide ### 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 levels · L0 · 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 research · L0 Reads code, logs and official docs to gather evidence No edits or state changes - Ticket implementation · L0 Implements, tests, commits and verifies locally within the ticket No merges or deploys - QA and security review · L0 Judges finished changes for regressions and security No implementation or release decisions ### Domain roles - Product listing · L1 Product planning · detail pages · official re-check after listing No direct DB or channel writes, no purchase orders - Customer messages · L0 Classifies customer messages · gathers facts · drafts replies No sending, refunds or compensation - Finance lookup · L0 Reads and reconciles revenue, cost, settlement and cash-flow sources No transfers or orders · unconnected sources are never filled with zero - Ad decisions · L0 Ad and marketing decisions from confirmed evidence No spend, budget or bid changes - Supplier notices · L0 Observes and normalizes supplier notices · keeps the source No price, stock or order changes ### Result flow Role agent runs → Result in a fixed format · evidence, checks, risks → Lead verifies against real sources → Business system runs after a permission check → Official re-check confirms completion [Routing and sales status control](https://geonwoo.kim/en/portfolio/deepeet-routing) · [Sourcing data](https://geonwoo.kim/en/portfolio/deepeet-sourcing)