Amp Turned Agents Into Always-On Services This Week

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.

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.

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.

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.

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.

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.”

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.

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.

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.

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.

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.

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.

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.