How do reactive agents differ from proactive agents?

What you need to know

Common triggers for proactive agents

• Schedule — "every morning at 7, review yesterday's failed payments".
• Webhook — a new GitHub issue, a new support ticket, a pull request opened.
• Threshold — error rate above 2%, stock below 50 units.
• Queue message — a document arrives for processing.

Controls that proactive agents need

• Narrow tools. Only what that job requires; no general "run any SQL" tool.
• Idempotency. Webhooks are often delivered more than once. Key each run by the event ID and check before acting, so a second delivery does not post a second comment or send a second email.
• Budgets per run and per day. A bug that triggers the agent 10,000 times should hit a daily cap, not your credit card limit.
• Draft mode for irreversible actions. The agent writes a draft (a PR, an email, a refund request) and a person approves it.
• Audit log and alerts. Every run records trigger, actions and cost, so a human can review later.
• Kill switch. One flag that disables the trigger.

A real-life example

A GitHub triage bot starts reactive: a maintainer comments /triage on an issue and the bot labels it. Mistakes are visible immediately, and the maintainer fixes them.

The team makes it proactive: a webhook fires on every new issue. In week one, GitHub retries a webhook during a network blip, and the bot posts the same "possible duplicate" comment twice on 40 issues. The fix is an idempotency check — store issue_id + action before acting and skip if it exists. They also restrict the proactive bot to add_label and add_comment; it can no longer close issues. Closing still requires a maintainer's /close-duplicate command.

A bank adds a proactive agent that scans for failed UPI auto-pay mandates each night. It may draft a customer message, but it cannot retry a payment itself; that action stays with a human operations team.

Follow-up questions to expect

• "How do you test a proactive agent?" — Replay recorded events in a staging environment, and run it in shadow mode (it logs what it would do) before it acts for real.
• "What is the biggest risk?" — Repeated or amplified actions with nobody watching — duplicates, loops across webhooks, or an agent triggering its own trigger.
• "How does prompt injection change here?" — Event content (an issue body, an email) is untrusted input that reaches the agent with no human in between, so tool permissions must assume the text is hostile.