Originally published at Trida AI. The quote went out at half past nine. The agent that was checking its prices finished at twenty to ten, found two prices changed, and did what it had been asked to do: it updated the customer record and drafted a correction. Nothing had gone wrong, technically. The work was simply late, and late work, acted on, became a second problem on top of the first.
Take that scene as a pattern rather than a report. It repeats wherever an agent's answer has a moment it is needed by: a summary wanted before a meeting starts, a check wanted before a payment is released, a price wanted before the quote is sent. Many runs carry budgets for steps and tokens. Fewer carry the time by which the answer stops being useful. Those are different limits, and the second one is the one the business actually feels.
A timeout is a local allowance. This tool call may take 30 seconds, that model call may take a minute, and each allowance starts fresh when the call starts. Ten calls in a row, each inside its own timeout, can keep a run going for as long as the steps hold out. Nothing anywhere in that arrangement knows what time the whole thing was supposed to be done by.
A deadline is a point in time. The gRPC deadlines guide puts it plainly: a deadline is the point past which a client is no longer willing to wait for a response. It does not reset. Every step inside the run shares the same shrinking remainder, and when the remainder reaches zero, the question changes from "how much longer can this take?" to "why is it still running at all?"
Where the deadline comes from matters. It is not an infrastructure setting, because infrastructure does not know when the quote goes out. It belongs to the task, and it is set when the task is accepted: this answer is worth having until 09:30, after that it is worth much less, and after 10:00 it may be worth less than nothing, because acting on it creates clean-up work. Some tasks get hours. An overnight research run gets until morning. The point is not that the window is short. The point is that there is one, the run knows it, and it was chosen by whoever knows what the answer is for.
One run, and the clocks nested inside it. Example times. Each step and tool call gets what is left of the run's window, never a fresh allowance of its own — and the last slice is reserved for reporting back, not for starting new work.
A deadline that sits in the orchestrator's configuration and nowhere else will be missed politely, one well-behaved step at a time. It has to travel. When a step calls a tool, it hands over the time remaining, not a new budget. When a run starts a child run, the child inherits the parent's deadline, minus the reserve the parent keeps for reading the result and reporting back. Where gRPC propagates a deadline, it handles the clock problem in the conversion: the deadline becomes a timeout with the elapsed time already deducted, so machines that disagree about the time still agree about how much is left. Agent runtimes need the same habit. Pass durations, not timestamps.
The check belongs before the work, not after it. Google's SRE book, in Addressing Cascading Failures, describes a request that sat in a queue for eleven seconds against a ten-second deadline: by the time a server picked it up, the caller had given up, and any work done on it earned no credit at all. Their rule is that a server handling a request in stages should check the time left at each stage before doing more work on it. Translated to an agent: before each step, and before each expensive tool call, compare what is left with what the step plausibly needs. If the step cannot finish inside the window, do not start it and call the outcome a timeout later. Decline it now, while declining is still cheap, and spend the remainder closing out.
The split of where time goes is worth copying too. Temporal's timeouts separate how long an activity may wait to be picked up from how long it may run once started, because those are different failures with different fixes. A run can miss its deadline in a queue, in an approval inbox, or mid-execution. If the record only says "deadline exceeded," you will fix the wrong one. Log which clock ate the time.
At zero, the run stops starting things. That sounds obvious and is widely not what happens: retries fire, a slow source gets one more chance, a final synthesis step begins with ninety seconds of context assembly still ahead of it. A deadline with no change in behaviour at zero is a comment in a config file.
The harder question is the late result. Sources do not know about your deadline. The supplier portal that was slow at 09:18 may answer at 09:41, correct and complete. The rule should be: a result that arrives after the deadline is recorded as late and is not acted on automatically. The world it was gathered for has moved. The quote went out, the meeting started, the record was written by someone else. Applying the late result without a person looking at it first turns a timing problem into a correctness problem. Logged with its arrival time, it is still useful evidence. Applied silently, it is a surprise.
What the run owes instead is a partial answer before the deadline, not a complete one after it. When the reserve slice begins, the run closes with what it has: the prices it verified, the one it could not, and the gap stated in plain words. A person can send a quote with one price flagged as unverified. Nobody can use a perfect check that arrives after the quote has gone.
Run log for a pricing check that missed one source. Example entries. The partial answer goes out inside the window with its gap flagged; the slow source's reply is kept as a late record, not applied.
Deadlines do real damage when they are picked badly. Set one from impatience instead of from the task, and you will train the system to fail expensive requests consistently — the SRE book warns about exactly that failure shape, where some more expensive requests are the ones a short deadline makes fail consistently. Set one that s silently whenever a human approval is involved, and you have a loophole, not a deadline: if waiting on a person should move the deadline, move it explicitly, in the record, where someone can see who moved it and by how much. And a genuinely open-ended task should not be given a pretend window to satisfy a policy. Give it the honest one, even if that is tomorrow morning.
So the test is two questions, asked of any agent run you operate. When does this answer stop being useful? And does the run itself know? If the first answer lives only in a person's head, the second is no, and the run will keep doing correct work at the wrong time — which, from the receiving end, looks exactly like being wrong.
If your agents are doing sound work that lands after the moment it was needed, the fix is rarely a faster model. It is a deadline drawn from the task, carried through the run, and honoured in the last minutes. Tell us where your runs are landing late through Trida AI's intake.