armcat 2026-03-12 14:29 UTC link

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.

punkpeye 2026-03-12 14:43 UTC link

What are some things you've automated using Axe?

bensyverson 2026-03-12 14:44 UTC link

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.

Orchestrion 2026-03-12 15:29 UTC link

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.

btbuildem 2026-03-12 15:52 UTC link

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?

hamandcheese 2026-03-12 15:58 UTC link

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

swaminarayan 2026-03-12 16:02 UTC link

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

reacharavindh 2026-03-12 16:11 UTC link

Reminded me of this from my bookmarks.

https://github.com/chr15m/runprompt

boznz 2026-03-12 19:09 UTC link

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.

mccoyb 2026-03-12 19:41 UTC link

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?

Multicomp 2026-03-12 20:00 UTC link

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!

CraigJPerry 2026-03-12 23:05 UTC link

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

For example:

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

Where ai-commit-msg is a tiny agent:

    #!/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"

And you can see to keep the agents themselves tiny, they rely on a little lib to load the various skills and optionally apply some guard / post-exec validator. Those validators are usually simple grep or whatever to make sure there were no writes outside a given dir but sometimes they can be to enforce output correctness (always jq in my examples so far...). In theory the guard could be another claude -p call if i needed a semantic instruction.

uhx 2026-03-13 02:14 UTC link

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

multidude 2026-03-13 08:04 UTC link

A problem i have is that the agent's mental model of the system im building diverges from reality over time. After discussing that many times and asking it to remember, it becomes frustrating. In the README you say the agents memory persists across runs, would that solve said problem?

Also, I had to do several refactorings of my agent's constructs and found out that one of them was reinventing stuff producing a plethora of function duplications: e.g. DB connection pools(i had at least four of them simultaneously).

Would AXE require shared state between chained agents? Could it do it if required?

athrowaway3z 2026-03-13 08:15 UTC link

I'm not sure if HN is being flooded with bots or if the majority of people here nowadays lack a sense of simplicity.

Anybody looking to do interesting things should instantly ignore any project that mention "persistent memory". It speaks of scope creep or complexity obfuscation.

If a tool wants to include "persistent memory" it needs to write the 3 sentence explanation of how their scratch/notes files are piped around and what it achieves.

Not just claim "persistent memory".

I might even go so far that any project using the terminology "memory" is itself doomed to spend too much time & tokens building scaffolding for abstractions that dont work.

aa-jv 2026-03-13 08:42 UTC link

This is exactly what I have wanted for a while, so thank you very much!

Disclaimer: I haven't dug into axe enough yet, just going on first impressions.

>No daemon, no GUI.

I love the world we developers live in right now. ;)

>What would you automate first?

In a sense, I have wanted to be able to just add AI to a repo, and treat it like the junior developer it is. Its okay if the junior developer will do literally any stupid thing I tell it to do, because I won't tell it to do stupid things.

So, exactly: refactor this code, implement a shim, produce docs for <blah>, construct a build harness, write unit tests, produce a build, diff these codebases, implement this API, do all this on your own branch, and build and test things so that I can review the PR over coffee.

Essentially, three word commands which will encourage the AI to produce better software. Through my repo, so I can just review through the repo.

Okay, that's how I hope things work, now off to actually dig in to axe and give it a try on a few things, thanks very much again ..

ColonelPhantom 2026-03-13 09:26 UTC link

I like the idea of LLM-calling as an automation-friendly CLI tool! However, putting all my agents in ~/.config feels antithetical to this. My Bash scripts do not live there either, but rather in a separate script collection, or preferably, at their place of use (e.g. in a repo).

For example, let's say I want to add commit message generation (which I don't think is a great use of LLMs, but it is a practical example) to a repo. I would add the appropriate hook to /.git, but I would also want the agent with its instructions to live inside the repo (perhaps in an `axe` or `agents` directory).

Can Axe load agents from the current folder? Or can that be added?

bsoles 2026-03-13 10:51 UTC link

I don't know exactly how these things work, but you may run into copyright/TM issues with Deque's Axe tool: https://www.deque.com/axe/devtools/

kwstx 2026-03-14 14:03 UTC link

Really cool approach, I like the “Unix philosophy” for agents. Curious how you handle state persistence and chaining sub-agents when agents are depth-limited. Also, do you have any strategies for ensuring data consistency across runs, especially when multiple agents interact with the same files?

spranab 2026-03-16 00:27 UTC link

Ran jrswab/axe through IdeaCred (automated repo scorer) — 85/100, strongest in undefined.

Free badge/profile: https://ideacred.com/profile/jrswab

jrswab 2026-03-12 15:03 UTC link

> how you would approach budget when using Axe

Great question and it's something that I've not dig into yet. But I see no problem adding a way to limit LLMs by tokens or something similar to keep the cost for the user within reason.

jrswab 2026-03-12 15:06 UTC link

Thanks for checking it out! And yes the tool is indeed catering to that crowed. It's a need I have and thought others could use it as well.

jrswab 2026-03-12 15:26 UTC link

I have a few flows I'm using it for and have a growing list of things I want to automate. Basically, if there is a process that takes a human to do (like creating drafts or running scripts with variable data) I make axe do it.

1. I have a flow where I pass in a youtube video and the first agent calls an api to get the transcript, the second converts that transcript into a blog-like post, and the third uploads that blog-like post to instapaper.

2. Blog post drafting: I talk into my phone's notes app which gets synced via syncthing. The first agent takes that text and looks for notes in my note system for related information, than passes my raw text and notes into the next to draft a blog post, a third agent takes out all the em dashes because I'm tired of taking them out. Once that's all done then I read and edit it to be exactly what I want.

jrswab 2026-03-12 15:48 UTC link

> Curious if you’ve experimented with workflows where agents produce artifacts (files, reports, etc.) rather than just returning text.

Yes! I run a ghost blog (a blog that does not use my name) and have axe produce artifacts. The flow is: I send the first agent a text file of my brain dump (normally spoken) which it then searched my note system for related notes, saves it to a file, then passes everything to agent 2 which make that dump a blog draft and saves it to a file, agent 3 then takes that blog draft and cleans it up to how I like it and saves it. from that point I have to take it to publish after reading and making edits myself.

hiccuphippo 2026-03-12 16:05 UTC link

Clankers are not humans.

jrswab 2026-03-12 16:08 UTC link

That's my dream.

jrswab 2026-03-12 16:09 UTC link

I've shared a few flows I use a lot right now in some other comments.

Zondartul 2026-03-12 18:35 UTC link

It is easier to trust in the correctness and reliability of an LLM when you treat it as a glorified NLP function with a very narrow scope and limited responsibilities. That is to say, LLMs rarely mess up specific low level instructions, compared to open-ended, long-horizon tasks.

ipython 2026-03-12 19:48 UTC link

it's written in golang. 12MB barely gets you "hello world" since everything is statically linked. With that in mind, the size is impressive.

nine_k 2026-03-12 21:13 UTC link

12 MB is not large; it's like 3 minutes of watching YouTube. Actual RAM consumption is only very weakly correlated to the binary size, and that's what matters.

jrswab 2026-03-12 21:32 UTC link

Love to hear it! Thanks for checking it out and feel free to put up an issue on GitHub if you have any ideas for improvements.

jrswab 2026-03-12 21:34 UTC link

I'm excited to see how this plays out. Keep me updated on x(twitter)

avoutic 2026-03-13 02:15 UTC link

I was looking at something similar. What does your agent-lib.sh look like?

avoutic 2026-03-13 02:16 UTC link

Where is the nanobot approach not working for you?

linkregister 2026-03-13 03:55 UTC link

chroot

lionkor 2026-03-13 07:33 UTC link

Do you have examples of these commit messages? I have yet to see an AI write a good commit message. At least when compared to good commit messages -- if it just does better than "wip" or "fix stuff" that's not a high bar.

aa-jv 2026-03-13 08:44 UTC link

>scaffolding

The purpose of scaffolding is to create persistent memories.

>claim "persistent memory"

Just look at it as a build product.

>abstractions that don't work

Look at this as a testing problem.

Editorial Channel

What the content says

Structural Channel

What the site does