Why I Built event-watcher: From Reactive Chatbot to Event-Driven Agent

I’ve been thinking a lot about why most AI agents still feel like glorified chatbots.

You open a session, type a question, get an answer, and close it. Maybe you set up a cron job so it wakes up every hour to check something. But neither of these patterns is how real workers actually operate — and I think that gap points to one of the most important unresolved problems in agent architecture today.

That’s why I built event-watcher — a skill for OpenClaw that connects agents to Redis Streams and webhooks, waking them only when specific events occur. It’s crossed 1.5k installs now, and the response has pushed me to write down the thinking behind it more clearly.

The Problem: Agents Only Have Two Modes

Most agents today operate in one of two ways:

1. Prompt-triggered: a user asks a question, the agent reasons, responds, and goes idle.
2. Timer-triggered: a scheduler wakes the agent on a fixed interval to check something.

Neither of these is what I’d call a “real worker.” A real worker doesn’t wait to be asked. A real worker doesn’t wake up every 60 seconds to look around. A real worker responds to the world changing.

Think about who actually operates this way:

• A trader watching price movements and position risk
• An SRE watching service metrics for anomalies
• A risk officer watching transaction patterns for fraud signals
• A supply chain manager watching inventory and order status

These people aren’t waiting for someone to prompt them. They’re watching signals — and they act when the signal warrants it. The high-value decisions they make are almost never prompt-first. They’re event-first.

The current generation of agents has no equivalent of this. They don’t have a way to receive the world’s events. And I’d argue that’s a bigger limitation than model capability. An agent that never knows a risk threshold was breached can’t respond to it, no matter how good its reasoning is.

The Insight That Drove This

Here’s what clicked for me: an agent’s proactivity isn’t a function of how smart the model is — it’s a function of what signals the agent can receive.

Most people assume that if an agent isn’t proactive enough, you need a better model. In reality, the bottleneck is almost always upstream: the agent simply doesn’t know what happened. There’s no entry point for the world’s events to reach it.

The fix isn’t a smarter prompt. It’s an event input.

That’s what event-watcher is: an infrastructure layer that connects the outside world to an agent session, and only wakes the agent when something actually worth thinking about has occurred.

What It Does

event-watcher listens to two event sources:

• Redis Streams — for high-throughput internal event buses (message queues, audit logs, transaction streams, monitoring data)
• Webhook JSONL — for external signals from third-party services, APIs, or your own systems

But it doesn’t just pass raw events through. Raw event streams are noise. The real work is converting them into high-quality decision triggers:

• Filtering using JSON rules with AND/OR logic and regex support — so only events that actually match your criteria wake the agent
• Deduplication with configurable TTL — to prevent an agent being triggered repeatedly by the same underlying condition
• Retry logic for failed deliveries — so transient errors don’t cause silent gaps
• Session routing via sessions_send or agent_gate — for directing events to the right agent session in more complex setups

The design goal is simple: by the time an event reaches your agent, it should already be worth reasoning about.

Why “Event-Driven Cognition” Is Different from Automation

I want to be clear about what this isn’t. It’s not an if-this-then-that automation system. It’s not a rule engine that mechanically triggers a fixed action when a condition is met.

What I’m trying to enable is something I think of as event-driven cognition: the event arrives, the agent interprets it in context, makes a judgment about severity or relevance, and decides what to do next — whether that’s executing an action, generating an analysis, waiting to observe, or escalating to a human.

The agent’s reasoning capacity is preserved. What changes is when and why it engages. Instead of “someone asked me something,” the trigger is “something happened in the world.”

The Challenges I Had to Take Seriously

Getting the event capture working is honestly the easy part. The hard problems are elsewhere.

The noise problem. Connect any real event source and you’ll immediately be flooded. The question isn’t “can the agent receive events” — it’s “can you build a filter layer that turns raw event flow into a clean signal stream?” Deduplication, aggregation, throttling, cooldown windows — these are the things that determine whether the system is actually useful or just chaotic.

The action boundary problem. A passive agent’s failure mode is laziness. But a proactive agent’s failure mode is overreach. In high-stakes domains — trading, risk management, operations — you need a clear hierarchy of what the agent can do autonomously versus what requires human confirmation. “Observe only,” “generate analysis,” “suggest action,” “auto-execute,” “require human sign-off” all need to be distinct, explicit modes. Without this, proactivity becomes a liability.

The state problem. If an agent encounters every event as if it’s seeing the world for the first time, it can’t make good sequential decisions. A trading agent needs to know current positions, recent actions taken, what happened the last three times it saw this pattern. Event-driven operation without memory leads to incoherent behavior. This is the direction I see event-watcher naturally evolving: from a pure event pipe into a system where events interact with a persistent state layer.

Where I Think This Goes

The mental model I’ve arrived at is: event + state + policy + action.

• Event: what happened in the world
• State: what the agent knows about its current context and history
• Policy: the rules and role-specific judgment the agent applies
• Action: what the agent decides to do and at what permission level

Today, event-watcher covers the first layer. It’s a reliable, configurable event input for agents that previously had none. But the second and third layers are what make the difference between a reactive tool and something closer to a truly autonomous worker.

I think of this as giving agents a sensory system. Right now, most agents are smart but blind to the world as it changes. event-watcher is a step toward fixing that — not by making the reasoning smarter, but by giving the reasoning something real to respond to.

Where This Goes Next

This is still early work. event-watcher as it stands handles the event input layer — getting the right signals to the agent at the right time. But the harder layers are state and policy: making sure the agent remembers what it’s already done, understands its current context, and has a clear sense of what it’s allowed to act on autonomously.

That’s the direction I’m continuing to explore. If you’re building on OpenClaw and want agents that respond to your Redis Streams or webhooks instead of waiting for a prompt, event-watcher is here. And if you’ve run into the harder problems — state continuity, action boundaries, multi-agent routing — I’d like to hear how you’re thinking about it.