In order for the benefits of AI to be distributed, intelligence has to become a commodity.
As long as you control the skills, the learnings, and the infrastructure setup you will be fine.
And, no, wrapping claude -p or any other “allowed” use wherein you don’t control the agent loop isn’t the same.
I log everything - user messages, tasks, project memory, even bash commands for forensics. As a consequence you can do reflection where you analyze past work and extract refinements for the harness and realign the project when it diverged from user intentions. I don't have to do this manually, it reduces steering work.
I could make it work if I didn't care about access to latest reasoning model capabilities, but then my customers would no longer be interested in any of this.
I tried the DIY provider agnostic harness thing and it performs like shit compared to what OAI, Anthropic and Google's engineers have created. I don't have a trillion dollar AI budget. I feel like these comments are sometimes written with the assumption that the reader does.
Just ask AI to make it perform not like shit. /s
The various vendors behave differently enough to make a simple code contract swap largely infeasible for many kinds of domain-specific agents. I agree there are lots cases where this does work (probably most of them), but you sacrifice performance in the targeted scenarios where you need much more specific alignment and control.
The biggest example where this breaks down is with computer use and vision. I cannot take a targeted solution that works on OAI's stack and forklift it over to anthropic (or google) and expect anything to perform correctly. Some things will work some of the time, but it's basically starting all over again with alignment each time you move something this complex.
Having a generic interface for executing shell and writing code in an iterative ecosystem is not a hard problem to solve. Having a generic interface for reliably inspecting specific PDF documents in a very particular way in a single shot is a much more difficult problem to solve.
If you follow this argument to its logical conclusion, you will wind up implementing a provider-specific version of your tools. And the ones that demand this treatment will be the most complicated ones.
- Agents live in their own directories, for example ~/Agents/[project]/[instance]/
- In a tmux session run each agent in its own window and directory. Pi, OpenCode, Claude Code, Codex, a combination, whatever works best at any given time.
- Tell them that they are working with other agents, and that knowledge is shared and stored in an agreed format. They are very good at using OKF[1], for example. In my actual setup I use a harvester agent whose only job is to ensure the quality of the knowledge.
- They can communicate with each other simply by sending messages to each other's tmux windows with tmux send-keys. If the team grows, or you work with other people, you can use a general messaging system (I wrote and maintain https://github.com/awebai/aweb but I am sure there are others).
Or using it in a way that's replaceable I guess, not having your entire work only ther, as your main machine.