I kept seeing a slightly absurd pattern in longer Agent Bridge tasks.

The coding agent would do the work, push the change, start CI and correctly decide that the next sensible action was to wait.

Then it would say something like "I'll check back shortly."

And the turn would end.

Nothing was going to check back.

The reasoning was fine. The lifecycle was missing one verb.

This looked like an autonomy problem

My first instinct was to connect it to the broader work we have been doing on autonomous execution.

Maybe a Run that encounters pending CI should become an autonomous episode. Maybe Agent Bridge needed a scheduler. Maybe we needed background jobs that could own the task until the external condition changed.

All of those mechanisms can be useful.

They were also far larger than the failure in front of us.

The agent did not need permission to invent new work. It did not need a plan executor. It did not need a general workflow engine deciding what happened next.

It had already decided what happened next.

Wait for a bounded period, then continue the same conversation.

That is a much smaller primitive.

The important word was same

We already had scheduled routines and autonomous episodes in Agent Bridge. Reusing either blindly would have changed the meaning of the work.

A scheduled routine is a separate scheduled occurrence. An autonomous episode has its own bounded objective and authority.

What I wanted here was less interesting.

The follow-up should return to the exact conversation and provider that asked for the wait. It should use the provider session we already persist. It should enter through the ordinary Run path. It should still queue behind a user message if the user has started talking again.

In other words, the wait should not create a second actor.

It should let the existing actor finish its turn later.

That distinction kept the implementation small.

We added a continuation, not a scheduler

The resulting mechanism is deliberately narrow.

During an ordinary Run, the provider can ask Agent Bridge to wait for a bounded delay. Agent Bridge stores a pending continuation in the existing database. When it becomes due, the interactive runtime claims it at most once and dispatches a new ordinary Run back into the same conversation and provider context.

The existing provider-session persistence does the important part: the follow-up resumes the same native coding-agent session rather than starting an unrelated conversation about the old work.

There is an expiry. A claimed continuation is not replayed after an ambiguous restart. Failed or cancelled origin Runs do not wake later. If the provider session has changed, the continuation is fenced. If the user has an active turn, the continuation waits behind it.

We added Discord after the first implementation and hardened the packaging so the helper exists in the actual release artifact, not just a source checkout.

None of that required a workflow graph.

A tool can be smaller than a Skill

This work also sharpened a distinction I had been muddling.

A Skill tells an agent how to do something. It is guidance, context and policy.

The wait mechanism is not advice to "remember to come back later". The provider already knew it wanted to wait. It needed a runtime capability that could preserve the continuation after the current process turn returned.

That is a tool-shaped problem.

The agent can decide when to use it. Agent Bridge owns the durable mechanic.

This seems obvious when written down. It has been useful in deciding where new behaviour belongs. Not every missing agent behaviour deserves another prompt, and not every useful instruction deserves another runtime primitive.

The question is what is actually missing.

It is another argument against premature orchestration

The previous Field Note was about why Agent Bridge does not have its own agent framework.

I wrote that the provider agents should own the software work while Agent Bridge owns the durability around it.

This wait primitive is a fairly good test of that claim.

We could have used the problem as evidence that Agent Bridge finally needed a general orchestration layer.

Instead, the provider still decides that CI should be checked again. It still knows what success means. It still decides what to do when the result arrives.

Agent Bridge only makes "come back to this same work later" durable.

That is exactly the kind of boring surrounding capability the product seems to keep needing.

Small primitives still need hard edges

The implementation being small does not make it harmless.

A continuation can duplicate work if claimed twice. It can surprise the user if it wakes after they cancelled the task. It can act in the wrong provider session if the conversation moved on. It can become an accidental monitoring daemon if delays are unbounded.

Most of the hardening work was therefore about not letting a tiny primitive acquire workflow-engine semantics by accident.

At most once claim. Bounded expiry. Same provider session. Successful origin only. Existing queue. Existing Run authority.

The useful test was not whether it could wake up.

It was whether waking up still meant the same thing as continuing the original work.

What I am watching next

There will be pressure to make this more general.

Wait until a webhook arrives. Wait until a PR is approved. Wait until a deployment is healthy. Wait on several conditions. Branch depending on the result.

Some of those may eventually deserve first-class mechanics.

I want each one to earn the extra system.

For now, a surprisingly large class of "the agent gave up too early" problems can be expressed as one bounded continuation back into the path we already trust.

The agent did not need another workflow engine.

It needed a way to wait.