> The loop runs on stateless workers in the control plane. A worker runs one iteration
> of the loop, either a model call or the tool calls it produced, then releases the
> agent and puts the next iteration on a queue in Postgres.
...
> Also unlike other harnesses, the machines that the workers (our agent loop) run on aren't
> where the agent runs its commands.
It's late but don't think I am grokking this.
Isn't running the commands the heavier part of the work? The agent loop itself is mostly waiting for a remote model and then running the commands?
Why would I need a pool of workers for the loop when the constraining resource is likely to be the machines I am running the commands against (which can't be stateless like the workers are?)
> The loop runs on stateless workers in the control plane. A worker runs one iteration > of the loop, either a model call or the tool calls it produced, then releases the > agent and puts the next iteration on a queue in Postgres. ... > Also unlike other harnesses, the machines that the workers (our agent loop) run on aren't > where the agent runs its commands.
It's late but don't think I am grokking this.
Isn't running the commands the heavier part of the work? The agent loop itself is mostly waiting for a remote model and then running the commands?
Why would I need a pool of workers for the loop when the constraining resource is likely to be the machines I am running the commands against (which can't be stateless like the workers are?)