Because at the process / runtime level, harnesses are entirely replaceable by models bitter-lesson-style, what’s left, and it should be obvious since OpenClaw, is accessibility and distribution.
This is entirely the domain of hyperscallers.
Making a harness today with the hypothesis of improving productivity or controlling costs is like fine-tuning mistral in 2024 assuming it would solve hallucinations, it’s a categorical error.
S𝙳☈XView on XOpenAI’s dot is really good. They have artifacts now, besides a fully remote desktop, and you can link your devices. I don't need tailscale nor cloudflare for my personal setup anymore.
The main agent of dot is Astra. It acts as an orchestrator that can spawn indefinite sub-agents. It’s a pattern I was already following.
I'm quite surprised / pleased.
I’m still testing it, but the lack of friction alone seems worthwhile.
0
6 comments
@sadasant Hmmm. Well, harnesses can definitely improve/enhance “integration” along some, or many” dimensions. If done properly, to help bridge disjointed possibility domains, it can reduce friction which… can improve productivity?
@cometaj2 yes, but a better model will solve the same thing.
You can read my thoughts in more detail here: https://medium.com/sadasant/delete-the-harness-55892f50699f
@sadasant Perhaps, but it gets interesting if you can harness any “dumber”/cheaper/smaller/locally run? models and have them do what they otherwise wouldn’t be able to do standalone.
@cometaj2 usually you’d want an expensive model orchestrating the cheaper ones. You can do this today. You don’t even need MCP. Tell any expensive model to use tmux directly to orchestrate agents in other harnesses (codex, claude, pi, etc). Done
@cometaj2 you can even orchestrate them remotely with unix addresses, tunnels, etc. I do this all the time
@sadasant Yup, this all tracks,and I’m landing in a similar play space; pty mux, HCLI, smarter orchestrator vs dumber task handlers. It just seems to want to grow that way organically.