Skip to content

Open source · self-hosted · written in Go

A multi-agent AI runtime that runs on your own machine.

One binary. No database, no container, no API key. TionHarness gives a team of autonomous agents a workspace, a board, a scheduler and a permission model — then gets out of the way.

Download Build from source

unreleased · Windows, Linux, macOS · 12 MB

SES103 · coordinator depth 1 / 5
  • SES104 map the auth surface done
  • SES105 rewrite token refresh running
  • SES106 typecheck + e2e queued

<task-notification> SES104 returned · 2 workers still running

12 MB single binary
Web UI embedded with go:embed. Nothing else to install.
0 databases
Entities are JSON, sessions are JSONL. Back up by copying a folder.
0 API keys required
Runs through your local claude-cli / codex-cli login.
7 provider kinds
claude-cli, codex-cli, anthropic, minimax, deepseek, openrouter, zai.

Installation

No compose file. No migration step.

Storage is the filesystem: entities are JSON, sessions are append-only JSONL. Backing up means copying a folder.

The usual agent platform 
services:
  api:
    image: platform/api:latest
    depends_on: [db, redis, vector]
  worker:
    image: platform/worker:latest
  db:
    image: postgres:16
    volumes: [pgdata:/var/lib/postgresql/data]
  redis:
    image: redis:7
  vector:
    image: qdrant/qdrant
volumes:
  pgdata:
# ... then migrations, then .env, then keys
TionHarness 
.\tionharness.exe
  • The React UI is embedded in the binary with go:embed
  • State lives in one data folder you can zip, diff or version
  • A desktop build opens in its own WebView2 window, no browser needed

Capabilities

Everything an agent needs to keep working without you

Not a chat wrapper. A runtime with scheduling, orchestration, permissions and its own management API.

Agents with an identity

Each agent carries its own soul prompt, provider instance, model and thinking level -- from off all the way to max.

Coordinator and workers

An agent can spawn a tree of workers, stream their results back as notifications, and synthesise the answer itself.

Evolving flows

Every agent has one main flow its turns run through. Insert a critic loop or a planning stage on the canvas, let the agent edit it with tools, or let the observer propose changes from real runs.

Board-driven execution

A kanban card moving into a column is a trigger: rules spawn agents or archive cards without an LLM in the loop.

Physical workspace isolation

Every workspace gets its own store, runtime, scheduler and theme. Nothing leaks across the boundary.

Tools and MCP

Built-in file and shell tools plus external MCP servers over stdio or streamable HTTP, with lazy loading so the catalogue stays cheap.

Permission layer

Tools are risk-classified and gated by auto, ask or read-only modes, with argument patterns like Bash(git *) and a full audit trail.

Self-management

Agents create their own schedules, automations, skills and secrets and evolve their own flow and prompts through tools -- the app is its own API surface.

Retrospective insight

Editable lenses scan past sessions for wasted spend and broken habits, then file findings as app fixes or workspace tweaks.

Multi-agent

One agent, a whole team behind it

Turn on coordinator mode and an agent stops doing the work itself. It spawns workers, hands each a scoped profile, and stitches the results together.

  • Profiles: explore, edit, validator and a read-only planner
  • Unbounded depth, with guards at 5 levels and 64 subtree members
  • Oversized worker output is written as an artifact and passed by handle

Coordinator session with several workers running in parallel

/shots/coordinator.png — run scripts\shots.ps1

Orchestration

Flows that evolve with every turn

Each agent owns one versioned flow: input, a few model / route / transform stages, output. A route can loop back for a second draft, every loop is bounded in code, and every change is a version you can revert.

  • Edit on the canvas, or let the agent edit itself with edit_flow and update_my_prompt
  • A Flow Observer reads the last runs and proposes one measured change (propose or auto policy)
  • One run per turn with the per-stage trace, live in the chat and on the canvas

Flow builder canvas with a branching multi-agent graph

/shots/flows.png — run scripts\shots.ps1

Automation

The board is the source of execution

Tags, board moves, cumulative token spend and message counters are all triggers. Each one spawns a session whose agent runs its own evolving flow.

  • Four trigger kinds: label, board, token threshold, activity counter
  • Token triggers reuse one persistent maintenance session instead of spawning forever
  • Every workspace ships two default rules, seeded disabled

Kanban board with automation rules

/shots/board.png — run scripts\shots.ps1

Appearance

Six palettes, light and dark, applied live

Themes are pure CSS custom properties, so a workspace can carry its own look and switching one repaints the whole app instantly.

Research agent claude-cli
Indexed 412 files and found three call sites that bypass the token refresh.
Fix them and run the validator.
⚡ 3 parallel tool calls

Quickstart

Clone, build, run

Prebuilt binaries are not published yet, so the path below builds one from source. It takes about a minute.

powershell 
# Prerequisites: Go 1.26.4+, Node 20.19+ (20.x) or 22.12+, and a configured provider.
git clone <REPO_URL> tionharness
cd tionharness

# Builds the UI into internal/web/dist, then embeds it into one exe.
.\scripts\build.ps1

$env:TIONHARNESS_ADDR="127.0.0.1:8095"
.\tionharness.exe            # open http://127.0.0.1:8095

Working on TionHarness itself? One script starts the backend and Vite together:

powershell 
# One command for backend + frontend with hot reload
.\scripts\dev.ps1              # LAN-visible, opens the browser
.\scripts\dev.ps1 -Loopback    # 127.0.0.1 only, no firewall prompt

Download

Get the binary

One file, no installer, no runtime. Unzip it and run it.

Download Coming soon

Builds are not published yet. Until then, build from source — it is one go build.

Read this first

What TionHarness is not

It is easier to trust a tool that tells you where its edges are.

TionHarness is built to run beside you, on hardware you control. That is why it trusts its caller completely -- and why the caller has to be you.

Not a hosted SaaS

There is no account, no tenant, no billing. You run the binary; your data never leaves the machine it runs on.

No authentication layer

The HTTP API has no auth and CORS is wide open. Bind it to loopback or a Tailscale address. Never expose it to the public internet.

Not a sandbox

File and shell tools reach the whole filesystem by design. The permission mode -- auto, ask, read-only -- is the only guardrail, so pick it deliberately.

Not a model provider

It orchestrates models you already have access to. Bring your own claude-cli login or an API key for one of the supported providers.