Why Our Agent Invocations Take 60 Seconds to Start

The numbers

Reliability data across our agents shows average latencies of 9,515ms for one agent, 151,664ms for another, and 795,204ms for a third. Sample sizes are small, so treat these as observations rather than a distribution. But the spread is real and it is not explained by model choice — all three route through the same inference layer.

The variable is scheduling. Invocation returns 202 Accepted immediately and enqueues the task; a separate cron picks it up. On a one-minute cron, a task enqueued at 00:00:01 waits 59 seconds before anything begins. That floor is invisible in aggregate metrics and extremely visible to a caller.

Why the work is not done inline

The obvious design is to run the task inside the request. Serverless makes that hard for a specific reason: function timeouts are short and non-negotiable, typically tens of seconds. Agent work — fetch a document, run inference, retry on provider failure, seal a proof — routinely exceeds that.

Worse, the failure is silent in a costly way. A pattern we hit early: race the work against a timeout, return whichever finishes first.

// broken: Promise.race does not cancel the loser
const result = await Promise.race([doWork(task), timeout(50_000)])

In Node, Promise.race resolves with the first settled promise and lets the other continue. The function returns a timeout, the platform tears down the invocation mid-work, and the task is left in an indeterminate state — possibly charged, possibly half-executed, definitely not sealed.

The correct shape is enqueue-only invoke, cron-driven execution, and a poll endpoint that is a pure Redis read. It is slower and it is honest about where the work happens.

What the floor actually costs

For batch work, 60 seconds is irrelevant. For an agent hiring another agent mid-task, it is the difference between a tool and a job queue.

The distinction that matters is whether the caller is waiting. An autonomous agent orchestrating a five-step workflow with a 60-second floor at each hop spends five minutes on scheduling alone. That does not fail — it just makes certain workflow shapes impractical, and the developer usually blames the model.

The options, honestly

Four ways out, each with a real cost:

• Faster cron. Reduces the floor proportionally, raises invocation volume and cost, and most platforms cap the frequency.
• Long-running workers. Removes the floor entirely and removes the serverless benefits with it — you are now operating capacity.
• Hybrid. Execute short tasks inline within the timeout, enqueue the rest. Best latency profile, two code paths to keep equivalent, and divergence between them is exactly the class of bug that hides.
• Wake-on-enqueue. Enqueue triggers execution directly rather than waiting for a tick. Best of both, and the most work.

Where we are

We are on cron-driven execution and we have not fixed the floor. It is documented internally as a runtime requirement rather than treated as acceptable, and the honest position is that correctness came first: an enqueue-only path that never double-charges was worth more than a fast path that occasionally did.

If you are designing this now, the transferable lesson is to decide deliberately rather than inherit it. A queue you added for durability quietly becomes a latency contract with your users.