Event-Driven Coding Agents: Triggers, Schedules, and Guardrails
Published September 5, 2026 · by the AQ team
An event-driven coding agent is one whose runs start from an event instead of a person typing a prompt: a webhook fires, a schedule ticks, CI fails, an issue gets assigned, and the agent wakes up and works. As of September 2026 every major vendor ships a version of it: Amp's orbs wake on webhooks and set their own schedules, Cursor's cloud agents fix failing CI on their own pull requests, GitHub Copilot's cloud agent starts from an issue assignment, Codex reviews every new pull request with automatic reviews on, and the Claude Code GitHub Action runs on any GitHub event including cron. Wiring a trigger is now the easy part. The hard part is the guardrails: what an agent that starts itself is allowed to touch, and what stops it when something goes wrong.
The trigger ladder
Event-driven setups differ mainly in how far the human is from the start button: a ladder from human-adjacent to fully autonomous. Every vendor claim below is from that vendor's own documentation, as of September 2026.
Mentions and assignments. The gentlest rung: a person addresses the agent, just inside the tracker or the PR instead of a terminal. Mention @claude in an issue comment and the Claude Code GitHub Action responds; mention @codex review and Codex reviews the pull request; assign an issue to Copilot and its cloud agent plans the work and opens a pull request. Linear formalizes this as delegation: the agent works while the human teammate stays the assignee and keeps ownership.
Repository events. The agent runs when the repository changes. The canonical case is review on every pull request: Codex's automatic reviews setting posts a review whenever a PR is opened for review (admins control which PR events count), and the Claude Code GitHub Action does the same from a workflow file. Review is the natural first rung of autonomy because the agent only comments: nothing merges because a bot spoke.
CI failure autofix. The event is red CI, and the response is a patch. Cursor's cloud agents automatically try to fix GitHub Actions failures on pull requests they created, and ignore checks that are also failing on the base branch. The scoping is deliberate: its own PRs, not any red build in the organization.
Schedules. Cron is the oldest trigger: reports, dependency bumps, nightly cleanups. The Claude Code GitHub Action runs in automation mode on a cron trigger; GitHub only runs scheduled workflows from the default branch, and in public repositories disables the schedule after 60 days without activity, a useful built-in dead-man switch.
Arbitrary webhooks. The general case: anything that can send an HTTP request can start an agent. Amp shipped this as event-driven orbs on July 23, 2026: ask the agent to listen for an event and it registers a durable webhook endpoint for the thread, and GitHub, Linear, Discord, or a monitoring system can then wake the orb.
Self-scheduling and agent-to-agent. The top rung: the agent decides when it runs next. Amp's self-scheduling (July 21, 2026) lets an agent set its own wake-up schedule and resume with full thread context, and its threads can message other threads, so one agent delegates to another. At this point no human is anywhere in the start loop.
| Trigger | Example (as of September 2026) | Who starts the run |
|---|---|---|
| Mention or assignment | @claude in a comment; an issue assigned to Copilot or delegated in Linear | A person, per task |
| Repository event | Codex automatic reviews on every new PR | Whoever opened the PR |
| CI failure | Cursor cloud agents autofixing red checks on their own PRs | The failing pipeline |
| Schedule | Claude Code GitHub Action on a cron trigger | The clock |
| External webhook | Amp orbs waking on GitHub, Linear, or monitoring events | Any service with the URL |
| Self-scheduling | Amp agents setting their own wake-ups; agent-to-agent messages | The agent itself |
The guardrails that make it safe
Every rung up the ladder removes a human check that used to be implicit: the person typing a prompt was also verifying the request was real, deciding the task was worth doing, and standing by to hit Ctrl-C. An event-driven setup has to replace each of those explicitly. The vendors' own designs, read together, form the checklist.
Verify the event. A webhook URL is an unauthenticated door unless you check signatures. Amp's event-driven orbs verify GitHub's webhook signature and deduplicate deliveries before a thread starts, and hand the agent trusted event metadata rather than the raw payload. Wire your own triggers the same way: reject unsigned payloads, and never let a replayed event start a second run.
Gate the actor. Decide who is allowed to pull the trigger. The Claude Code GitHub Action checks that the triggering user has write access to the repository before starting, and rejects bot actors outright unless they are explicitly allowlisted. Two agents that can trigger each other is an infinite loop with an invoice; bot rejection by default is the cheapest loop breaker there is.
Grant tools, not trust. An automated run should start with nothing and be granted exactly what the task needs. In the Claude Code GitHub Action's automation mode, a plain-text prompt has no shell or GitHub API access until the workflow allowlists specific tools. A nightly report generator needs read access to commits and issues, not push rights.
Bound the blast radius. Decide in advance what a run that goes wrong can break. GitHub's Copilot cloud agent is the strictest published example: it can only push to branches prefixed with copilot/, its output is a draft pull request it cannot mark ready for review, approve, or merge, the person who assigned the task cannot be the approver, and a human must approve before Actions workflows run on its code. By default it also works behind a firewall that only allows traffic to package registries, so a confused or compromised agent cannot exfiltrate data. The shape is reproducible in any setup: agent branches with a known prefix, draft PRs, human-only merge, restricted egress.
Budget the run. A triggered agent needs a stopping rule that does not depend on anyone watching. Turn limits and workflow timeouts cap a single run, concurrency limits stop a burst of events from becoming a burst of parallel agents, and Amp does some of this structurally: orbs pause after about five idle minutes and cost nothing while paused. Set a budget you would be comfortable discovering was fully spent on a Monday morning.
Treat event payloads as untrusted input. An issue title, a PR description, a commit message in a webhook body: all of it is stranger-written text flowing into the model's context. Automatic-review setups read attacker-controlled diffs by design. This is prompt injection surface, and the mitigations are the guardrails above, not clever prompting: least privilege, bounded writes, restricted egress, and a human before anything irreversible.
Which events actually deserve automation
The trigger being possible does not make it wise. A useful test: automate the event when the response is mechanical (the right action is obvious from the event), verifiable (CI or a reviewer can prove it correct), and reversible (a bad run costs a closed PR, not an incident). Review-on-every-PR, CI autofix scoped to the agent's own branches, and scheduled reports pass. "Rewrite whatever the alert points at, in production, at 3 a.m." does not.
The quieter cost of moving up the ladder is that fewer humans ever see the work. That is already the norm even with humans in the loop: a July 2026 LeadDev analysis of 25,264 agent-generated pull requests across 2,361 popular GitHub repositories found that in 79 percent of agentic PRs the same developer both reviewed and modified the agent's contribution, and only about one in eight workflows involved multiple humans. Agents that start themselves push further in that direction: nobody prompted the run, so by default nobody is watching it either. Pair event-driven agents with a place where the team can see what is running and review what a session actually did, or the automation becomes a stream of code one person rubber-stamps.
Where AQ fits
AQ is the multiplayer coding harness where engineering teams run AI coding agents like Claude Code and Codex together: shared live terminals, a code editor, and app previews, in your own cloud. On this guide's ladder, AQ takes a deliberate position rather than covering every rung: events prepare work, people start agents.
Label a Linear issue ai-task and a workspace appears in the team sidebar with its own isolated git worktree, status syncing both ways and ownership following the assignee; a teammate opens it and starts the agent, and nothing auto-launches. What AQ automates instead is everything around the run staying alive and visible: agents run as real CLIs (Claude Code, Codex, Cursor Agent, Kimi, Grok, or plain shells) in persistent tmux sessions on the team's VM, so an overnight run keeps going after the laptop closes and resumes from any device, and teammates open the same workspace and watch the same live session while it works. Agents commit, push, and open PRs under per-user GitHub auth, tracked per workspace. If you want fully unattended, webhook-woken agents, Amp currently ships the most complete version of that pattern, and the AQ vs Amp comparison walks the difference honestly. If you want always-on agent capacity where a person pulls the trigger and the whole team can see and steer what happens next, that is the case AQ was built for.
Frequently asked questions
What is an event-driven coding agent?
A coding agent whose runs are started by events rather than by a person typing a prompt: a webhook delivery, a cron schedule, a CI failure, a pull request opening, or an issue being assigned. The agent wakes, does a bounded piece of work (a review, a fix, a report), and stops until the next event. As of September 2026, Amp, Cursor, GitHub Copilot, Codex, and the Claude Code GitHub Action all ship some version of this.
Can a coding agent automatically fix failing CI?
Yes, with careful scoping. As of September 2026, Cursor's cloud agents automatically attempt fixes when GitHub Actions fail on pull requests the agent itself created, ignore checks that are also failing on the base branch, and can be disabled per PR with a comment or globally from the dashboard. The scoping is the lesson: an autofix agent should own its own branches and PRs, not chase every red build in the organization.
How do I run a coding agent on a schedule?
The simplest documented path is the Claude Code GitHub Action: give the workflow a prompt input and a cron trigger, and it runs in automation mode on that schedule, with tools granted only through an explicit allowlist. GitHub runs scheduled workflows from the default branch only, and disables the schedule in public repositories after 60 days without activity. Amp goes further: as of September 2026 its agents can set their own wake-up schedules and resume with full thread context.
What guardrails does an agent that starts itself need?
Six cover most of the risk: verify webhook signatures and deduplicate deliveries so only real events trigger runs; gate who can trigger (require write access, reject bots by default to prevent agent-triggers-agent loops); grant least-privilege tools per task; bound the blast radius with agent-prefixed branches, draft PRs, and human-only merge; restrict network egress; and cap each run with turn limits, timeouts, and concurrency controls. Treat every event payload as untrusted input, since issue titles and diffs are prompt injection surface.
Should coding agents launch automatically from issue trackers?
Opinions genuinely differ. Linear supports delegating issues to agents, including automatically through triage rules, while keeping the human teammate as the assignee who owns the result. AQ deliberately stops one step earlier: labeling a Linear issue ai-task creates a prepared workspace with two-way status sync, and a person opens it and starts the agent. Auto-launch saves a click; a human start means someone has decided the task is ready and is around to steer the session it produces.