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.

https://github.com/chr15m/runprompt

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.

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

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/

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.

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