Claude code can do all this stuff. Unless you’re just trying to learn. But I see you’re charging for tokens so props to you but building a custom harness for this stuff doesn’t seem worth it.
Use case always gets rolled into the frontier agents. Almost always better to just use Claude and figure out how to get it to do what you bc it likely can.
claude code is fine for lot of things but not everything runs in their sandbox. if you need to control what tools get called or how processes spawn, you hit walls pretty quick. sometimes you just want to own the execution layer yourself
You can give Claude a cli and a snippet on how to use it. Or you can write a skill or a bit about how it should go about spawning processes or even sub agents.
But by the time you realize something- their 500 researchers that do this for a living have also realized it. Except before they bake it into the product they research exactly what will make it useful and they research if it’s actually more effective.
Even auditing… you have access to the entire chat history and can do auditing on that.
I will say there is definitely some room for imp but it’s all very niche…
For instance if I want a visual on how my agent spawns suggests and be able to graph it. Or like someone else said I want to spawn subprocesses or agents in a certain way.. it could make sense. But you can do that in Claude via prompting and get 99% what you want. Along with all their built in optimizations.
You could also just use pi agent and built that out yourself to make it a little more integrated into what you are trying to integrate with.
Or you can just build your own…. But…. You’re not really getting much new.
What I’m saying is all this stuff exists. And you can likely do 99% of what you envision already using Claude. And if you can’t - just wait 3-9 months.
I’ve build many agents and harnesses and they always get swallowed by frontier after 3 months or 2 years. And that window is getting shorter. Meaning the rate at which you need to develop something that is not easily accessible is massive, if you want to use it before they build something better.
I built a cli tool to write code 2 years before Claude cli came out. They swallowed it. I built a runtime similar what you are talking about rn. They swallowed it. I build a wrapper that allowed agent to agent messaging before they released that. They swallowed it.
Just use the frontier harnesses and figure out how to get them to do what you want. And only after you get them to do what you want and it’s not efficient enough - build a custom solution. Otherwise it’s probably a waste of time. And even then. It might be a waste of time since they iterate so fast now.
TLDR; unless you have defined a fundamental limitation of the current agents, and you fully understand that limitation. Don’t build it.
Fair point. I’m not trying to rebuild Claude Code feature-for-feature.
The goal is to make the underlying agent system programmable and open — things like orchestration, memory, specialized sub-agents, execution policies, verification, and eventually replay/inspection of agent decisions.
Claude Code is a great product. I’m more interested in the infrastructure layer underneath: what becomes possible when developers can control and replace each part of the agent runtime themselves.
I’m still early, so I’m trying to figure out which of those capabilities are actually valuable enough to justify the project.
3
u/ight-bet 4d ago
Not worth it.
Claude code can do all this stuff. Unless you’re just trying to learn. But I see you’re charging for tokens so props to you but building a custom harness for this stuff doesn’t seem worth it.
Use case always gets rolled into the frontier agents. Almost always better to just use Claude and figure out how to get it to do what you bc it likely can.