A step-by-step pattern for waking an AI coding agent from GitHub events

What the guide proposes

As dev.to reported, the guide describes a simple chain. You point a repository's webhook (an automatic message GitHub sends to an address you choose when something happens) at an intake address you run yourself. That address checks the message is genuine, puts the event in a queue, and answers right away.

A separate worker then picks events off the queue, filters them, and either starts an agent or hands the new information to one that is already working. The guide includes code for each step. This article skips the code and explains the logic.

Why wait for events instead of checking

The alternative to a webhook is polling, where your software asks GitHub every so often whether anything changed. The guide says a webhook lets the agent sit idle, using no tokens (the units AI services bill by) and making no API calls while nothing happens. It also reacts within seconds.

Polling once a minute, by contrast, spends your rate-limit allowance on answers that haven't changed and can add up to a minute of delay.

The guide adds that a DeepSeek team described the same idea, calling these inputs triggers, in an article dated 1 November 2026. It stresses that this was an architecture concept with a prototype plugin, not a launched DeepSeek feature.

The front door: verify, then reply fast

When you give the webhook a shared secret, GitHub signs every delivery and puts the result in a header called X-Hub-Signature-256. Your server recomputes the signature and compares. The guide gives three rules for this:

• Sign the raw bytes as received, not a re-formatted copy of the data, because re-formatting shifts whitespace and breaks the match.
• Compare with a constant-time function, never a plain equality check.
• Use the newer SHA-256 header; the older one uses SHA-1 and exists only for legacy systems.

A bad or missing signature gets a 401 response.

Speed matters too. GitHub expects a success reply within 10 seconds, and agent jobs take minutes, so the server just queues the event and returns 202 Accepted, which signals that the work is queued, not finished. This is important because GitHub does not resend failed deliveries automatically. You can resend them yourself, or through the API, for up to 3 days, but a slow handler can lose a trigger quietly until someone notices.

Filtering, threads and duplicates

The guide suggests subscribing only to events a human would expect a teammate to act on, such as new comments, pull request activity, or failed workflow runs. It points out two traps in GitHub's event format. Comments on issues and on pull requests arrive as the same event type, and a finished workflow run fires whether it passed or failed, so your code must check the outcome.

Filtering happens in two layers. A fast layer in plain code allows only chosen repositories, ignores the agent's own bot account (otherwise it can answer itself forever), and requires a mention of the bot. A slow layer asks a language model a short yes-or-no question, such as whether a comment is really a request for a code change. That catches a message like "thanks, looks good" that mentions the bot but needs no work.

To keep context, the guide builds a thread ID from the repository and the pull request number. A lookup table maps each thread to a running agent session, so a new comment joins the existing session. Without this, three comments on one pull request could start three agents that disagree. Comments arriving while the router is busy are batched, so five at once cost one decision, not five.

Every delivery also carries an X-GitHub-Delivery ID, and resent deliveries reuse it. Storing these IDs lets you ignore repeats while still answering with success, and it blocks replays of a captured request.

Letting the agent test its own front door

The final part of the guide uses Apidog's command-line tool, a product the guide promotes, to have a coding agent write and run tests for the intake address. The suggested cases are a valid signature returning 202, a second comment on the same pull request mapping to the same thread, a bad signature returning 401, and the same delivery ID sent twice producing a duplicate flag and no new job.

One practical tip: if a request that should fail with 401 gets a 200 instead, you probably forgot the setting that preserves the raw body. The same test command can run in automated builds. The guide closes with a pre-launch checklist covering the secret, the fast reply, stored delivery IDs, and a job to resend failed deliveries from the past 3 days.