§1The system behind the chat
A Telegram message is not sent straight to an all-powerful model. It enters a gateway that identifies the conversation, loads the durable operating context, selects a skill, gives that skill a bounded tool surface, and formats the result for a small screen.
- 01TelegramIntent arrives in natural language.
- 02GatewayConversation and runtime state are resolved.
- 03Skill routerA named capability receives the task.
- 04ToolsOnly the required read or action surface is exposed.
- 05Evidence loopClaims are checked against observable state.
- 06Telegram resultVerdict, evidence, limits, and next action return.
§2The functions Hermes handles
Ask and orient
Answer questions from the maintained project context, explain which source owns a fact, and identify the safe place to begin.
“What is live now, and what would you verify before changing it?”Research and summarize
Collect sources, separate facts from inference, compare claims, and return a concise evidence-led brief.
“Compare the current evidence and list what remains uncertain.”Monitoring digests
Receive scheduled summaries from monitoring jobs, distinguish content changes from network failure, and surface only the exceptions that deserve attention.
“Show changes, confidence, and the items that need a human check.”Runtime diagnostics
Check gateway connectivity, scheduled-task cadence, service health, storage pressure, and the live model/profile state instead of guessing from stale files.
“Is the runtime healthy? Give me the evidence window.”Repository and release checks
Inspect revisions, diffs, worktrees, tests, generated surfaces, and preview state. Production remains a separate authority boundary.
“Run the release guard and explain every failure.”Memory and continuation
Summarize completed conversations, preserve durable decisions, and leave a compact continuation packet so the next session starts from evidence.
“What changed, what was proven, and what is the safest next action?”Action-capable workflows
Prepare bounded external actions but pause at the moment a message, permission, payment, production release, or other consequential state change would occur.
“Prepare it, show the final payload, and wait for approval.”§3Hermes uses skills, not one giant prompt
A skill packages one repeatable capability: inputs, allowed tools, steps, expected output, evidence, failure modes, and stop conditions. Monitoring, research, runtime health, release review, and handoff creation therefore behave as separate contracts even though they share the same Telegram interface.
This makes the system easier to reason about. A health skill can read service state but cannot publish content. A release-review skill can inspect and test but cannot silently deploy. An action skill must expose the final payload and wait at its approval gate.
§4Deterministic outside, probabilistic inside
Hermes can use a model to interpret a request or synthesize an answer, but the surrounding loop should be exact wherever exactness is available.
| Function | Uncertain core | Deterministic enclosure |
|---|---|---|
| Research | Which sources and synthesis are most useful? | Source URLs, dates, quote limits, and claim ledger. |
| Monitoring | Does a change matter? | Fetch result, diff, classification set, and scheduled cadence. |
| Diagnostics | What is the likely cause? | Exact service state, logs, exit codes, and resource thresholds. |
| Release review | Which risk deserves attention? | Diff ownership, test suite, link check, preview, and live hash. |
The detailed design pattern is documented in Designing skills and loops for certain and uncertain outcomes.
§5Design for the Telegram screen
A useful response leads with the verdict, then gives the evidence window, uncertainty, and next action. Long logs stay behind a concise summary. Scheduled digests collapse unchanged items and expand exceptions. Commands are readable as ordinary language; the user should not need to memorize a private syntax.
VERDICT
Healthy / degraded / blocked / action needed
EVIDENCE WINDOW
What was checked and when
CHANGED
Only material differences
UNCERTAINTY
What the checks do not prove
NEXT ACTION
One bounded continuation§6Telegram is an interface, not the security boundary
- Secrets, tokens, infrastructure paths, and private identifiers never belong in ordinary chat output.
- Read-only skills get the broadest autonomy.
- Local reversible changes require explicit scope and tests.
- External or irreversible actions stop for human approval at action time.
- Runtime truth is read from the active service, not assumed from old documentation.
- Every scheduled alert distinguishes “nothing changed” from “the check could not run.”
§7Failure modes the design anticipates
- Connected but unauthenticated: the gateway answers while the intended model or tool cannot.
- Healthy as the wrong user: a root-level test passes while the runtime identity cannot read its credentials.
- Silent fallback: the system routes to another provider and looks healthy.
- Missing success logs: storage settings hide successful runs, so absence is misread as failure.
- Notification without outcome: a digest arrives even though downstream state did not change.
- Chat as authority: a natural-language request is treated as permission for a consequential external action.
Hermes in one sentence
- A persistent operator reached through Telegram.
- Many named skills, each with its own authority.
- Probabilistic interpretation inside deterministic evidence loops.
- Scheduled monitoring and on-demand diagnosis in one surface.
- Human judgment retained at consequential boundaries.