Hi everyone, I built Axe because I got tired of the "everything is a chatbot" pattern in AI tooling.
Axe treats LLM agents like Unix programs. Each agent is a TOML config with a focused job such as a code reviewer, a log analyzer, or a commit message writer. You run them from the CLI, pipe data in, get results out. Chain them together. Trigger them from cron, git hooks, CI.
Whatever you already use.
Some things that make it different:
- No framework lock-in: it's a single binary with two dependencies
- Stdin piping: `git diff | axe run reviewer` just works
- Sub-agent delegation: agents can call other agents via tool use
- Persistent memory: agents remember across runs without you managing state (if you need)
- Path-sandboxed tools: file ops are locked to the agent's working directory
Written in Go because I wanted fast cold starts and easy distribution. No daemon or GUI.
This is early stage to solve a need I have. I would love feedback on the agent config format and the skill system.
What's missing? What would make you actually use this?
jrswab•57m ago
Axe treats LLM agents like Unix programs. Each agent is a TOML config with a focused job such as a code reviewer, a log analyzer, or a commit message writer. You run them from the CLI, pipe data in, get results out. Chain them together. Trigger them from cron, git hooks, CI.
Whatever you already use.
Some things that make it different:
- No framework lock-in: it's a single binary with two dependencies
- Stdin piping: `git diff | axe run reviewer` just works
- Sub-agent delegation: agents can call other agents via tool use
- Persistent memory: agents remember across runs without you managing state (if you need)
- Path-sandboxed tools: file ops are locked to the agent's working directory
Written in Go because I wanted fast cold starts and easy distribution. No daemon or GUI.
This is early stage to solve a need I have. I would love feedback on the agent config format and the skill system.
What's missing? What would make you actually use this?