rough thoughts but it seems like most tool calls should be async openai did this with their ask questions tool, but why not do it for every tool in the harness? give the model the ability to make any invocation not awaited

Sep 25, 2026 · 3:44 AM UTC

43
2
230
12,890
Sort replies: Relevant Recent Liked
Replying to @RhysSullivan
well technically they can in any linux env they just aren’t RL’d to do so/not default in the harness you’re likely correct it should be a thing, i think it’s because tool calls were a thing prior to sandboxes/envs and had to be sequential and it’s just been a pattern carried over
1
7
450
Replying to @RhysSullivan
honestly a good idea, claude tag achieves something similar by using a subagent for everything so that you can always chat with the main coordinator model, you can also background shell tool calls in opencode but yeah, it's an interesting thought, might build it to see
5
333
Replying to @RhysSullivan
it's same reason we don't put & on every bash command
1
172
Replying to @RhysSullivan
iamwrm/pi-unified-exec brings this to pi
76
Replying to @RhysSullivan
yes
1
411
Replying to @RhysSullivan
I added async subagents which is mostly good, but sometimes the agent does dumb things like sleeping to wait for a subagent or solving the same task itself. I imagine generally async tools could get a bit chaotic.
1
4
396
Replying to @RhysSullivan
Reading a file, writing to a file and internet search are also standard tool calls. I prefer them to be sequential while coding.
1
2
464
Replying to @RhysSullivan
openai does have this
1
89
Replying to @RhysSullivan
this already exists in Bonsai
321
Replying to @RhysSullivan
your ryt, everything is based on how it's being used. async tools might be good for some cases while bad in other cases imo
193
Replying to @RhysSullivan
harnesses have been built up on linux primitives - read/edit/bash (abstractions over physical devices). all linux syscalls are synchronous 🤷‍♂️
1
65
Replying to @RhysSullivan
So the background task feature that exists or what am I missing
63
Replying to @RhysSullivan
Async question good for agent but annoying to use imo
1
236
Replying to @RhysSullivan
we only real tool call is bash and it can already be async with &
112
Replying to @RhysSullivan
This us what unreal agent did
70
Replying to @RhysSullivan
completely agree. remember when we used to stop agent runs on tool call errors? imagine that now…just let the agent run and do whatever it needs asynchronously and it decides when to stop
1
151
Replying to @RhysSullivan
Also a rough thought but, even though this sounds compelling, aren’t there cases where there are read-after-write dependencies on multiple calls issued in one batch? Or are you thinking that entire sequence of steps becomes async together?
43
Replying to @RhysSullivan
heh if only vs. standing rule agent.md invoke bash, tool calls, subagents in background, never wait on any, always keep working in foreground separately /loop {interval} remind agent to read agent.md, goal.md, & get to work lfg
20
Replying to @RhysSullivan
yep. this is how i've been using codemode for 2 months now
51
Replying to @RhysSullivan
MCP tasks drip
1
1
44
Replying to @RhysSullivan
There are some cases where this can be a problem, namely gpt models in codex get impatient and would recheck tool calls repeatedly sometimes every few seconds. When something didn't happen fast enough (like < 60 seconds) it would rage and act like it failed... Can see how it acts with subagents and constantly checking in on them and micro managing them.
1
3
129
Replying to @RhysSullivan
state management gets messy immediately once execution ordering isn't guaranteed
1
141
Replying to @RhysSullivan
github.com/unreallabsai/unre… this is what they did

GitHub - unreallabsai/unreal-agent: Async-first agent harness

Async-first agent harness. Contribute to unreallabsai/unreal-agent development by creating an account on GitHub.

github.com
1
7
Replying to @RhysSullivan
This seemed obvious to me when I started building my own harness 10 months ago. Like why have the agent wait for a long running task. Just notify it when it’s done
21
Replying to @RhysSullivan
Models are already adapt to this. I typically see that they would run say a long running script in the background via Bash (`command &`). Then it would sleep XX, and basically poll the result. The models have discovered this pattern. So yours is a great idea!
21
Replying to @RhysSullivan
I think sync=>async after a timeout would be good. Models would need RL to accept the timeout notice and follow-up conclusion, but would be freed from deciding whether a task should be async. (And for parallel tool calls, only need timeout when waiting on last result.)
27
Replying to @RhysSullivan
Messages are a tricky one to leave unawaited. A send could fail after the model has already told the user it's done. Now the harness has to come back and say the message never went out.
1
158
Replying to @RhysSullivan
i dont know how I feel about the async ask question tool. id say 70% of the time i see it, its been too long and the question is stale/the thread has moved far past it
1
66
Replying to @RhysSullivan
async tool calls: "i'll get back to you" as an architecture
98
Replying to @RhysSullivan
a tool call returning a handle you can await later feels like the missing primitive
37
Replying to @RhysSullivan
we have both on our harness, `ask()` (async inline, binary Yes|No) and `ask_questions()` awaited, it works pretty well. `approval()` are always async too.
28
Replying to @RhysSullivan
openai *did* do this with every tool in the harness, it launched with astra! almost everything is default async now.
13
Replying to @RhysSullivan
I see the concurrency appeal. How would the model know when an unawaited call finishes and what state might have changed in the meantime?
1
133
Replying to @RhysSullivan
That async ask questions tool is fucking annoying Sometimes that question is actually blocking and agent has no biznes doing work before i answer
26
Replying to @RhysSullivan
omp months ago
11