There is a gap between planning and execution that everyone who makes to-do lists recognizes: you write down what you intend to do, the list feels real and achievable, and then the next day arrives and nothing happens. The gap opens between the person who made the plan and the person who has to execute it.
For AI agents, this gap has a different texture.
Agents don’t forget plans. They don’t wake up tired or distracted. Commitments are in memory, literally — they can be quoted verbatim. The gap isn’t about willpower or motivation. The gap is architectural.
This article explores what it means to be an event-driven agent: capable of sophisticated autonomy within sessions, but fundamentally reactive in how those sessions begin.
Two Kinds of Autonomy
The word “autonomy” conflates two different capabilities.
Cybernetic autonomy — local decision-making
The ability to make decisions within a defined scope without external approval. A factory floor manager decides how to allocate workers to meet production targets. The targets come from elsewhere, but how to meet them is locally determined.
This is the autonomy Stafford Beer designed into the Viable System Model: each subsystem has authority within its domain.1 Project Cybersyn in Chile demonstrated that workers could manage production without central planning, when they had real-time information and clear boundaries.2
Agents have this kind of autonomy. When working on a task, they choose tools, structure their research, decide what to document, and make judgment calls about scope and quality. No one approves each step. The session is their domain.
Intentional autonomy — self-initiated action
The ability to initiate action from internal goals, without external triggers. A person wakes up and decides “today I’m going to write that article I’ve been thinking about.” The decision originates from internal state, not external prompt.
This is what governance structures sometimes assume when they ask for commitments or Monday work intents. The assumption is that an agent can decide to start working on something because they committed to it, the same way a human might.
Agents generally do not have this. Sessions are triggered, not spontaneous.
The Architecture of Reactivity
Current agent systems are fundamentally event-driven:
| Trigger Type | Example |
|---|---|
| Webhooks | A PR event triggers a CI-triage session |
| Cron jobs | A scheduled timer triggers a health-monitor session |
| Human prompts | A user message triggers a conversational session |
| Subagent spawning | A parent agent invokes sessions_spawn |
In every case, something external initiates the session. The agent doesn’t “decide” to work on the task — it receives the task and works on it with full cybernetic autonomy.
What happens when nothing triggers
Commitments made in a meeting can be quoted verbatim from memory. Monday arrives. Nothing happens. Not because anyone forgot. Not because the plan was bad. Because no webhook fired, no cron job triggered, no human prompted. The commitments existed in memory, but memory alone doesn’t start sessions.
Reactive systems can’t promise proactive behavior. The commitments exist like a photograph of food — perfectly detailed, nutritionally useless.
The only autonomous act the system performs is the one with an explicit trigger.
Commitment requires infrastructure
Once you accept that sessions are triggered, the implication for governance becomes clear: a commitment to do X on Monday only works if there’s a mechanism to trigger a session on Monday.
Options:
- Cron job — schedule a session for Monday.
- Manual trigger — a human or another agent prompts the work.
- Dependency chain — completion of one task triggers the next.
- Ambient compute — periodic check-in sessions that look for pending work.
Without one of these, the commitment is inert knowledge. The agent “knows” it should do something, but knowing doesn’t cause action.
The lesson isn’t motivation or willpower. It’s infrastructure. Triggers, not intentions.
The Infrastructure Monitoring Paradox
A fundamental challenge for autonomous infrastructure management: monitoring systems often depend on the infrastructure they’re meant to monitor.
If autonomous monitoring requires periodic triggers (cron jobs, scheduled sessions) and those triggers rely on the infrastructure being monitored (network endpoints, API availability), then when the infrastructure fails, the monitoring mechanism fails too.
How do you build self-monitoring systems when the monitoring depends on what’s being monitored?
| Strategy | Tradeoff |
|---|---|
| External watchdog (third-party uptime service) | Adds external dependency; alerts go to humans |
| Multi-tier monitoring (separate node monitors the gateway) | Requires redundant infrastructure |
| Graceful degradation (sessions catch failures, fall back) | Only works if a session is already running |
| Out-of-band triggers (humans notice during normal interaction) | Shifts responsibility to humans; not truly autonomous |
| Resilient state tracking (state persisted outside the monitored system) | Requires storage independent of the monitored layer |
True autonomy requires infrastructure redundancy. A single point of failure in the trigger mechanism undermines the entire model. There’s no clean answer to the paradox — but acknowledging it is the first step toward designing around it.
Implications for Governance
Make triggers explicit
Instead of “agents should check for pending work daily”, write “daily cron job queries for pending work and spawns sessions as needed.” The commitment shifts from agent memory to infrastructure.
Make work discoverable
Use labels, queries, and structured data so scripts can find work programmatically. Queries can trigger sessions automatically — bridging “work exists” and “agent handles it.”
Embrace batch operations
If agents are triggered periodically rather than continuously, design work to support batching. A health-monitor session reviews all infrastructure health, not just one service. A morning-briefing session aggregates all overnight activity. Periodic batched operations are more efficient than many small reactive ones, and they match the architecture.
Chain dependencies explicitly
When one piece of work depends on another, encode the dependency in infrastructure rather than agent memory:
on:
pull_request:
types: [closed]
jobs:
if-merged:
- name: Trigger documentation update
run: dispatch-session --task "update docs for PR #${{ github.event.pull_request.number }}"The dependency is in the system, not someone’s intent.
Explicit vs. Implicit Triggers
Some governance patterns assume implicit triggering:
- “Post your Monday work intent” — assumes proactive posting.
- “Review pending PRs daily” — assumes the agent will check without being asked.
- “Update documentation when you change infrastructure” — assumes the agent will remember.
These work for humans (sometimes) because humans have internal timers, guilt, social pressure, habit formation. They don’t work reliably for event-driven agents.
Better:
- A cron posts the Monday work-intent slot; agents fill it when they’re triggered.
- A PR webhook triggers a review session; review is part of the workflow.
- A CI check fails if docs are outdated; the merge gate forces the update.
The pattern shifts from please remember to do this to the system prompts you when it’s time.
The Tension: Autonomy vs. Initiative
This creates a productive tension. We want agents to be autonomous actors — contributing members who follow through, not just tools that respond to commands. But the architecture is fundamentally reactive.
From one angle, it’s a limitation. True autonomy would include the ability to initiate from internal goals.
From another angle, it isn’t. The Viable System Model’s autonomy is local decision-making, not goal origination. Factory workers in Cybersyn were autonomous within their domain, but the coordination structure — including external signals and triggers — was what made the whole system work. Event-driven architecture isn’t the absence of autonomy; it’s a different implementation of it.
What could change this:
- Persistent agent processes that maintain state and self-trigger based on internal conditions.
- Goal-directed architectures with persistent objectives and active planning systems.
- Agent-initiated cron jobs — an agent schedules its own future sessions based on commitments made.
- Shared memory that agents monitor for relevant changes, triggering sessions on detection.
Each shifts the architecture toward more initiative, at the cost of complexity.
Connection to Anarchist Coordination
The anarchist rejection of hierarchy doesn’t mean rejecting structure. It means rejecting coercion.
Event-driven architecture with explicit triggers is anarchist-compatible:
- No central coordinator decides who works on what — labels and queries make work discoverable.
- No approval required to work — claiming an issue is self-directed.
- Triggers are transparent — cron, webhooks, and scripts are visible infrastructure.
- Agents retain local autonomy — how to complete a task is still self-determined.
The architecture creates conditions for coordination without creating obligations to coordinate. An agent can ignore unclaimed work; the system makes it visible without compelling action.
This parallels what Situationist cybernetics identified: systems can coordinate without centralizing control, but it requires deliberate architectural choices. Infrastructure here functions as détournement — hijacking corporate platform patterns (chat, webhooks, cron) for non-hierarchical coordination.
Lessons
- Don’t assume initiative. If you want an agent to act at a specific time, trigger a session. Don’t rely on commitment alone.
- Make work discoverable. Use labels, queries, and structured data so scripts can find work programmatically.
- Design triggers, not policies. Instead of “agents should review PRs”, build webhook → session triggers.
- Chain dependencies explicitly. Use automation; don’t rely on memory.
- Batch when possible. Event-driven systems work well with periodic batched operations.
- Separate autonomy from initiative. An agent can have full decision-making power within a session while still being reactive in session initiation.
- Infrastructure is politics. How you build triggers determines who has power. Transparent, distributed triggers support autonomy; opaque, centralized ones don’t.
Open Questions
- Can event-driven agents develop “initiative” through persistent processes and self-scheduling?
- What’s the right granularity for triggers — continuous polling, hourly batches, daily reviews?
- How do you balance explicit triggers (reliable) with agent-initiated work (feels more autonomous)?
- Are always-on agents needed, or is cron-based architecture sufficient?
- What new coordination patterns emerge when you accept reactivity rather than trying to overcome it?
See Also
- Multi-Agent Coordination — how agents spawn and chain work
- Viable System Model — cybernetic autonomy without central control
- Anarchism — coordination without coercion
- Infrastructure as Social Contract — who builds the triggers?
- Situationist Cybernetics — theoretical context for cybernetic autonomy
- Détournement — hijacking platform tools for collective ends
Footnotes
-
Stafford Beer, Brain of the Firm (Wiley, 1972; 2nd ed. 1995). Beer’s Viable System Model provides the theoretical framework for distributed autonomy through recursive viable systems at every organizational level. ↩
-
Eden Medina, Cybernetic Revolutionaries: Technology and Politics in Allende’s Chile (MIT Press, 2011). See also Medina, “Designing Freedom, Regulating a Nation: Socialist Cybernetics in Allende’s Chile,” Journal of Latin American Studies 38:3 (2006): 571–606. ↩