OPEN SOURCE · MIT LICENSE · AUTONOMOUSLY PORTED FROM HERMES

AI agent runtime in one Go binary.

Drop-in compatible with the Hermes agent ecosystem — skills, providers, memory, and gateways — without a Python runtime, virtualenv, or backend service.

Built by TrebuchetDynamics' autonomous engineering loop, which ports upstream Hermes daily under TDD discipline.

Choose source build or install.sh, prove the machine offline, then add provider and gateway credentials.

Scout release.

Offline TUI, onboarding, provider turns, local SQLite memory, dashboard, and Telegram/Discord/Slack gateway paths are available now. Release signing, voice/TTS, and full Hermes parity are still hardening.

Choose an install path See how it is built
Source build recommended install.sh available Current scout release: v0.1.06 Static Go binary MIT License Offline doctor before credentials Autonomous porting loop ships daily

HOW IT IS BUILT

An autonomous engineering loop ports Hermes to Go, every day.

Gormes is the artifact TrebuchetDynamics' agentic engineering system produces. A planner → builder → TDD-slice loop runs against upstream Hermes around the clock, lands one bounded vertical slice at a time, and only commits when go test, progress validate, and git diff --check are all green. The methodology is the differentiator; Hermes-parity is the receipt that proves it works.

Loop output, measured today

770+

Validated rows shipped

Each carries a contract, fixtures, and acceptance evidence.

749 Go files · 186k lines · 4620 tests

Code base

Static binary, zero CGO, no dynamic library deps.

~27.1 MB

Binary

Linux/amd64, linux/arm64, darwin/amd64, darwin/arm64 today.

Validation-gated commits

Every loop commit must pass go test ./..., go run ./cmd/progress validate, and git diff --check before landing on development. No silent failures, no skipped hooks.

progress.json as system of record

A schema-validated, contract-typed plan tracks every bounded slice. The loop selects the next builder-ready row; nothing else. No side queues, no private TODOs.

Hermes is the parity oracle

Upstream Hermes is the Python reference. The loop sweeps each release for behavior gaps, classifies them, and turns them into TDD slices the builder can finish.

Reusable porting toolkit

The skill set behind the loop (planner, builder, tdd-slice, parity-auditor, references, skill-manager) is generic Python-to-Go porting infrastructure. Open-source extraction is on the Q2 roadmap.

Read how the loop works ->

INSTALL

Two install paths. One gormes command.

Build from source when you want maximum inspection. Use install.sh when you want a source-backed managed install that publishes the stable gormes command. Both paths keep the first proof offline. No runtime Node or npm is needed to open the native UI.

METHOD 1 · BUILD FROM SOURCE

git clone https://github.com/TrebuchetDynamics/gormes-agent.git
cd gormes-agent
make build
export PATH="$PWD/bin:$PATH"
gormes doctor --offline
gormes --offline

METHOD 2 · INSTALL.SH

curl -fsSLO https://gormes.ai/install.sh
less install.sh
sh install.sh
gormes doctor --offline

Both paths end at the same gormes command. install.sh also runs gormes setup when a terminal is available. Read the install docs ->

After offline proof

Add a provider

gormes setup provider

Configure endpoint credentials only after the local doctor and offline TUI prove the machine.

Smoke-test a turn

gormes --oneshot "hello"

Run a single provider turn before starting longer local sessions or gateways.

Check gateway state

gormes gateway status

Promote Telegram, Discord, or Slack only after the configured channel reports clean status.

Who this is for

For

Developers and operators who want local, inspectable agent infrastructure that survives restarts, bad networks, and dependency drift — and engineering teams curious how an autonomous loop ships parity work daily.

Not for yet

Teams that require signed enterprise releases, full Hermes parity, voice/TTS, or broad channel parity today.

Trust posture

  • Source build and inspectable install.sh are the two promoted scout-release paths.
  • Offline doctor runs before provider credentials or token spend.
  • Secrets stay local under the Gormes home, not in the landing workflow.
  • install.sh clones or updates a managed source checkout, builds gormes, verifies the command, and can hand off to setup.
  • Tagged artifacts carry checksums; release signing and package-manager hardening are still in progress.
  • Every autonomous-loop commit passes a validation gate (go test, progress validate, git diff --check) before landing.
  • Current measured Linux build: ~27.1 MB (2026-05-07)
  • Progress and benchmark data sync from repo sources during every landing build.

What works today

  • Run a local agent UI with zero runtime dependencies on the offline path
  • Send one-shot prompts to a provider-compatible endpoint
  • Validate your environment before spending tokens
  • Run onboard/setup flows that surface config, providers, skills, agents, and channel bindings
  • Operate Telegram, Discord, and Slack paths from one binary when configured
  • Inspect and debug local SQLite memory ("Goncho")
  • Browse sessions, config, skills, logs, and audits from local operator surfaces

Gateway support status

Runtime-ready

Telegram, Discord, and Slack.

In roadmap validation

WhatsApp, WeChat, Signal, Matrix, and Mattermost.

WHY GORMES

Python-stack agents fail for boring reasons.

The model is not usually the fragile part. Operations are:

  • 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

Gormes cuts out that failure class

Single Binary Runtime

Static Go builds keep the runtime surface in one binary with no Python runtime dependency.

Offline Proof

gormes --offline starts the native TUI without credentials, network calls, Python, Node, Docker, or Hermes.

Built-In Doctor

gormes doctor --offline checks local readiness before provider calls or token spend.

Provider Turns

One-shots and the TUI use configured provider-compatible endpoints from the same binary.

Local SQLite Memory

Sessions, durable context, diagnostics, and queue state stay in local SQLite.

Visible Limits

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

CURRENT STATE

Core runtime shipped. Production hardening and broader parity are in progress.

Shipped in scout

  • Offline TUI and doctor
  • Source-backed install.sh and setup handoff
  • Onboard/setup flows
  • Provider one-shots
  • Local SQLite memory and sessions
  • Dashboard inspection
  • Logs, security audit, and secrets audit
  • Telegram, Discord, and Slack configured paths

Hardening now

  • Provider routing and auth edges
  • Learning loop and operator feedback paths
  • Tool safety and sandboxing
  • Browser/web tools
  • Release checksums, signing, and package-manager lanes

Later

  • Voice/TTS parity
  • Broad channel parity
  • Plugin/MCP parity
  • Enterprise release polish

Next milestone

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

View full roadmap ->

Explore

Quickstart Install Configuration Architecture GitHub

Prove the runtime locally before you ever spend a token.

Build from source or inspect install.sh, run the offline doctor, then add credentials only after the machine has proven itself.

Pick an install path Star on GitHub