Gormes

§ 01 · OPEN SOURCE · MIT LICENSE · EARLY SCOUT RELEASE

Run Agents From One Go Binary.

Gormes is a Go-native runtime for long-running AI agents.

One static binary for the TUI, doctor, provider turns, memory, dashboard, and gateways.

No Python runtime. No virtualenv repair. No running Hermes backend.

Scout release. Useful today, still early.

Offline TUI, doctor --offline, provider one-shots, Goncho memory, dashboard, and configured Telegram/Discord/Slack gateway paths have implementation and tests.

Build from source View on GitHub
~22.0 MB static binarySource build recommendedMIT LicenseScout release

INSTALL

Build from source. Prove it offline.

The recommended trust path is boring: inspect the repository, build the binary, run the offline TUI, then run diagnostics before adding credentials. No runtime Node or npm is required.

1. BUILD FROM SOURCE

git clone https://github.com/TrebuchetDynamics/gormes-agent.git
cd gormes-agent
make build

2. OFFLINE TUI

./bin/gormes --offline

3. LOCAL DOCTOR

./bin/gormes doctor --offline

4. MEMORY AUDIT

./bin/gormes goncho doctor --json

5. MODEL-BACKED TURN

GORMES_ENDPOINT="https://your-provider.example/v1" \
GORMES_API_KEY="..." \
GORMES_MODEL="your-model" \
./bin/gormes --oneshot "hello from Gormes"

6. INSPECT INSTALLER

curl -fsSLO https://raw.githubusercontent.com/TrebuchetDynamics/gormes-agent/main/scripts/install.sh
less install.sh
sh install.sh

The installer manages a source checkout, builds gormes, and links it into your PATH. The README keeps the inspect-first path explicit. Read the installer source →

See it work in 30 seconds

Build from source, run the offline TUI, and verify your local runtime before touching a model.

git clone https://github.com/TrebuchetDynamics/gormes-agent.git
cd gormes-agent
make build
./bin/gormes --offline
./bin/gormes doctor --offline
Read the quickstart →

§ 02 · WHY GORMES

Why agent runtimes fail in production

Python-stack agents fail operationally when:

  • dev, staging, and prod stop matching
  • virtualenvs and package wheels drift across hosts
  • long turns die on dropped streams
  • tool wiring fails after tokens are already burning

How Gormes fixes the runtime surface

Single Static Binary

CGO_ENABLED=0 release builds produce a ~22.0 MB artifact. Offline TUI startup does not require Python, Node, Docker, or a Hermes process.

Source-First Install

Build the exact source tree you inspected. Convenience installers stay inspect-first from GitHub raw URLs instead of README-level pipe-to-shell snippets.

Offline Doctor

./bin/gormes doctor --offline checks local TUI, tools, Goncho, gateway configuration, and provider endpoint readiness without contacting a model provider.

Provider Turns

One-shots and the TUI use configured provider-compatible endpoints from the same runtime surface as the offline tooling.

Local Goncho Memory

Session history, durable user context, diagnostics, and queue state live in local SQLite rather than external Redis or vector sidecars.

Scout Limits Are Visible

Full Hermes parity, broad channel parity, voice/TTS, MCP/plugin parity, stable signed releases, and release hardening remain in progress.

What works today

  • Offline TUI without Python, Node, Docker, provider credentials, or Hermes
  • Provider-backed one-shots from one binary
  • Local Goncho SQLite memory and session export
  • Configured Telegram and Discord gateways; Slack with complete Socket Mode credentials
  • htmx dashboard for sessions, config, skills, and logs

§ 03 · BUILD STATE

Useful today, still early.

Current focus

  • Offline TUI, doctor diagnostics, provider-backed one-shots, and dashboard
  • Configured Telegram and Discord gateways; Slack when complete credentials are present
  • Goncho memory, Go-native tool registry, and subagent safety

Next milestone

Production-stable Go-native runtime with signed releases and broader Hermes parity

View full phase-by-phase checklist
SHIPPED · 4/4

Phase 1 — The Dashboard

  • 1.A Core TUI
  • 1.B Wire Doctor
  • 1.C Automation Reliability
  • 1.D Skill-Driven Control Plane
SHIPPED · 21/21

Phase 2 — The Gateway

  • 2.A Tool Registry
  • 2.B.1 Telegram Scout
  • 2.B.10 WeChat Adapter
  • 2.B.11 Discord Forum Channels
  • 2.B.12 Channel-Neutral Native Runtime Adapter
  • 2.B.2 Gateway Chassis + Discord
  • 2.B.3 Slack on Shared Chassis
  • 2.B.4 WhatsApp Adapter
  • 2.B.5 Session Context + Delivery Routing
  • 2.C Thin Mapping Persistence
  • 2.D Cron / Scheduled Automations
  • 2.E.0 OS-AI Spine: Deterministic Subagent Runtime
  • 2.E.1 OS-AI Spine: Delegation Policy + Child Execution
  • 2.E.2 OS-AI Spine: Concurrent-Tool Cancellation
  • 2.E.3 OS-AI Spine: Durable Job Resilience
  • 2.F.1 Slash Command Registry + Gateway Dispatch
  • 2.F.2 Hook Registry + BOOT.md
  • 2.F.3 Restart / Pairing / Status
  • 2.F.4 Home Channel + Operator Surfaces
  • 2.F.5 Gateway Mid-Run Steering + Active-Turn Policy
  • 2.G OS-AI Spine: Skills Runtime
SHIPPED · 15/15

Phase 3 — The Black Box (Memory)

  • 3.A SQLite + FTS5 Lattice
  • 3.B Ontological Graph + LLM Extractor
  • 3.C Neural Recall + Context Injection
  • 3.D Semantic Fusion + Local Embeddings
  • 3.D.5 Memory Mirror (USER.md sync)
  • 3.E.1 Session Index Mirror
  • 3.E.2 Tool Execution Audit Log
  • 3.E.3 Transcript Export Command
  • 3.E.4 Extraction State Visibility
  • 3.E.5 Insights Audit Log
  • 3.E.6 Memory Decay
  • 3.E.7 Cross-Chat Synthesis
  • 3.E.8 Session Lineage + Cross-Source Search
  • 3.F Goncho Honcho Memory Parity
  • 3.G Goncho Drop-In Compatibility Closure
IN PROGRESS · 7/13

Phase 4 — The Brain Transplant

  • 4.A Provider Adapters
  • 4.B Context Engine + Compression
  • 4.C Native Prompt Builder
  • 4.D Smart Model Routing
  • 4.E Trajectory + Insights
  • 4.F Title Generation
  • 4.G Credentials + OAuth
  • 4.H Rate / Retry / Caching
  • 4.I Native Agent Turn Closure
  • 4.J Permission-Hardened Tool Execution
  • 4.K Provider Fallback Chain
  • 4.L Safety-Anchored Turn Loop (MOSAIC)
  • 4.M Advanced Provider Routing
IN PROGRESS · 5/22

Phase 5 — The Final Purge

  • 5.A Tool Surface Port
  • 5.B Sandboxing Backends
  • 5.C Browser Automation
  • 5.D Vision + Image Generation
  • 5.E TTS / Voice / Transcription
  • 5.F Skills System (Remaining)
  • 5.G MCP Integration
  • 5.H ACP Integration
  • 5.I Plugins Architecture
  • 5.J Approval / Security Guards
  • 5.K Code Execution
  • 5.L File Ops + Patches
  • 5.M Mixture of Agents
  • 5.N Misc Operator Tools
  • 5.O Hermes CLI Parity
  • 5.P Docker / Packaging
  • 5.Q API Server + TUI Gateway Streaming
  • 5.R Code Execution Mode Policy
  • 5.S Loop Detection
  • 5.T Browser Harness Doctor
  • 5.U Fault-Tolerant Sandbox Execution
  • 5.V Unified Event Bus
IN PROGRESS · 6/12

Phase 6 — The Learning Loop (Soul)

  • 6.A Complexity Detector
  • 6.B Skill Extractor
  • 6.C Skill Storage Format
  • 6.D Skill Retrieval + Matching
  • 6.E Feedback Loop
  • 6.F Skill Surface
  • 6.G Structured Memory Types
  • 6.H Skill Metadata Placement
  • 6.I Zero-LLM Knowledge Graph
  • 6.J Agentic Memory Lifecycle (AgeMem)
  • 6.K Self-Evolution Engine (GEPA)
  • 6.L Composable Skill Execution (Voyager)
IN PROGRESS · 2/5

Phase 7 — Paused Channel Backlog

  • 7.A Signal Adapter
  • 7.B Email + SMS Adapters
  • 7.C Matrix + Mattermost Adapters
  • 7.D Webhook + Trigger Ingress
  • 7.E Regional + Device Adapter Backlog

60/92 shipped · Full progress tracker →

Explore

QuickstartInstallConfigurationArchitectureGitHub

Build it. Prove it offline. Add credentials later.

The offline path proves the runtime, diagnostics, tools, memory, and configured gateway readiness before provider calls or token spend.

Build from source Star on GitHub