{ "@context": "https://schema.org", "@id": "https://aggr.aymericbeaumet.com/items/ampcode-com/2026-07-23-event-driven-orbs/#webpage", "@type": [ "WebPage", "ArchiveComponent" ], "articleBody": "Amp's orbs can now receive requests and react to events outside Amp.\n\nThat means an orb can wake up when CI fails on GitHub, when someone opens a Linear issue, when a monitor raises an alert, or when an event arrives from Discord. If it can send an HTTP request, it can wake an orb.\n\n## More Ways to Wake an Orb\n\nGitHub issues are just one example. You can use the same pattern to:\n\n- Investigate every CI failure on `main` and post the findings to Slack.\n- Watch for new releases of your dependencies, then review the changes and open an upgrade PR.\n- Start a fresh thread when someone opens a Linear issue, then comment with a fix or report.\n- Turn a bug report from Discord into a reproduction and pull request.\n- Resume a rollout when a deployment or security scan reports back.\n\nThe event decides when the orb wakes up. You decide what it does next.\n\n## From a GitHub Event to an Orb\n\nHere is the whole setup. Start a thread in an orb for your repository and tell Amp which events to watch and what to do with them:\n\n![Prompt asking Amp to monitor GitHub issues and pull requests with a webhook](https://ampcode.com/news/webhook-automations-github-prompt.png)\n\nAmp turns that request into a project-specific plugin. It scopes the listener to the repository and events you asked for, verifies GitHub's signature, deduplicates deliveries, and starts a read-only orb thread with trusted event metadata.\n\n![Amp describing the GitHub webhook plugin it will build](https://ampcode.com/news/webhook-automations-plugin-plan.png)\n\nThen Amp loads the plugin and registers its durable endpoint:\n\n![Amp registering the plugin's durable webhook endpoint](https://ampcode.com/news/webhook-automations-plugin-loaded.png)\n\nIf the orb's GitHub token can administer repository webhooks, Amp connects the endpoint for you. In this case it could not, so Amp gave us one manual step without printing the private URL or signing secret into the thread:\n\n![Amp explaining the manual GitHub webhook configuration step](https://ampcode.com/news/webhook-automations-github-setup.png)\n\n## A Wild Issue Appears\n\nOnce the webhook is active, someone opens issue #57:\n\n![GitHub issue 57 reporting a typo in a completion description](https://ampcode.com/news/webhook-automations-github-issue.png)\n\nGitHub sends the signed event to Amp. Amp verifies it and starts a fresh orb thread with the trusted repository, event, issue, and actor metadata. The issue itself remains untrusted input, not agent instructions:\n\n![A new Amp thread created from a verified GitHub issue webhook](https://ampcode.com/news/webhook-automations-spawned-thread.png)\n\nThe new thread inspects the current issue and relevant code, then reports what it found:\n\n![Amp report confirming issue 57 as a low-impact UI typo](https://ampcode.com/news/webhook-automations-investigation-report.png)\n\nThe typo is real, appears once, and only affects secondary menu text. Now the same workflow runs for every issue and pull request event while the original orb sleeps.\n\n## How It Works\n\nWebhooks work through the [Amp Plugin API](https://ampcode.com/manual/plugin-api). When you ask Amp to listen for an event, it creates a plugin in the orb and calls `amp.createWebhook` to register a durable endpoint for that thread. Then it loads the plugin and gives you the URL to connect to GitHub, Linear, Discord, or another service. If the orb already has access, Amp can connect it for you.\n\nWhen a request arrives, Amp stores the event and wakes the orb. The plugin validates and filters the payload, then handles it using the instructions you gave Amp. The URL stays the same across plugin reloads and orb restarts, so the orb does not need to keep running while it waits.\n\n## React to Events However You Want\n\n`amp.createWebhook` gives the plugin a handler, not a fixed workflow. That handler is ordinary TypeScript with access to the rest of the Plugin API. The handler can:\n\n- Continue the owning thread with its context intact by appending the event to `ctx.thread`.\n- Start a fresh thread in an orb with `amp.getBuiltinAgent(...).createThread({ executor: 'orb' })`.\n- Keep durable state so it can react every time, or handle one matching event and then stop listening.\n\nThat is where the flexibility comes from. Tell Amp how you want to handle an event and it writes the handler that way. It can also call external APIs to post results back to Slack, Linear, GitHub, or wherever the work began. Return to the owning thread whenever you want to change the behavior.\n\nThe webhook URL is a credential. Keep it private, and tell Amp to remove it when you no longer need it.\n", "authors": [], "captured_at": "2026-10-03T23:09:50.514863041+00:00", "category": "programming", "content_html": "

Amp's orbs can now receive requests and react to events outside Amp.

\n

That means an orb can wake up when CI fails on GitHub, when someone opens a Linear issue, when a monitor raises an alert, or when an event arrives from Discord. If it can send an HTTP request, it can wake an orb.

\n

More Ways to Wake an Orb

\n

GitHub issues are just one example. You can use the same pattern to:

\n\n

The event decides when the orb wakes up. You decide what it does next.

\n

From a GitHub Event to an Orb

\n

Here is the whole setup. Start a thread in an orb for your repository and tell Amp which events to watch and what to do with them:

\n

\"Prompt

\n

Amp turns that request into a project-specific plugin. It scopes the listener to the repository and events you asked for, verifies GitHub's signature, deduplicates deliveries, and starts a read-only orb thread with trusted event metadata.

\n

\"Amp

\n

Then Amp loads the plugin and registers its durable endpoint:

\n

\"Amp

\n

If the orb's GitHub token can administer repository webhooks, Amp connects the endpoint for you. In this case it could not, so Amp gave us one manual step without printing the private URL or signing secret into the thread:

\n

\"Amp

\n

A Wild Issue Appears

\n

Once the webhook is active, someone opens issue #57:

\n

\"GitHub

\n

GitHub sends the signed event to Amp. Amp verifies it and starts a fresh orb thread with the trusted repository, event, issue, and actor metadata. The issue itself remains untrusted input, not agent instructions:

\n

\"A

\n

The new thread inspects the current issue and relevant code, then reports what it found:

\n

\"Amp

\n

The typo is real, appears once, and only affects secondary menu text. Now the same workflow runs for every issue and pull request event while the original orb sleeps.

\n

How It Works

\n

Webhooks work through the Amp Plugin API. When you ask Amp to listen for an event, it creates a plugin in the orb and calls amp.createWebhook to register a durable endpoint for that thread. Then it loads the plugin and gives you the URL to connect to GitHub, Linear, Discord, or another service. If the orb already has access, Amp can connect it for you.

\n

When a request arrives, Amp stores the event and wakes the orb. The plugin validates and filters the payload, then handles it using the instructions you gave Amp. The URL stays the same across plugin reloads and orb restarts, so the orb does not need to keep running while it waits.

\n

React to Events However You Want

\n

amp.createWebhook gives the plugin a handler, not a fixed workflow. That handler is ordinary TypeScript with access to the rest of the Plugin API. The handler can:

\n\n

That is where the flexibility comes from. Tell Amp how you want to handle an event and it writes the handler that way. It can also call external APIs to post results back to Slack, Linear, GitHub, or wherever the work began. Return to the owning thread whenever you want to change the behavior.

\n

The webhook URL is a credential. Keep it private, and tell Amp to remove it when you no longer need it.

\n", "content_markdown": "Amp's orbs can now receive requests and react to events outside Amp.\n\nThat means an orb can wake up when CI fails on GitHub, when someone opens a Linear issue, when a monitor raises an alert, or when an event arrives from Discord. If it can send an HTTP request, it can wake an orb.\n\n## More Ways to Wake an Orb\n\nGitHub issues are just one example. You can use the same pattern to:\n\n- Investigate every CI failure on `main` and post the findings to Slack.\n- Watch for new releases of your dependencies, then review the changes and open an upgrade PR.\n- Start a fresh thread when someone opens a Linear issue, then comment with a fix or report.\n- Turn a bug report from Discord into a reproduction and pull request.\n- Resume a rollout when a deployment or security scan reports back.\n\nThe event decides when the orb wakes up. You decide what it does next.\n\n## From a GitHub Event to an Orb\n\nHere is the whole setup. Start a thread in an orb for your repository and tell Amp which events to watch and what to do with them:\n\n![Prompt asking Amp to monitor GitHub issues and pull requests with a webhook](https://ampcode.com/news/webhook-automations-github-prompt.png)\n\nAmp turns that request into a project-specific plugin. It scopes the listener to the repository and events you asked for, verifies GitHub's signature, deduplicates deliveries, and starts a read-only orb thread with trusted event metadata.\n\n![Amp describing the GitHub webhook plugin it will build](https://ampcode.com/news/webhook-automations-plugin-plan.png)\n\nThen Amp loads the plugin and registers its durable endpoint:\n\n![Amp registering the plugin's durable webhook endpoint](https://ampcode.com/news/webhook-automations-plugin-loaded.png)\n\nIf the orb's GitHub token can administer repository webhooks, Amp connects the endpoint for you. In this case it could not, so Amp gave us one manual step without printing the private URL or signing secret into the thread:\n\n![Amp explaining the manual GitHub webhook configuration step](https://ampcode.com/news/webhook-automations-github-setup.png)\n\n## A Wild Issue Appears\n\nOnce the webhook is active, someone opens issue #57:\n\n![GitHub issue 57 reporting a typo in a completion description](https://ampcode.com/news/webhook-automations-github-issue.png)\n\nGitHub sends the signed event to Amp. Amp verifies it and starts a fresh orb thread with the trusted repository, event, issue, and actor metadata. The issue itself remains untrusted input, not agent instructions:\n\n![A new Amp thread created from a verified GitHub issue webhook](https://ampcode.com/news/webhook-automations-spawned-thread.png)\n\nThe new thread inspects the current issue and relevant code, then reports what it found:\n\n![Amp report confirming issue 57 as a low-impact UI typo](https://ampcode.com/news/webhook-automations-investigation-report.png)\n\nThe typo is real, appears once, and only affects secondary menu text. Now the same workflow runs for every issue and pull request event while the original orb sleeps.\n\n## How It Works\n\nWebhooks work through the [Amp Plugin API](https://ampcode.com/manual/plugin-api). When you ask Amp to listen for an event, it creates a plugin in the orb and calls `amp.createWebhook` to register a durable endpoint for that thread. Then it loads the plugin and gives you the URL to connect to GitHub, Linear, Discord, or another service. If the orb already has access, Amp can connect it for you.\n\nWhen a request arrives, Amp stores the event and wakes the orb. The plugin validates and filters the payload, then handles it using the instructions you gave Amp. The URL stays the same across plugin reloads and orb restarts, so the orb does not need to keep running while it waits.\n\n## React to Events However You Want\n\n`amp.createWebhook` gives the plugin a handler, not a fixed workflow. That handler is ordinary TypeScript with access to the rest of the Plugin API. The handler can:\n\n- Continue the owning thread with its context intact by appending the event to `ctx.thread`.\n- Start a fresh thread in an orb with `amp.getBuiltinAgent(...).createThread({ executor: 'orb' })`.\n- Keep durable state so it can react every time, or handle one matching event and then stop listening.\n\nThat is where the flexibility comes from. Tell Amp how you want to handle an event and it writes the handler that way. It can also call external APIs to post results back to Slack, Linear, GitHub, or wherever the work began. Return to the owning thread whenever you want to change the behavior.\n\nThe webhook URL is a credential. Keep it private, and tell Amp to remove it when you no longer need it.\n", "dateCreated": "2026-10-03T23:09:50.514863041+00:00", "date_created": "2026-07-23T00:00:00+00:00", "date_modified": "2026-07-23T00:00:00+00:00", "date_published": "2026-07-23T00:00:00+00:00", "description": "Amp's orbs can now receive requests and react to events outside Amp. That means an orb can wake up when CI fails on GitHub, when someone opens a Linear issue, when a monitor raises an alert, or when an event arrives from Discord. If it can…", "external_url": "https://ampcode.com/news/event-driven-orbs", "git": { "commit": "ebb0941c5c06a2ab2377342d607535262a3e969e", "path": "items/ampcode-com/2026/07/2026-07-23-event-driven-orbs.md", "permalink": "https://github.com/aymericbeaumet/aggr-instance/blob/ebb0941c5c06a2ab2377342d607535262a3e969e/items/ampcode-com/2026/07/2026-07-23-event-driven-orbs.md" }, "id": "urn:aggr:item:a16f84e309c67271c116139fbe1ee9122f467610", "isBasedOn": { "@id": "https://ampcode.com/news/event-driven-orbs" }, "mainEntity": { "@id": "https://ampcode.com/news/event-driven-orbs", "@type": "CreativeWork", "archivedAt": { "@id": "https://aggr.aymericbeaumet.com/items/ampcode-com/2026-07-23-event-driven-orbs/#webpage" }, "dateModified": "2026-07-23T00:00:00+00:00", "datePublished": "2026-07-23T00:00:00+00:00", "headline": "Event Driven Orbs", "timeRequired": "PT3M", "url": "https://ampcode.com/news/event-driven-orbs", "wordCount": 638 }, "name": "Archived snapshot: Event Driven Orbs", "preview": null, "reading_minutes": 3, "replicated_at": null, "source": "ampcode-com", "source_name": "Amp News", "summary": "Amp's orbs can now receive requests and react to events outside Amp. That means an orb can wake up when CI fails on GitHub, when someone opens a Linear issue, when a monitor raises an alert, or when an event arrives from Discord. If it can send an HTTP request, it can wake an orb. More Ways to Wake an Orb GitHub issues are just one example. You can use the same pattern to: Investigate every CI failure on main and post the findings to Slack. Watch for new releases of your dependencies, then review the changes and open an upgrade PR. Start a fresh thread when someone opens a Linear issue, then comment with a fix or report. Turn a bug report from Discord into a reproduction and pull request. Resume a rollout when a deployment or security scan reports back. The event decides when the orb wakes up. You decide what it does next. From a GitHub Event to an Orb Here is the whole setup. Start a thread in an orb for your repository and tell Amp which events to watch and what to do with them: Amp turns that request into a project-specific plugin. It scopes the listener to the repository and events you asked for, verifies GitHub's signature, deduplicates deliveries, and starts a read-only orb thread with trusted event metadata. Then Amp loads the plugin and registers its durable endpoint: If the orb's GitHub token can administer repository webhooks, Amp connects the endpoint for you. In this case it could not, so Amp gave us one manual step without printing the private URL or signing secret into the thread: A Wild Issue Appears Once the webhook is active, someone opens issue #57: GitHub sends the signed event to Amp. Amp verifies it and starts a fresh orb thread with the trusted repository, event, issue, and actor metadata. The issue itself remains untrusted input, not agent instructions: The new thread inspects the current issue and relevant code, then reports what it found: The typo is real, appears once, and only affects secondary menu text. Now the same workflow runs for every issue and pull request event while the original orb sleeps. How It Works Webhooks work through the Amp Plugin API. When you ask Amp to listen for an event, it creates a plugin in the orb and calls amp.createWebhook to register a durable endpoint for that thread. Then it loads the plugin and gives you the URL to connect to GitHub, Linear, Discord, or another service. If the orb already has access, Amp can connect it for you. When a request arrives, Amp stores the event and wakes the orb. The plugin validates and filters the payload, then handles it using the instructions you gave Amp. The URL stays the same across plugin reloads and orb restarts, so the orb does not need to keep running while it waits. React to Events However You Want amp.createWebhook gives the plugin a handler, not a fixed workflow. That handler is ordinary TypeScript with access to the rest of the Plugin API. The handler can: Continue the owning thread with its context intact by appending the event to ctx.thread. Start a fresh thread in an orb with amp.getBuiltinAgent(...).createThread({ executor: 'orb' }). Keep durable state so it can react every time, or handle one matching event and then stop listening. That is where the flexibility comes from. Tell Amp how you want to handle an event and it writes the handler that way. It can also call external APIs to post results back to Slack, Linear, GitHub, or wherever the work began. Return to the owning thread whenever you want to change the behavior. The webhook URL is a credential. Keep it private, and tell Amp to remove it when you no longer need it.", "tags": [], "temporalCoverage": "2026-10-03T23:09:50.514863041+00:00", "title": "Event Driven Orbs", "url": "https://aggr.aymericbeaumet.com/items/ampcode-com/2026-07-23-event-driven-orbs/", "word_count": 638 }