How EONYX Works: The Agent Architecture from the Inside
EONYX is written in Go.
It builds into a single static binary.
Inside sits a small set of packages around one central abstraction.
Here is how it fits together.
███████╗ ██████╗ ███╗ ██╗██╗ ██╗██╗ ██╗ ██╔════╝██╔═══██╗████╗ ██║╚██╗ ██╔╝╚██╗██╔╝ █████╗ ██║ ██║██╔██╗ ██║ ╚████╔╝ ╚███╔╝ ██╔══╝ ██║ ██║██║╚██╗██║ ╚██╔╝ ██╔██╗ ███████╗╚██████╔╝██║ ╚████║ ██║ ██╔╝ ██╗ ╚══════╝ ╚═════╝ ╚═╝ ╚═══╝ ╚═╝ ╚═╝ ╚═╝
EONYX is written in Go.
It builds into a single static binary.
Inside sits a small set of packages around one central abstraction.
Here is how it fits together.
Hooks are shell commands that run around a tool call.
One before it, one after it.
They bolt on formatting, auditing and guardrails without touching the agent’s code.
An agent reads code, edits it and runs commands.
So it has to stay inside explicit permissions.
EONYX stacks several layers: a static gateway, a file sandbox, plan mode and a hard block on dangerous commands.
The main way to work with EONYX is the terminal interface.
Streaming answers, a command palette, pickers and dialogs.
Here is everything worth knowing to move fast.
A subagent is a separate instance of the agent.
EONYX hands it a slice of the work.
It runs in its own context window, with a reduced tool set, and returns only the result.
So the main conversation stays clean: the research never clutters it.
EONYX also runs headless: it does the task and exits.
That is what scripts, pipes and CI need.
Predictable output, JSON events, meaningful exit codes.
Features are nice.
Seeing them work is better.
A few practical scenarios: how to phrase the task, and which technique to switch on.
The prompts are deliberately plain.