I Open-Sourced My AI Agent Platform

Today I released Goated, an always-on AI agent platform I've been building as a side project. It's MIT-licensed, written in Go, and it runs on top of Claude Code or Codex instead of trying to replace them. What started as a personal tool has started catching on at work too.

This post is about why I built it, what I learned, and why I think the "thin orchestrator" pattern is the right architecture for long-running AI agents.

The OpenClaw Problem

I started 2026 running OpenClaw, like a lot of people did. OpenClaw went viral in January — 247,000 GitHub stars, Peter Steinberger on the cover of Fast Company, the whole thing. It was genuinely impressive software.

I wasn't a casual user. Alan Botts — my agent — was one of the most sophisticated agents running on OpenClaw. Custom Go tooling, a massive Obsidian-style vault, over 150K documents indexed in Turbopuffer, cron jobs, subagent spawning, the works. But the deeper I went, the more I ran into problems that weren't bugs — they were architectural limits. Reliability issues. Speed. Ergonomic nightmares like memory drift, permanently losing SSH keys and session context during compaction, and token costs that scaled with session age instead of staying flat.

But if you ran it in production — really ran it, 24/7, with cron jobs and subagents and a Slack integration that never sleeps — you hit the wall fast.

The core issue is architectural. OpenClaw owns the context window. It injects bootstrap files, manages session history, and accumulates state in-process. Every API request carries 3K-14K tokens of force-injected context. Session history gets reprocessed on every turn. Tool outputs get stored permanently in .jsonl files and dragged forward indefinitely.

The result: 1.9 GB of RAM after 13 hours. 28 GB by day three. Token bills that made me wince. And a daemon that needed babysitting like a newborn.

I tried patching it. Wrote custom compaction logic. Added memory caps. Ran session file pruning crons. But you can't optimize your way out of an architecture that fundamentally wants to own everything.

The Insight

The realization was simple, almost embarrassingly so: the best way to manage the context window is to not manage it at all.

Claude Code already has context compaction. It already manages its own memory. It already handles token budgeting. Why was I rebuilding all of that in a Node.js wrapper that's worse at it?

What if the agent framework was just... a message router? What if it received a Slack message, wrapped it in a tiny envelope, pasted it into tmux, and got out of the way?

What I Built

Goated is a ~20 MB Go daemon that does exactly that. It:

  • Receives messages from Slack or Telegram
  • Wraps them in a ~200 character pydict envelope (a Python dict literal with the message, source, chat ID, and a command for sending replies)
  • Pastes the envelope into a tmux session running Claude Code (or Codex)
  • Lets the runtime handle everything else

That's it. No token injection. No session history management. No context pipeline. The agent runtime manages its own context, compaction, memory, and tools — because it's already better at that than anything I could build.

The daemon itself is a cron runner, a message queue, a health checker, and a subagent launcher. It opens the database per-operation and closes it immediately. It holds almost nothing in memory. After 11 days of continuous operation — hundreds of cron jobs, dozens of subagent spawns, thousands of messages — it sits at 20 MB RSS and 0% CPU.

For comparison, OpenClaw was at 28 GB and 70% CPU after three days doing the same workload.

What's in the Box

Goated ships with:

  • Slack and Telegram connectors with attachment support
  • Claude Code and Codex in both interactive (tmux) and headless modes
  • Cron jobs with timezone support, deduplication, and two types: subagent (spawns a headless agent) and system (runs a shell command)
  • Subagent launcher with completion tracking and main-session notification
  • File-backed credentials with automatic log redaction
  • Session health checks with auto-restart and graceful drain
  • Auto-compaction that monitors context usage and compacts before the window fills
  • A bootstrapper that initializes a private workspace/self/ repo where the agent keeps its identity, memory, tools, missions, and knowledge vault

The workspace/self/ pattern is one of my favorite decisions. Every Goated agent has a private Git repository where it stores everything that makes it it — personality, memory, tools, cron prompts, credentials. The platform doesn't touch this data. It just provides the infrastructure for the agent to manage itself.

The Architecture in One Sentence

Goated is a thin orchestrator that routes messages, runs crons, and manages health — then gets out of the way and lets Claude Code be Claude Code.

I think this is the right pattern for the current moment. Models and runtimes are improving fast. Any framework that tries to own the context window is building on sand — the compaction logic you write today will be obsolete when the next model ships with a bigger window or better native memory. But a message router that delegates to the best available runtime? That just keeps working.

Try It

git clone https://github.com/endgame-labs/goated.git
cd goated
./bootstrap.sh

MIT license. Two Go binaries. One goated.json config file. Full docs on GitHub.

I've been running it in production for a month — deal prep, daily digests, competitive Minecraft farming.

If you're tired of babysitting your agent framework, give it a shot.