← All posts
Engineering6 min read

Webhooks and the async job model

Agent runs take seconds to minutes, which makes them a poor fit for a blocking request. A look at how we model runs as async jobs you can stream, poll, or subscribe to.

A model call returns in a second or two. An agent run — a crew taking several turns, calling tools, maybe pausing for a human — can take minutes. Treating that like a normal blocking HTTP request is a recipe for timeouts and brittle clients. So we don't.

A run is a job, not a request#

Triggering a run returns a job ID immediately. From there you have three ways to follow along, and you can mix them:

  • Stream: open a connection and receive step events as they happen — ideal for a live UI.
  • Poll: fetch the run by ID on your own cadence — ideal for a backend that checks in.
  • Subscribe: register a webhook and let us call you on completion and on each step.

Webhooks for the things you can't sit and wait for#

Webhooks matter most for the runs that take real time or pause for approval. Rather than hold a connection open for ten minutes, you get a callback when the run completes or hits a step you care about. Deliveries are signed so you can verify they came from us, and a run's full history is always available by ID if a delivery is missed. The result is a job model that fits how agent work actually behaves: asynchronously.

Written by The LoopLlama team.

Run your first agent crew in five minutes.

Get an API key and put these ideas to work. Pay only for the steps your agents run.