Always-On Agents vs. the Agents I Build

This year "always-on" became the headline feature. AWS added continuous autonomous agents to Amazon Quick in June. Salesforce is calling it ambient intelligence. Every personal-assistant launch this fall pitched an agent with its own computer that keeps working while you're away.

I've spent the same months building agents that work in bounded runs. They wake up, do a job, show their work to a human, and go back to sleep. Watching the always-on wave, what jumps out at me is how little it would take to turn those agents on. Here's how the two compare, and what the path between them looks like.

Across client work and my own builds, the same few ideas keep showing up.

Bounded runs. The agent wakes on a schedule or because a person asked, does one job, and stops. The run is the unit you log, evaluate, pay for, and argue about.

Human-in-the-Wild (HITW). The human corrects the agent from wherever they already are, by text or email, in plain language, and the correction carries into the next run. A shop owner saying "this vendor's roses have been rough lately" is training data the sales numbers will never contain.

Knowledge people can edit. What the agent knows lives in skills that a non-technical teammate can read and change, not in prompts buried in code. My All Things Open demo puts those skills right in the Django admin.

Evaluate every run. Each run is traced and scored, so "is it getting better?" has an answer.

Build next to the data. The agent sits beside the client's certified vendor data store, like their POS, instead of copying data into somebody else's agent platform.

None of that requires an agent watching anything 24/7.

Always-on is mostly a hosting and trust decision. The agent's reasoning doesn't change much. What changes is when it runs, what it can touch while nobody's watching, and what keeps it accountable.

For a lot of the small businesses I work with, a scheduled run plus a human with context covers the daily decisions. But reaction time matters more than it first looks: a price spike from a wholesaler, a stockout on a holiday weekend, a big order that needs a quick yes. That's where always-on starts paying for itself.

Bounded runs also give you a natural unit to log, evaluate, and learn from. With DeepEval on each run and OpenTelemetry traces, you can show a client exactly what changed after a person corrected the agent. That record is what you want in hand before an agent works unattended.

Always-on is the right call when waiting costs more than a mistake. A few places it clearly wins:

• Monitoring and read paths. Watching for a vendor price spike, a stockout, a failing job. Reading is cheap to get wrong.
• Time-sensitive signals. A wire order that has to be confirmed in minutes, not at tomorrow's run.
• High volume, low stakes. Triage, tagging, routing, where a human reviews a sample instead of every item.

The pattern I like: let it watch all day, and route writes (spending money, emailing a customer, changing an order) through the same human checkpoint the bounded runs already use. As the evals earn it, loosen that gate for low-risk actions.

The agents I build are closer to always-on than they look. They're already orchestrated, traced, evaluated, and have a human checkpoint. Going continuous is mostly a trigger change: the same PydanticAI agents and the same skills, fired by events instead of a Prefect schedule. A point-of-sale webhook, a vendor price feed, an inbound text.

Human-in-the-Wild gets better, too. An always-on agent the owner can text back and forth with all day stops being a report and starts being a coworker.

• Triggers and idempotency. Events arrive twice, out of order, or in bursts. Every run needs an idempotency key so a duplicate webhook never becomes a duplicate order.
• State and memory. Bounded runs can start fresh. Always-on needs durable state that outlives a session. Keep it somewhere the client can inspect, next to the skills, not locked in a vendor's memory store.
• Cost controls. Cap retries and spend per workflow per day. Pick hosting that scales to zero between events.
• Isolation and credentials. The longer an agent runs unattended, the more the runtime matters. Policies enforced outside the agent beat prompts asking it to behave.
• The write path. Reads run free. Writes route to a human through the HITW channel, with autonomy widening as evals justify it.
• Continuous evals and red teaming. An always-on agent is exposed longer, so evals run on a schedule against live traces and red team suites run regularly, not once.
• Model routing. A small, cheap model handles the constant stream of triage events. A bigger model gets called for the occasional heavy decision.
• Managed versus built. Managed always-on platforms get you running fast. Before choosing one, check where the data and memory live, how actions get gated, and how hard it is to leave. My default stays the same: build next to the client's certified data store.

I'm evaluating Prefect for this after an awesome conversation with a friend at Prefect, and I'm interested in trying it for very practical reasons. Prefect doesn't keep an agent spinning in a loop. A long-lived process (serve() or a worker polling a work pool) listens for events, and each matching event starts a normal, bounded flow run. That keeps everything I like about bounded runs and gets the reaction time of always-on.

Always-on has real drawbacks, and the ones I care about most are the ones Prefect is built to absorb.

The first is cost. An agent that's always running is an agent you're always paying for, even at 3 a.m. when nothing is happening. With Prefect, only a lightweight listener stays up. Compute gets spent when an event actually fires a run, and each run ends when the job is done.

The second is noise. Real event streams are messy: a webhook arrives twice, ten arrive in the same second, one shows up out of order. An agent reacting to each of those can place the same order twice. Prefect's debounced triggers wait out a burst and fold it into one run, and I still keep an idempotency key on every run as a backstop.

The third is silence. The scariest failure in an always-on system is the event that never comes, like a sales sync that quietly stops and an agent that keeps working from stale data. Prefect's proactive automations fire on the absence of an expected event, so a missed sync turns into an alert instead of a bad recommendation.

The fourth is runaway behavior. An agent stuck in a retry loop, or a flood of events spawning runs in parallel, can burn through a budget fast. Retry policies and concurrency limits on flows and deployments put a ceiling on how much can happen at once.

The fifth is accountability. Continuous agents can rack up decisions nobody can trace. In Prefect every event becomes a flow run with its own state, logs, and place in the event feed. That gives OpenTelemetry and my evals a clean unit to attach to, same as the bounded runs I already build.

The last is the write path. Prefect flows can pause and wait for human input before they act. That's a natural home for the Human-in-the-Wild approval step, so the agent can watch all day and still ask before it spends money or messages a customer.

Getting outside systems in is straightforward too: custom events from your own app, or Prefect Cloud webhooks a point-of-sale or vendor system can POST to.

Prefect isn't the whole answer. It doesn't sandbox the agent, so the runtime layer still matters. It doesn't evaluate output quality, so DeepEval and the red team suites still do that job. And webhooks and automations are Prefect Cloud features, so a self-hosted setup emits events from its own endpoint instead.

Bounded, human-in-the-loop agents and always-on agents aren't competing ideas. One is the foundation for the other. Build the agent that wakes up, does the job, and shows its work. Get a human teaching it from wherever they already are. Then turn it on, with the stack to back it up.

Sources: Amazon Quick always-on agents, June 2026 (AI Agent Store news roundup) · Salesforce, AI trends for 2026 · NVIDIA OpenShell overview · AWS, long-running agents on AgentCore Runtime · IT Brief, AgentCore runtime instances

Prefect: debouncing events · Prefect: automations · Prefect: webhooks