Amp shipped event-driven orbs on July 23, 2026 — the fifth release in a seven-day run that turns its coding agents into always-on, self-scheduling services that no longer need a human, or even an open session, to start working. An orb can now wake because CI failed, because someone opened a Linear issue, because a monitor fired, or because any service on the internet sent an HTTP request to a durable webhook URL.
That last clause is where operations and CRM teams should slow down. Amp’s own documentation says it plainly: the webhook URL is a credential. For the GitHub integration, Amp verifies the vendor’s cryptographic webhook signature before processing. For everything else — Linear, Discord, monitors, any generic HTTP sender — the documented security model is a secret, unguessable URL plus idempotency-key deduplication. If that URL leaks, whoever holds it holds the trigger.
To be clear about sourcing: this is changelog-sourced product news. Every fact below comes from Amp’s own pages — the news posts, the Plugin API reference, and the chronicle index — cross-checked against the Releasebot changelog mirror. No independent tech press had covered this release cluster as of July 26, 2026. This guide reconstructs the week, walks the webhook mechanics, separates the two trigger security models Amp actually documents, and lays out what a business should govern before pointing real CRM events at an agent that never sleeps.
- 01Five releases in seven days made agents persistent.Agent-to-agent messaging (Jul 17), the Puck meta-agent plus Slack (Jul 20), self-scheduling (Jul 21), multiplayer orbs (Jul 22), and event-driven orbs (Jul 23) — the tightest capability run we could find in Amp’s public changelog.
- 02The webhook URL is the credential — Amp says so itself.Event-driven orbs expose durable capability URLs. Amp’s docs instruct users to keep the URL private and remove it when no longer needed. No expiry, scoping, or rotation mechanism is shown for the URL itself.
- 03Signature verification is GitHub-only, not blanket.The event-driven-orbs page documents cryptographic signature verification for the GitHub integration specifically. The general createWebhook() reference documents URL secrecy plus idempotency-key dedup for all other senders.
- 04Outbound auth got hardened nine days before inbound shipped.On July 14, Amp replaced injected static secrets with OIDC workload identity — short-lived, tightly scoped tokens — for orbs calling other services. The inbound trigger surface that followed on July 23 got a bearer URL instead.
- 05No documented budget or wake-rate cap on the new autonomy.Amp’s self-scheduling page documents no cap on how often an agent can re-wake itself. That is an absence in the documentation, not proof of unlimited design — but it makes your subscription allotment the only visible ceiling.
01 — What ShippedFive releases, seven days — the week agents stopped ending.
Some quick vocabulary first. An “orb” is Amp’s name for an ephemeral remote VM — in the company’s words, “machines where agents can run without supervision”, introduced June 30, 2026 with a 32GB RAM / 16 vCPU base spec and automatic sleep when idle. And Amp itself is no longer a Sourcegraph internal tool: it has operated as an independent company, Amp Frontier Corporation, since December 2025, with the CLI renamed from the Sourcegraph npm scope in May 2026.
Onto that orb substrate, Amp’s changelog landed five releases between July 17 and July 23 — a seven-day window that is, reading its own chronicle index, the tightest capability run we could find in the product’s public history. Read them in order and the direction is unmistakable: each one removes another reason an agent would need a human present.
From Agent to Agent
Agents can spawn other agents, message them, and exchange files across Amp threads. Peers can run in orbs, on the local machine, or on any other machine running amp — including delegating a bug as a ‘side quest’ to a spawned orb thread.
Puck + Slack
Puck is a persistent meta-agent on ampcode.com that spawns and coordinates other agents, investigates issues, and archives work — Amp calls it an experiment. The same day, Amp landed in Slack: @-mention it in a channel to trigger bug fixes, feature spikes, and codebase Q&A.
Right on Schedule
Agents set their own schedules, wake themselves up, and resume with their saved prompt and full prior context. Amp’s examples: daily slowest-query digs with Slack notification, feature-flag cleanup reminders, and hourly error triage that spawns fix threads.
Multiplayer
Invite workspace members to share control of a running orb: message the agent directly, view its portal, see file changes, and use a shared terminal. Sessions are time-boxed via a TTL field on thread creation; the default duration is undisclosed.
Event-Driven Orbs
Orbs receive requests and react to outside events — a CI failure on GitHub, a new Linear issue, a monitor alert, a Discord event, or any service capable of sending an HTTP request. The release that makes everything above triggerable from outside.
Individually, each release is incremental. Composed, they change the product category. Amp states outright that self-scheduling “works great with Slack, Puck, and spawning other agents” — and in the multiplayer announcement it frames the orb as the platform’s de facto unit of work, where “the lines between description, solution, code, and computation are all blurring and merging into the orb.” A scheduled agent that can message peer agents, spawn new orbs, post to Slack, and now be woken by external events is not a coding assistant with extra features. It is a long-running service whose deploys happen to be conversations.
"Agents can now set their own schedules, wake themselves up, and keep working."— Amp product docs, Right on Schedule (July 21, 2026)
02 — The MechanicsHow event-driven orbs actually work.
The trigger surface is not a generic platform-wide endpoint. Each webhook is generated as a project-specific TypeScript plugin, registered through the Amp Plugin API’s createWebhook() call. The registration takes a key of 1–128 characters, an optional headers allowlist, and a handler function — and returns a URL the docs label a “capability URL.” That handler is where the always-on behavior lives: it can append the event to an existing thread, spawn a brand-new orb thread, hold durable state across invocations, or call external APIs.
Three operational properties matter for anyone who has run webhook infrastructure before. First, delivery is at least once, not exactly once — the docs say so explicitly, and the event object carries an id field that exists specifically as an idempotency key for deduplication. Second, handlers run against a hard 30-second processing deadline, enforced by an AbortSignal that Amp fires at the cutoff. Third, the event payload arrives with the raw body, lowercased headers, and an ISO-8601 received-at timestamp — the handler decides what becomes agent work. If you want the general engineering discipline behind that first property, our reference on building webhook handlers around at-least-once delivery covers the dedup, retry, and ordering patterns that apply here verbatim — Amp’s WebhookEvent.id is a textbook live example.
Hard processing cutoff
WebhookHandlerContext carries an AbortSignal that Amp aborts at a 30-second deadline. Long work belongs in a spawned orb thread, not in the handler itself — the handler is a router, not a worker.
At-least-once delivery
Events are delivered at least once, never exactly once. The WebhookEvent.id field is documented explicitly as an idempotency key — handler code that is not duplicate-tolerant will eventually double-fire agent work.
createWebhook() key cap
Each webhook registers with a 1–128 character key, an optional headers allowlist, and a handler. Spawned work is placed via executor type: the local machine, a fresh cloud orb, or a specific named runner.
The placement options are worth a second look. A handler that spawns work chooses one of Amp’s four current execution modes — low, medium, high, or ultra, the naming Amp settled on July 9 — and one of three executor placements: local, orb, or a named runner machine. In other words, an inbound HTTP request can start compute on a cloud VM, on the registering developer’s laptop, or on any named machine in the fleet. That flexibility is genuinely useful, and it is also exactly why the question of who can send that request deserves its own section.
03 — Trigger SecurityTwo security models, one word: precisely what is verified.
Here is the distinction that a quick read of the announcement will miss, and it is the security point of this entire release. Amp documents two different trust models for inbound events, and they are not equivalent.
For GitHub, verification is cryptographic. The event-driven-orbs page states that Amp verifies GitHub’s webhook signature and then starts a fresh orb thread with trusted repository, event, issue, and actor metadata. The design even separates trust layers deliberately: the verified metadata comes from Amp’s verification layer, while the issue body itself “remains untrusted input, not agent instructions” — an explicit mitigation against the classic malicious-GitHub-issue prompt injection.
For every other sender, the URL itself is the secret. The general createWebhook() reference — the mechanism behind Linear, Discord, monitors, and arbitrary HTTP senders — documents URL secrecy plus idempotency-key deduplication as the security model. It does not document per-request signature verification across all event sources. That means for the general case, possession of the URL is authorization: there is no documented expiry on the URL, no documented scoping of what a given sender may trigger, and rotation is manual — you “tell Amp to remove it when you no longer need it.”
"The webhook URL is a credential. Keep it private, and tell Amp to remove it when you no longer need it."— Amp product docs, Event Driven Orbs (July 23, 2026)
None of this is unusual for a v1 webhook surface — plenty of mature platforms started with capability URLs. What makes it worth flagging on day three rather than day three hundred is what sits behind the URL: not a row in a database, but an agent that can run code, spend compute, message other agents, and act without anyone watching. The blast radius of a leaked trigger URL scales with the autonomy of the thing it triggers.
04 — The ContrastOutbound got OIDC; inbound got a secret URL.
The sharpest way to see the gap is to read the July 23 release against one Amp shipped nine days earlier. On July 14 — “Secrets of the Orb” — Amp eliminated long-lived secrets injected into orbs for calling other services, replacing them with OIDC-based workload identity: short-lived tokens carrying explicit claims for workspace, project, user, thread, email, issuer, audience, subject, and expiration. Amp’s own words: “tokens are all short-lived and tightly scoped to the operations that project needs,” with zero config required from developers.
That is a genuinely modern credential story — expiry, scoping, auditability, per-thread attribution. And it makes the inbound asymmetry impossible to unsee: the same platform that decided static bearer secrets were unacceptable for orbs calling out shipped, nine days later, a static bearer URL as the general mechanism for the outside world calling in. Outbound authentication got workload identity; inbound triggering got URL secrecy. Neither Amp’s docs nor any press coverage frames these two releases as a contrast — seeing it requires reading five changelog entries across nine days side by side — but for anyone deciding whether to wire business events into this system, it is the single most useful fact of the week.
The fair reading is directional, not damning: the July 14 release proves the team treats credential hygiene as a first-class engineering problem, which makes it reasonable to expect the inbound surface to mature the same way. Until it does, the asymmetry is yours to manage. For the wider discipline — why agents should hold their own scoped, short-lived, revocable identities rather than borrowed human credentials — see our playbook on how non-human agent identity and credentials should be scoped; Amp’s OIDC claims structure is close to that playbook’s recommended shape for outbound calls, which is exactly why the inbound gap stands out.
05 — The LedgerCapability shipped vs governance shipped, release by release.
Nobody has laid the week’s releases side by side against what each one did — or did not — ship in terms of controls. The table below does exactly that, built entirely from each release’s own primary page. The pattern in the last two columns is the argument of this post made legible: the governance groundwork landed before the capability week, and the capability week itself shipped autonomy faster than controls.
| Date (2026) | Release | New autonomous capability | Identity / credential control alongside | Audit / budget control alongside |
|---|---|---|---|---|
| Governance groundwork — outbound calls | ||||
| Jul 14 | Secrets of the Orb | None — pure credential-hygiene release | OIDC workload identity: short-lived, tightly scoped tokens replace injected static secrets | Token claims attribute every outbound call to a workspace, project, user, and thread |
| The capability week — five releases in seven days (Jul 17–23) | ||||
| Jul 17 | From Agent to Agent | Agents spawn, message, and exchange files with other agents — in orbs, locally, or on remote machines | None documented | None documented |
| Jul 20 | Puck + Amp in Slack | Persistent meta-agent coordinates other agents; @-mention in Slack triggers work from chat | None documented | None documented |
| Jul 21 | Right on Schedule | Agents set their own schedules and re-wake themselves with full prior context | None documented | No wake-frequency cap or budget guardrail documented on the release page |
| Jul 22 | Multiplayer | Workspace members share live control of a running orb — messages, portal, file changes, shared terminal | Workspace-membership access; sessions time-boxed via a TTL field (default undisclosed) | Shared portal and terminal add real-time visibility for teammates |
| Jul 23 | Event-Driven Orbs | Any HTTP-capable service can wake an orb via a durable webhook | GitHub: cryptographic signature verification. All other senders: secret capability URL, manual removal | Idempotency-key dedup; 30-second handler deadline |
Sources: each row’s own release page on ampcode.com plus the Plugin API reference, retrieved July 26, 2026 — with one exception: the Jul 20 Slack detail is chronicle-summary-level only, because its own release page did not resolve when we fetched it. “None documented” means exactly that — an absence in the published pages, not a confirmed absence of internal controls. Amp may well enforce limits it has not written down. But governance you cannot read is governance you cannot audit against, and for an ops team doing vendor due diligence, the documented surface is the surface.
06 — The CategoryThe always-on agent category is consolidating fast.
Amp is not inventing this category alone. Cursor got there first on the scheduled side — our guide to Cursor’s always-on automation model covers its Automations architecture in full. What Amp’s week adds to the category is the inbound half: not just agents that run on a schedule, but agents any external system can wake on demand, plus the agent-to-agent fabric for what happens after they wake.
The same week, the pendulum swung the other way elsewhere: Anthropic’s changelog arc added hard subagent depth limits and budget caps to Claude Code — one vendor adding brakes in the same seven days another added throttle. That divergence, more than any single feature, is the trend line: the vendors racing to make agents persistent are now differentiating on how much governance ships in the box.
Our forward read: the capability side of always-on agents is close to settled — schedules, webhooks, chat triggers, and agent-to-agent handoff will be table stakes across every serious agent platform within a quarter or two. The unsettled axis is operational trust. Amp’s own July 14 release shows the direction mature platforms will take — short-lived, scoped, claims-carrying identity — and the reasonable expectation is that inbound triggers across the industry converge on signed or identity-bound events the way outbound calls already have. Teams adopting now should plan for that convergence rather than wait for it: the governance you wrap around a v1 trigger surface today is the same governance you will want when the platform hardens underneath it.
07 — Ops PlaybookBefore you wire business events into an agent that never sleeps.
The reason this post sits in our CRM and automation category rather than developer tooling: the obvious next move for any ops team reading Amp’s changelog is to point business events at it. New lead created, deal stage changed, support ticket opened, payment failed — these are exactly the “any service capable of sending an HTTP request” events the release invites. And an agent with no session boundary and no human in the loop inverts the operational assumptions most teams inherit from their existing automation stack. Three things become load-bearing that used to be nice-to-have: budget, audit trail, and credential hygiene.
Set the spend ceiling before the trigger
A session-bound agent stops spending when you close the laptop; a self-scheduling one does not. With no documented wake-rate cap, your subscription allotment is the only visible ceiling — size it deliberately, and alert on burn rate, not just balance.
Log which event woke which agent, and why
At-least-once delivery plus agents that spawn agents means reconstructing an incident requires a trail: event id, source, handler decision, threads spawned, actions taken. Build it at the handler boundary — it is the one chokepoint every wake passes through.
Treat every webhook URL as a production API key
For non-GitHub senders the URL is the credential: no expiry, no scoping, manual removal. Store it in a secrets manager, never in shared configs or dashboards, rotate on staff changes, and remove URLs the moment a workflow is retired.
Decide where a person signs off
No session boundary means nobody is implicitly watching. Decide explicitly which actions an event-woken agent may complete alone — and which (customer-facing messages, CRM writes, anything irreversible) queue for approval instead.
The audit-trail point deserves the most emphasis, because it is the one you cannot retrofit after an incident. Our guide to designing audit trails for agents that act without a human present walks the full pattern; the short version is that Amp’s own primitives — the event id, the received-at timestamp, the trusted metadata on GitHub events — give you the raw inputs, but the correlation layer is yours to build. This is also, candidly, the work we do for clients: our CRM automation engagements increasingly consist of wiring event-driven agents into pipelines with exactly these guardrails in place from day one, and our AI transformation practice handles the governance side — budgets, approval gates, and credential policy for non-human actors — before the first production event fires.
08 — ConclusionThe week the session boundary dissolved.
Agents became services this week. Governance is now your job.
Amp’s five-release week is the clearest single-vendor statement yet that coding agents are becoming persistent services — schedulable, triggerable, multiplayer, and able to delegate to each other. All of it is documented only in Amp’s own changelog and API reference; no independent press had touched it as of this writing. That does not make it less real — it makes reading the primary pages carefully more important.
The precise finding worth carrying: trigger security is split. GitHub events get cryptographic signature verification and a deliberate trusted-metadata / untrusted-content separation; everything else gets a secret capability URL that Amp itself calls a credential. Nine days before shipping that inbound surface, Amp replaced static outbound secrets with short-lived OIDC workload identity — proof the team knows what mature credential design looks like, and the standard its own inbound path should be held to.
For ops and CRM teams, the move is not to wait. The capability is genuinely useful today, and the gaps are all manageable with discipline you control: a deliberate spend ceiling, an audit trail built at the handler boundary, webhook URLs treated as production keys, and explicit approval gates on irreversible actions. Agents that never sleep are here. The teams that win with them will be the ones that governed them before the first event fired.