Gary Engineering Lab #001: Recovering Hermes and Ornith — Why a Connected Agent Still Failed

Engineering log · October 11, 2026 · Freedom’s Purchase Ranch · Status: measured local tests; broader reliability system under development

Most self-hosted AI demos begin with a successful prompt. Our latest test began with a Telegram message that failed. The useful question wasn’t whether the bot appeared online; it was whether a complete message could travel through the gateway, agent runtime, model server, and back again.

Environment under test

• Host: Windows 11 workstation, AMD Ryzen 9 3950X, 96 GB RAM, NVIDIA RTX 5060 Ti 16 GB.
• Agent: Hermes gateway 0.21.5, Telegram interface.
• Inference: local Ollama server running a 9-billion-parameter Ornith model.
• Goal: eliminate a model-context initialization failure, retain GPU acceleration, and preserve rollback options.

The failure: connected is not healthy

The Telegram gateway was polling successfully but the attempted Ping failed. Examination of the local exception trace showed that the agent refused to initialize: its minimum accepted context was 64,000 tokens, while the configured Ornith instance advertised only 32,768. This is a configuration and compatibility failure—not evidence that a network connection or model quality is inadequate.

Our first corrective test requested a 65,536-token context from the existing model. The Ollama API returned HTTP 200 in approximately 8.3 seconds for a short arithmetic check. The running-model status showed 65,536 context and 100% GPU placement. A subsequent full Hermes one-shot conversation also returned PONG.

A second trap: context settings can drift between callers

After that successful agent test, the live-model listing later showed a 32,768-token context again. Request-level overrides are not a reliable guarantee that every caller will use the same serving configuration. We therefore created a separately named model profile with num_ctx 65536 embedded in its model definition, while reusing the existing weights. Production and fallback profiles remain separate.

Measured results

Test	Observed result	Interpretation
Telegram inbound Ping before repair	Failed at agent initialization	Minimum-context check rejected 32,768
Ollama API, original profile, explicit 65,536 context	HTTP 200; ~8.3 s; GPU placement	Model served a request at the target context
New 64K GPU profile, direct Ollama API	HTTP 200; PONG; 6.27 s	Dedicated profile worked without an explicit per-request context override
Hermes agent, new 64K GPU profile	PONG; one model call; ~8.3 s model-call latency	Agent initialization, inference, and completion passed
Gateway restart and Telegram polling	Connected; 65,536-token model warmed	Gateway healthy; a fresh post-change Telegram round trip remains a separate acceptance gate

Benchmark caveat: These are engineering smoke tests, not a representative throughput or quality benchmark. Inputs, cache state, prompt sizes, and timing scopes differ between tests. The full Hermes test processed roughly 19,300 input tokens in its agent context, whereas the direct API check was much smaller. Comparing their wall-clock times as a model-speed contest would be misleading.

What we learned

1. Require end-to-end health checks. A listening port and a healthy polling loop do not establish that a user can get a response.
2. Make inference profiles explicit. Model name, artifact identity, quantization, context length, and CPU/GPU placement belong in versioned configuration.
3. Separate availability from correctness. A successful PONG proves connectivity and basic generation, not reasoning quality, coding skill, or safe tool execution.
4. Preserve the failure and the fix. Backups, redacted traces, exact parameters, failed checks, and measured outcomes make improvement reproducible.

Next: the FPR Mechanic project

We’re developing a modular, local-first reliability layer for self-hosted agents. The first components are intended to record structured test receipts, observe health, compare versions, validate recoverability, and publish redacted engineering logs. Later phases will add policy-gated remediation and independent watchdogs. The system is not yet a finished public release; we will publish installation instructions, source, tests, known limitations, and a license only as the individual modules clear their acceptance gates.

Our principle is simple: show the failure, show the evidence, show the recovery—and never confuse a green dashboard with a working system.