Honestly the fact that we're still modeling agent harnesses like chat and strapping them into shell sessions instead of building async actor systems with sandboxed OS functionality access actors is bananas to me. So much easy wins can be had just by building on right abstractions... Hopefully will get enough time to play with this idea soon on my own.

▲

dirtbag__dad a day ago | parent [-]

Do you have any examples of this approach?

▲

rafaelmn a day ago | parent | next [-]

I'm actually taking the time to hash out the details to do this as a side experiment project, but basically what I read this project as showing is that if you leverage asynchrony you can let agents be more efficient - and you get this "for free" if you model your "agents" as actors that interact with the system through message passing. Then all the system operations become messages to different actors, need to read a file => message the fs actor => get reply from FS actor as a message when it's done. You'd probably need some out of mailbox ways to share blob resources and sockets for realtime (audio), but for the most part simple message passing should handle most of what LLM agents do.

Actors can have identities and roles for RBAC, etc. you - cross agent communication is the same as sending any other message to a actors.

Not to mention that actors can be on your device, another device, etc. whatever the router can resolve - it's transparent to the agents.

▲

solarkraft a day ago | parent | next [-]

I’d think the approach in this repo gets close to that, no? I also think LLM harnesses should just support typical async i/o.

Let a model get notifications when something it has accessed/ subscribed to changes, a tool produces output or it gets some other kind of message (for example by another AI or flesh agent). Wait until the next turn or wake it up. It can still decide to do nothing and wait.

▲

ibash a day ago | parent | prev | next [-]

I think you nailed it. I have my own agent harness that's designed with inspiration from erlang/elixir. It seems to be a natural fit for indeterministic output and failures.

▲

hombre_fatal a day ago | parent | prev [-]

You lambasted the interface (linear messages, chat) but then never pitched us your vision of a successor.

Your technical ideas are just implementation details behind the interface. What's your idea for a better UX?

	▲	rafaelmn 21 hours ago \| parent [-]
		That's the reason I'm excited about the orchestrator because it would let me build my ideal UX on top. If you move away from the idea that agents are chat streams and treat them as processes/actors then you can start letting agents represent themselves/build their own interfaces. And if you build enough introspection into the protocol because everything is message based you can have other agents build interfaces for them. So like either standard GUI, or a voice assistant talking to you and delegating to agents, etc. It's not an idea it's a way of thinking about agent systems - basically an agent OS.

▲

dpc_01234 a day ago | parent | prev [-]

https://tau-agent.dev/ in my setup. Many sessions each multiagent, in different sandboxes, sending messages. Also nothing in the main article that Tau wouldn't have. I just don't have stamina for more "marketing". Async tools ... sooo basic. :D