What are proactive agents?

1. Definition: What makes an agent proactive

A proactive agent is an AI agent that acts without being prompted. It watches its environment, notices when something changes, and decides whether and how to respond. The defining characteristic is how it wakes up, not what model it runs or what framework it uses.

Most AI agents today are reactive: they receive a prompt, execute a chain of tool calls, return a response, and go back to sleep. The whole cycle starts when a human pushes a button. A proactive agent inverts this relationship. It is always running in the background — watching the world and acting when the moment is right.

The term appears in a 2024 paper from Tsinghua and Huawei (“Proactive Agent: Shifting LLM Agents from Reactive Responses to Active Assistance”), which formalizes the same five claims we ended up with independently: push beats poll, persistent state is non-negotiable, shared environmental state is the coordination primitive, calibrated restraint is the hard problem, and multi-candidate fan-out beats single proposals.

2. The three triggers

A proactive agent is defined by how it wakes up. There are exactly three triggers:

1. Time.The agent runs on a schedule or interval — every 15 minutes, every Monday at 9am, every quiet hour past midnight. This is the simplest trigger but the least differentiated. A schedule alone is just a cron job.
2. Change. The agent watches for data mutations. A ticket moves in Linear, a record updates in Salesforce, a file appears in a shared drive. The agent receives a push event (via webhook) the moment the change happens, rather than polling for it on an interval.
3. Message.Someone addresses the agent directly — a human, another agent, or a system. The agent responds in its own time, not on a polling cycle.

A truly proactive agent listens for all three. Pick one and you have made a smarter cron job. Pick two and you have made a chatbot that polls. The composition of all three is what makes an agent genuinely proactive.

3. Reactive vs proactive: a side-by-side comparison

The reactive agent asks: “What changed in the last five minutes?” The proactive agent asks: “What just changed?” The first is a query you have to invent. The second is a fact the world hands you.

For a detailed code comparison of the same agent built both ways, see Reactive vs proactive, with examples.

4. The three primitives every proactive agent needs

A proactive agent requires three primitives wired together:

Primitive 1: A wake-up mechanism

The agent needs a clock (schedules and intervals), a listener (normalized change events from providers), and an inbox(messages from humans and systems). Reactive agents only honor the third, and they don’t even honor it well — they wait to be invoked, not to be spoken to.

Primitive 2: Persistent state

The agent needs a place to remember what it saw and did between runs. Without persistent state, every wake-up is a cold start and the agent repeats the same work. Whatever store you choose — key-value, document database, real-time sync layer — it needs to support fast reads and writes, handle concurrent access safely, and ideally emit change events when state mutates.

Primitive 3: Durability

A proactive agent is long-lived. It runs while you sleep, while deploys ship, while providers rate-limit. The runtime must assume failure is the steady state. This means:

• Checkpointing — resume after failure, not restart
• Idempotency — prevent repeated external calls
• Spend observability — catch runaway loops
• Scoped authentication — limit blast radius per agent

Together these three primitives form the infrastructure layer that sits underneath a proactive agent. You can build it yourself, adopt an existing runtime, or piece it together from cloud services — the important thing is that all three are present. For a deeper treatment, see Proactive agents need three primitives.

5. How to build a proactive agent

Building a proactive agent is primarily an infrastructure problem, not a model problem. Here are the five steps:

1. Define your triggers. Identify which of the three triggers your agent needs: time (schedules/intervals), change (data mutations from external systems via webhooks), and message (human or system communication). Most useful agents need at least two.
2. Set up push-based wake-ups. Replace polling loops with event-driven triggers. For time, use a durable scheduler (cron, cloud scheduler, or a task queue with delayed delivery). For change, register webhooks with providers and handle signature verification, ack-and-enqueue, and deduplication. For messages, set up an async inbox.
3. Implement persistent state. Give the agent a durable store for what it saw and did between runs. Options range from a simple key-value store to a real-time database with change feeds. The key requirement is that state survives restarts and concurrent writes are handled safely.
4. Add durability guarantees. Add checkpointing so the agent resumes after failure instead of restarting from scratch. Make external calls idempotent to prevent repeated actions. Add spend tracking to catch runaway loops. Scope authentication so a misbehaving agent cannot access resources beyond its role.
5. Write the agent logic. Once the infrastructure handles triggers, state, and recovery, the agent's core logic is small: receive a trigger event, check state, decide whether to act, perform the action, update state. The decision logic — including when NOT to act — is where the real complexity lives.

The pattern that emerges: once the infrastructure handles triggers, state, and recovery, the agent’s own code shrinks to a handler and decision logic. The hard part shifts from plumbing to behavior — teaching the agent when not to act is harder than wiring up the events.

Example: Reactive vs proactive ticket closer

Consider an agent that closes a support ticket when the customer’s last reply contains approval. Here is the reactive version most teams ship:

// Reactive — runs every 5 min via cron
async function tick() {
  const tickets = await zendesk.search({
    status: "open",
    updated_since: lastRun,
  });
  for (const t of tickets) {
    if (containsApproval(t.lastCustomerReply)) {
      await zendesk.close(t.id);
    }
  }
  lastRun = Date.now();
}

This works, but it polls on a made-up interval, the lastRun global resets on deploy, bursts overwhelm the next tick, and two instances racing cause double-closes.

A proactive version inverts the flow:

// Proactive — fires on each webhook event
async function onTicketUpdated(event) {
  const { previous, current } = event;
  if (previous.status !== "open") return;

  if (containsApproval(current.lastCustomerReply)) {
    await zendesk.close(current.id);
  }
}

The agent no longer polls — it receives each change as it happens. No batch, no interval, no lastRun. The event carries both previous and current state, so the agent sees the transition, not just a snapshot. Deduplication, ordering, and delivery become infrastructure concerns handled outside the agent’s code. For a deeper walkthrough, see Reactive vs proactive, with examples.

6. When reactive is still the right choice

Reactive agents are not bad — they are appropriate for certain shapes of work:

• Batch-shaped jobs— “every Monday morning, generate a digest” — are reactive by design.
• Long computethat does not care about freshness — nightly backfills, weekly retraining runs.
• One-shot prompts— the user asks, the agent answers, done. Reactive is the only answer.

What reactive is notappropriate for is anything where the value of the agent is its responsiveness to the world. If the agent’s job is to notice things and act on them, polling will lose to push every time, on every metric you care about.

7. Frequently asked questions

Is a cron job the same as a proactive agent?

No. A cron job only uses one trigger (time). A proactive agent combines time-based schedules with change-based triggers (webhooks) and message-based triggers (inbox), plus persistent state and durability. A cron job is one primitive; a proactive agent wires all three together.

Do I need a specific framework to build proactive agents?

No. Proactive agents are defined by their architecture (how they wake up and maintain state), not by a specific framework. You can build them with any language or agent SDK. The key requirements are push-based triggers, persistent state between runs, and durability guarantees like checkpointing and idempotency.

Can a single agent be proactive, or does it require multiple agents?

A single agent can be fully proactive. Multi-agent systems are a second-order benefit that emerges naturally when agents share state, but the core concept applies to a single agent that listens for time, change, and message triggers.

What is the biggest challenge in building proactive agents?

State management between wake-ups. Most agents wake up amnesiac — they don't remember what they saw or did last time. Building persistent, conflict-aware state that survives across triggers is the hardest engineering problem, followed by calibrated restraint (knowing when NOT to act).