I built Axe because I got tired of every AI tool trying to be a chatbot.

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?

> - Path-sandboxed file ops. Keeps agents locked to a working directory

How is it supposed to work, if agent can simply run "cat" command instead of using skill for file read/write/etc?

This is a great concept. I fully agree with small, focused and composable design. I've been exploring a similar direction at asterai.io but focusing more on the tool layer than agent layer, with portable WASM components you write once in any language and compose together.

I currently use Claude web with an MCP component for my workflows but axe looks like it could be a nicer and quicker way to work with the tools I have.

I've had good success with something along these lines but perhaps a bit more raw:

    - claude takes a -p option
    - i have a bunch of tiny scripts, each script is an agent but it only does one tiny task
    - scripts can be composed in a unix pipeline

    $ git diff --staged | ai-commit-msg | git commit -F -

    #!/usr/bin/env bash
    # ai-commit-msg: stdin=git diff, stdout=conventional commit message
    # Usage: git diff --staged | ai-commit-msg
    set -euo pipefail
    source "${AGENTS_DIR:-$HOME/.agents}/lib/agent-lib.sh"
    
    SYSTEM=$(load_skills \
        core/unix-output.md \
        core/be-concise.md \
        domain/git.md \
        output/plain-text.md)
    
    SYSTEM+=$'\n\nTask: Given a git diff on stdin, output a single conventional commit message. One line only.'
    
    run_agent "$SYSTEM"

It's exciting to see so much experimentation when it comes to form factors for agent orchestration!

The first question that comes to mind is: how do you think about cost control? Putting a ton in a giant context window is expensive, but unintentionally fanning out 10 agents with a slightly smaller context window is even more expensive. The answer might be "well, don't do that," and that certainly maps to the UNIX analogy, where you're given powerful and possibly destructive tools, and it's up to you to construct the workflow carefully. But I'm curious how you would approach budget when using Axe.

The Unix analogy is really interesting, but one thing I always run into with agent pipelines is failure propagation.

In a traditional Unix pipeline, each stage is deterministic and errors are easy to reason about: exit codes, stderr, etc. But once an LLM sits in the middle, a stage can partially succeed, hallucinate, or silently change the structure of the output.

In practice this turns a simple pipe into something closer to a dataflow system where every stage needs some kind of validation layer.

Have you experimented with guard/validator steps between agents (e.g. schema checks, structured outputs, retry logic)? Without that the Unix model feels elegant but a bit fragile once the pipeline grows beyond a few steps.

Why not just run your typical claude/codex/pi/etc with a prompt as the command line/input?

> 12MB binary, two dependencies. no framework, no Python, no Docker (unless you want it)

Does it do anything CPU-bound on its own, such that it benefits significantly from being a compiled (Go) executable? I actually like having things like this done in Python, since there's more potential to hack around with them.

This is what I've been trying to get nanobot to do, so thanks for sharing this. I plan to use this for workflow definitions like filesystems.

I have a known workflow to create an RPG character with steps, lets automate some of the boilerplate by having a succession of LLMs read my preferences about each step and apply their particular pieces of data to that step of the workflow, outputting their result to successive subdirectories, so I can pub/sub the entire process and make edits to intermediate files to tweak results as I desire.

Now that's cool!

I really like this idea. Gonna need an "Awesome Axe" page that collects agents.

One idea I'm thinking of is, after an agent has been in use for a while, and built up and understanding of the task, would be something like, "Write a Python script to replace this agent."

I could imagine this would work with agents that are processing log files or other semi-structured data for example.

Cool work!

Aside but 12 MB is ... large ... for such a thing. For reference, an entire HTTP (including crypto, TLS) stack with LLM API calls in Zig would net you a binary ~400 KB on ReleaseSmall (statically linked).

You can implement an entire language, compiler, and a VM in another 500 KB (or less!)

I don't think 12 MB is an impressive badge here?

Reminded me of this from my bookmarks.

https://github.com/chr15m/runprompt

Nice! I’ll try this soon, and I’m afraid I’ll end up using it a lot.

@jrswab, do you think it would be feasible to limit outgoing connections to a whitelist of domains, URLs, or IP addresses?

I’d like to automate some of my email, calendar, or timesheet tasks, but I’m concerned that a prompt injection could end up exfiltrating or deleting data. In fact, that’s the main reason why I’m not using Openclaw or similar projects with real data yet.

> 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.

I'm a bit skeptical of this approach, at least for building general purpose coding agents. If the agents were humans, it would be absolutely insane to assign such fine-grained responsibilities to multiple people and ask them to collaborate.

This is interesting. I'd be curious to see a bunch more working examples. Personally I like the chat model because I iterate heavily on planning specs and have a lot of back and forth before implementation.

I could see using this once the plan is defined and switching back to chat while iterating on post-implementation cleanup and refactoring.

Great work! Kind of reminds me of ell (https://github.com/MadcowD/ell), which had this concept of treating prompts as small individual programs and you can pipe them together. Not sure if that particular tool is being maintained anymore, but your Axe tool caters to that audience of small short-lived composable AI agents.

Axe treats LLM agents like Unix programs—small, composable, version-controllable. Are we finally doing AI the Unix way?

I will give it a try, I like the idea of being closer to the metal.

A Proper self-contained, self improving AI@home with the AI as the OS is my end goal, I have a nice high spec but older laptop I am currently using as a sacrificial pawn experimenting with this, but there is a big gap in my knowledge and I'm still working through GPT2 level stuff, also resources are tight when you're retired. I guess someone will get there this year the way things are going, but I'm happy to have fun until then.

looks really cool, how does it differ from something like running claude headless with `claude -p`?

I really like seeing the movement away from MCP across the various projects. Here the composition of the new with the old (the ol' unix composability) seems to um very nicely.

OP, what have you used this on in practice, with success?

“ MCP support. Axe can connect any MCP server to your agents”

I just don't see this in the readme… It is not in the Features section at least.

Anyway, i have MCP server that can post inline comments into Gitlab MR. Would like to try to hook it up to the code reviewer.

What are some things you've automated using Axe?

If I have time I want to try this today because it matches my LLM-based work style, especially when I am using local models: I have command line tools that help me generated large one-shot prompts that I just paste into an Ollama repl - then I check back in a while.

It looks like Axe works the same way: fire off a request and later look at the results.

Nice. There's another one also written in Go (https://github.com/tbckr/sgpt), but i'll try this one too. I love that open source creates multiple solutions and you can choose the one that fits you best

The Unix-style framing resonates a lot.

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.

This looks really interesting. I'm curious to learn more about security around this project. There's a small section, but I wonder if there's more to be aware of like prompt injection

Now what we need is a chat interface to develop these config files.

Does it support the use of other OpenAI API compatible services like Openrouter?

looks interesting, I agree that chat is not always the right interface for agents, and a LLM boosted cli sometimes feels like the right paradigm (especially for dev related tasks).

how would you say this compares to similar tools like google’s dotprompt? https://google.github.io/dotprompt/getting-started/

I really like the project, although I would prefer a json5 config, not toml, which I find annoying to reason about.

There is no "session" concept?

Is the axe drawing actually a hammer?

I’m having trouble understanding when/where I would use this? Is this a replacement for pi or codex?

Is there Gemini support?

Looks pretty interesting!

Tiny note: there's a typo in your repo description.

amazing work my friend

Why is this comment an ad?

12MB for an "AI framework replacement"? That's either brilliant compression or someone's redefining "framework" to mean "toy model that works on my laptop." Show me the benchmarks on actual workloads, not the readme poetry.