Background & Autonomous Agents

Chapter 3's orchestration patterns both assumed agents run to completion within a bounded task, whether alone or as part of a chain. This chapter covers a different dimension entirely: agents that run over an extended period, and agents that deliberately repeat their own task on a schedule rather than finishing once and stopping.

Background Agents, Revisited

Fundamentals' Chapter 3 introduced background invocation: an agent continues independently while you keep working, with its result arriving later. This chapter extends that same idea to genuinely longer-running work — not "finishes in a minute or two while you do something else," but work that may legitimately continue for a long stretch, or work that needs to check back in repeatedly over time rather than running once straight through.

Scheduled Wake-Ups

Rather than either blocking synchronously or ending outright, an agent can pause and schedule itself to resume later — waking up again after a specific delay to check on something and decide what to do next. This matters for two genuinely different situations, and the right delay differs between them:

• Polling something external you don't control — checking whether a long-running external process has finished. The delay should match how fast that external thing actually changes: a process that typically takes about eight minutes deserves one check around that mark, not eight separate one-minute checks.
• A long fallback heartbeat — when something else is the real signal that work is ready to continue (a notification, an event), the wake-up is just a safety net in case that signal never arrives. This should be scheduled generously — not frequently "just to stay responsive," since a signal that's actually going to arrive will arrive regardless of how often you separately check.

Looping/Autonomous Agents

Rather than being relaunched by hand each time, an agent can be set up to repeatedly re-enter its own task on a schedule, continuing across many cycles until some genuine stopping point is reached. A meaningful distinction worth drawing: dynamic pacing, where the agent itself decides how long to wait before its next cycle based on what it's actually waiting on (matching the polling-vs-heartbeat distinction above), versus a fixed schedule, where the same interval applies every time regardless of what's actually happening.

Why Not Just Poll Constantly?

Checking back every few seconds "just to be safe" feels cautious, but it wastes real resources for no genuine benefit if nothing relevant could plausibly have changed that quickly. In any system where each check carries a real cost, unnecessary frequent wake-ups are an avoidable, ongoing expense — matching the wake-up cadence to what's actually being waited on, per the polling-vs-heartbeat distinction above, is not a minor optimization but a real, practical discipline.

Hands-On Exercises