Agents That Don't Wait to Be Asked
So what actually changes
Last April I wrote about the shift from copilots to agents – from AI that suggests code to AI that executes tasks. I framed it as moving from “faster keyboard” to “junior colleague.” Which was right, but I’d hung onto one assumption I hadn’t really questioned: that a human is always the one who kicks things off. Someone opens a chat, describes a task, the agent gets to work.
That assumption’s already outdated.
The next shift isn’t about making agents better at the tasks humans assign. It’s about agents embedded in your workflows as persistent, event-driven roles – watching for signals, responding on their own, and producing outputs that flow into the same review processes your human work does. Not agents you talk to. Agents that are just… on. Doing work that would otherwise pile up or never happen at all.
This is the move from user-driven agentic AI to event-driven agentic AI. And I think it’s the most consequential change in how orgs will integrate AI over the next few years.
The problem with the way we use agents today
Right now the model is fundamentally interactive. An engineer has a task, invokes an agent, provides context, reviews the output, iterates. Works fine for implementation stuff. But it has some structural limits.
For one, it requires human initiation. The agent only works when someone decides to use it. Work that no one thinks to delegate – or that no one has time to delegate – just never gets done.
And it’s synchronous with the human’s attention. Even when the agent runs autonomously for a bit, someone has to be there to review, give feedback, integrate. The agent’s throughput is bottlenecked by human availability.
It doesn’t scale beyond individual productivity either. User-driven agents make individual engineers faster, but you’ve still got the same number of humans with the same number of working hours. The multiplier is real but bounded.
Maybe the biggest gap: it misses the long tail of organizational work. Every eng org has a backlog of important-but-not-urgent stuff that never gets prioritized. Docs that are out of date. Tests that should exist. Code that should be refactored. Logs that should be analyzed. Dependencies that should be updated. This stuff accumulates quietly, making everything more fragile and slowing you down. No individual engineer’s going to invoke an agent for it because nobody owns it.
What if the agent just… did the work
The alternative is agents that don’t wait to be asked. They’re configured to watch for specific events or conditions, and they respond with defined actions. Like any other automated system, except with enough reasoning to handle stuff traditional automation can’t.
Some concrete examples:
A code reviewer agent that watches for new PRs and does a first-pass review before a human touches it. Not a linter – we’ve got those. A reviewer that reads the PR in context, checks for architectural consistency, flags performance or security concerns, verifies alignment with established patterns. The human still has final say, but they start with a structured analysis instead of a blank page.
A documentation maintainer that watches for merged PRs that change public APIs, config schemas, or system behavior. When it detects a change, it finds the affected docs, drafts an update, opens a PR. Doc rot is pervasive because nobody’s responsible for keeping things in sync as code changes. An event-driven agent can be that someone.
A log analyst that monitors application logs and error tracking for new patterns. Novel error or spike? It pulls the relevant code, analyzes the likely root cause, opens an issue with its analysis or – for well-understood patterns – drafts a fix and opens a PR. The difference between “error rate increased” and “the error’s from a missing null check on line 247 of PaymentService.java after Tuesday’s refactor, here’s the fix.”
A ticket worker that watches Jira (or Linear, or GitHub Issues) for tickets tagged with things like “good-first-issue” or “bug-minor.” Picks up the ticket, reads it, looks at the code, implements a fix, runs tests, opens a PR. Human reviews and merges. The agent did the implementation unprompted.
A dependency updater that monitors manifests for outdated or vulnerable packages. Creates a branch, updates the dependency, runs tests, investigates failures, opens a PR with a summary and compatibility notes. Dependabot with a brain – it reads changelogs, understands breaking changes, adapts code if needed.
None of this is sci-fi. It’s composing capabilities that exist today: event listeners, code understanding, reasoning, tool use, structured output. What’s new is the framing – treating agents not as tools humans wield, but as roles that agents fill.
Thinking in roles instead of prompts
This is the conceptual shift that matters. With a user-driven agent you think in prompts: “What instruction gets me the output I want?” With an event-driven agent you think in roles: “What org function does this fill, what triggers it, what are its responsibilities, what are its boundaries?”
Closer to hiring someone, really. You’d define the role, the responsibilities, escalation paths, quality bar, review process. An event-driven agent needs the same:
Trigger conditions. What events activate it? New PR, new ticket, log pattern, scheduled interval, dependency alert.
Scope and boundaries. What’s it allowed to do? Which repos, file types, ticket categories? What’s explicitly out of scope? An agent with unbounded scope is as dangerous as an employee with no job description.
Output format. What does it produce? PR, issue, comment, report, Slack message? Should flow into existing review processes, not create new ones.
Escalation policy. When does it stop and ask for help? Multi-service changes, test failures suggesting deeper issues, ambiguous tickets. Well-defined escalation prevents the agent from confidently doing the wrong thing.
Quality bar and review process. Who reviews its output, and against what standard? Non-negotiable. Event-driven agents produce work autonomously, so the review process is your primary quality control.
Where agent roles actually fit in your org
I wrote in 2023 about starting AI integration with problems rather than technology. Same principle here, but the lens is different. You’re looking for org functions that are underserved, repetitive, and well-scoped enough for an agent to handle reliably.
The framework I’ve been using:
Map your workflow seams. Every eng org has handoff points – code gets written then reviewed, features merged then documented, bugs reported then triaged, dependencies flagged then updated. At each seam there’s usually a delay, a quality gap, or both. The review waits in queue. The docs don’t get updated. The bug sits in triage for a week. Map these. For each: Is there a well-defined input (an event)? Well-defined output? Repetitive enough that patterns exist? Quality bar clear enough to evaluate? Yes to all four and you’ve got a candidate.
Categorize by risk and autonomy. Not all roles need the same autonomy or carry the same risk. I use a simple 2x2. Low risk, low autonomy: analysis and recommendations for humans to act on (PR review comments, log analysis, dependency audit summaries). Start here. Low risk, high autonomy: action on low-stakes stuff (doc updates, test generation, formatting, dependency bumps with passing tests). High risk, low autonomy: analysis of high-stakes situations with humans deciding (security vuln analysis, incident investigation, architecture impact). High risk, high autonomy: action on high-stakes stuff without pre-approval (automated rollbacks, real-time security response). Most orgs aren’t ready for that last quadrant and shouldn’t pretend otherwise.
Start with the backlog nobody owns. Every org has work everyone agrees should be done but no one’s doing. Test coverage for legacy modules. API docs for internal services. Cleanup of deprecated paths. Triage of low-severity bugs. Dependency updates for non-critical stuff. This is ideal for event-driven agents because the counterfactual is zero – it wasn’t getting done anyway. If the agent does it well, you created value from nothing. If it does it poorly, you’ve lost nothing. Reduces org resistance too: the agent isn’t taking work from anyone.
Instrument, measure, iterate. Treat each agent role as a product. How many events processed? How many outputs produced? What fraction accepted without modification? What fraction rejected, and why? Use this to iterate on config – prompts, scope, escalation. First version will be rough. That’s fine. The goal is a flywheel: agent does work, humans review, feedback improves agent, trust builds, scope expands.
What this does to your org
Beyond productivity, this model changes the shape of things.
Capacity gets more elastic. When routine work is handled by event-driven agents, human capacity frees up for higher-judgment work. Your org’s capacity for routine work scales with compute spend rather than headcount. Handy during crunch – you can bump agent throughput without asking humans to work weekends.
Quality baselines rise. When every PR gets an AI review before a human sees it, when every API change triggers a doc update, when every error pattern gets automated root cause analysis, the floor rises. Improvements are individually small but cumulatively significant.
Knowledge concentration goes down. One of the pernicious problems in eng orgs is critical info locked in one person’s head. Event-driven agents that document, analyze, and explain as part of their workflow create durable artifacts. The documentation agent doesn’t go on vacation.
The definition of “team” expands. A team isn’t just the humans in a Slack channel anymore. It’s the humans plus the agent roles supporting them. Sprint planning includes work agents are expected to handle. Retrospectives include agent performance. Agents become part of the operational fabric.
A few things I’m not saying
I’m not arguing for replacing engineers with agents. Event-driven agents handle the routine, well-scoped, repetitive work that accumulates in every org. The work requiring creativity, judgment, cross-functional collaboration, and deep system understanding stays human. The goal isn’t fewer engineers – it’s engineers spending time on work only humans can do.
I’m not arguing for unsupervised AI. Every example I’ve described includes human review. The agent produces work; a human evaluates it. Autonomy is in initiation and execution, not deployment. Human stays the final authority.
And I’m not saying this is easy. Configuring agent roles well requires deep understanding of your workflows, clear quality standards, robust tooling, and ongoing iteration. Takes time to build. But orgs that build it will operate at a fundamentally different level.
Where I think this lands
In 2023 I proposed a three-tier model for AI integration: internal productivity tools, workflow augmentation, autonomous systems. Event-driven agent roles are tier two maturing into something that blurs the line with tier three. The agent operates autonomously but stays embedded in human review processes that maintain control.
This is where I think the next wave of org value from AI comes from. Not better chatbots or faster code gen. AI woven into how work actually flows through an eng organization. Persistent, event-driven, role-specific, always on.
Orgs that figure this out won’t just be more productive. They’ll be structurally different – able to maintain quality and operational discipline at a level that’s not possible when every task depends on a human choosing to do it.
The future of AI in orgs isn’t a tool you pick up. It’s a colleague that’s already working when you get in.