Architecture: Seven Tools, One Ecosystem
When we started building Hawk, the obvious path was to ship seven separate CLIs. One agent, one LLM runtime, one token counter, and so on. That's how everyone else does it.
We chose differently. Here's why, and how.
The shared context problem
AI coding tools are only as good as the context they have. A debugger that doesn't know what your agent just wrote is starting from scratch. A code reviewer that can't see your session history misses half the story.
We needed shared context without shared state. Each tool runs independently, but they can all read from the same context layer.
The architecture
Hawk is a single Go binary with a plugin-style internal architecture:
- A core runtime handles CLI parsing, config, and the context layer
- Each tool registers as a module with its own commands and capabilities
- The context layer provides read access to shared state (codebase index, session memory, recent changes)
- Each tool writes only to its own namespace
This means Trace can see what Hawk just wrote, Tok can measure the context that Yaad is managing, and Sight can review changes from any tool — all without coupling.
Why Go?
Single binary distribution. Cross-platform compilation. Fast startup times. No runtime dependencies.
The target experience: install Hawk and start in under 30 seconds. Container-first by default — Docker sandbox with no permission prompts. We're building toward that; public install is not available yet.
Trade-offs
This architecture means we ship everything together. You can't install just Trace without the rest. We think that's the right trade-off — the tools are small, the binary is ~15MB total, and the shared context is the whole point.
What's next
We're working on a plugin API so the community can add new tools to the Hawk ecosystem. Same shared context, same single binary, but extensible.