Show HN: Axe – A 12MB binary that replaces your AI framework
https://github.com/jrswab/axeOP, what have you used this on in practice, with success?
One thing I’ve noticed when experimenting with agent pipelines is that the “single-purpose agent” model tends to make both cost control and reasoning easier. Each agent only gets the context it actually needs, which keeps prompts small and behavior easier to predict.
Where it gets interesting is when the pipeline starts producing artifacts instead of just text — reports, logs, generated files, etc. At that point the workflow starts looking less like a chat session and more like a series of composable steps producing intermediate outputs.
That’s where the Unix analogy feels particularly strong: small tools, small contexts, and explicit data flowing between steps.
Curious if you’ve experimented with workflows where agents produce artifacts (files, reports, etc.) rather than just returning text.
It looks like Axe works the same way: fire off a request and later look at the results.
how would you say this compares to similar tools like google’s dotprompt? https://google.github.io/dotprompt/getting-started/
Most frameworks want a long-lived session with a massive context window doing everything at once. That's expensive, slow, and fragile. Good software is small, focused, and composable... AI agents should be too.
Axe treats LLM agents like Unix programs. Each agent is a TOML config with a focused job. Such as code reviewer, log analyzer, commit message writer. You can run them from the CLI, pipe data in, get results out. You can use pipes to chain them together. Or trigger from cron, git hooks, CI.
What Axe is:
- 12MB binary, two dependencies. no framework, no Python, no Docker (unless you want it)
- Stdin piping, something like `git diff | axe run reviewer` just works
- Sub-agent delegation. Where agents call other agents via tool use, depth-limited
- Persistent memory. If you want, agents can remember across runs without you managing state
- MCP support. Axe can connect any MCP server to your agents
- Built-in tools. Such as web_search and url_fetch out of the box
- Multi-provider. Bring what you love to use.. Anthropic, OpenAI, Ollama, or anything in models.dev format
- Path-sandboxed file ops. Keeps agents locked to a working directory
Written in Go. No daemon, no GUI.
What would you automate first?
That said, composability introduces its own attack surface. When agents chain together via pipes or tool calls, each handoff is a trust boundary. A compromised upstream output becomes a prompt injection vector for the next agent in the chain.
This is one of the patterns we stress-test at audn.ai (https://audn.ai) — we do adversarial testing of AI agents and MCP tool chains. The depth-limited sub-agent delegation you mention is exactly the kind of structure where multi-step drift and argument injection can cause real damage. A malicious intermediate output can poison a downstream agent's context in ways that are really hard to audit after the fact.
The small binary / minimal deps approach is great for reducing supply chain risk. Have you thought about trust boundaries between agents when piping? Would be curious whether there's a signing or validation layer planned between agent handoffs.