agents 0.22.0 → 0.24.0

package/docs/mcp-servers.md

@@ -78,7 +78,11 @@ createMcpHandler(() => createServer(), {
 });
 ```
 
-All upstream SDK v2 handler options pass through. Use `createLegacyMcpHandler` for WorkerTransport, storage, session, and event-store options.
+`createMcpHandler` supports upstream SDK v2 handler options except `bus`, which is not exposed by the Agents SDK. Supplying `bus` throws a `TypeError`.
+
+To publish change events, use the returned handler's `notify` methods, such as `handler.notify.toolsChanged()`. Create the handler once at module scope and reuse it for requests and notifications. Notifications are isolate-local: they do not reach subscriptions in other Worker isolates. See the [handler notification API](https://developers.cloudflare.com/agents/model-context-protocol/apis/handler-api/#publish-list-and-resource-changes) for the available methods.
+
+Use `createLegacyMcpHandler` for SDK v1 WorkerTransport, storage, session, and event-store options. The SDK v2 `bus` option is not available on that handler either.
 
 The handler validates every present `Origin` header before serving the request. It rejects malformed, opaque, and non-HTTP origins. Requests without `Origin` remain valid for non-browser MCP clients.
 

package/docs/queue.md

@@ -1,218 +1,157 @@
-# Queue System
+# Queue
 
-The Agents SDK provides a built-in queue system that allows you to schedule tasks for asynchronous execution. This is particularly useful for background processing, delayed operations, and managing workloads that don't need immediate execution.
+Durable background work for an Agent or any Lifecycle Object. A queued item
+persists a callback name and a payload, runs from the Durable Object's alarm
+loop one item at a time in push order, retries when the callback throws, and
+survives the object leaving memory.
 
-## Overview
+## Queue Lifecycle capability
 
-The queue system is built into the base `Agent` class. Tasks are stored in a SQLite table and processed automatically in FIFO (First In, First Out) order.
+> **Experimental.** The `Queue` capability and the `agents/lifecycle` surface
+> it builds on may change between releases. Agent's established queue methods
+> (`this.queue()` and friends) are stable.
 
-## QueueItem Type
+`Queue` is a reusable Lifecycle capability. A plain Lifecycle Object can
+install it without extending `Agent`:
 
 ```typescript
-export type QueueItem<T = string> = {
-  id: string; // Unique identifier for the queued task
-  payload: T; // Data to pass to the callback function
-  callback: keyof Agent<unknown>; // Name of the method to call
-  created_at: number; // Timestamp when the task was created
-  retry?: RetryOptions; // Retry options (if configured)
-};
-```
-
-## Core Methods
-
-### queue()
-
-Adds a task to the queue for future execution.
-
-```typescript
-async queue<T = unknown>(
-  callback: keyof this,
-  payload: T,
-  options?: { retry?: RetryOptions }
-): Promise<string>
-```
-
-**Parameters:**
-
-- `callback`: The name of the method to call when processing the task
-- `payload`: Data to pass to the callback method
-- `options.retry`: Optional retry configuration. See [Retries](./retries.md) for details.
-
-**Returns:** The unique ID of the queued task
-
-**Example:**
+import { DurableObject } from "cloudflare:workers";
+import { Lifecycle } from "agents/lifecycle";
+import { Queue, type QueueItem } from "agents/queue";
 
-```typescript
-class MyAgent extends Agent {
-  async processEmail(data: { email: string; subject: string }) {
-    // Process the email
-    console.log(`Processing email: ${data.subject}`);
-  }
+export class UploadObject extends DurableObject<Env> {
+  readonly queue = new Queue({
+    callbacks: {
+      processUpload: (
+        payload: { fileName: string },
+        item: QueueItem<{ fileName: string }>
+      ) => {
+        console.log(item.id, payload.fileName);
+      }
+    }
+  });
 
-  async onMessage(message: string) {
-    // Queue an email processing task
-    const taskId = await this.queue("processEmail", {
-      email: "user@example.com",
-      subject: "Welcome!"
-    });
+  readonly lifecycle = Lifecycle.install(this).use(this.queue);
 
-    console.log(`Queued task with ID: ${taskId}`);
+  async enqueueUpload(fileName: string): Promise<string> {
+    const item = await this.queue.push("processUpload", { fileName });
+    return item.id;
   }
 }
 ```
 
-### dequeue()
-
-Removes a specific task from the queue by ID.
-
-```typescript
-dequeue(id: string): void
-```
-
-**Parameters:**
-
-- `id`: The ID of the task to remove
-
-**Example:**
-
-```typescript
-// Remove a specific task
-agent.dequeue("abc123def");
-```
-
-### dequeueAll()
-
-Removes all tasks from the queue.
-
-```typescript
-dequeueAll(): void
-```
-
-**Example:**
-
-```typescript
-// Clear the entire queue
-agent.dequeueAll();
-```
-
-### dequeueAllByCallback()
-
-Removes all tasks that match a specific callback method.
-
-```typescript
-dequeueAllByCallback(callback: string): void
-```
-
-**Parameters:**
-
-- `callback`: Name of the callback method
-
-**Example:**
-
-```typescript
-// Remove all email processing tasks
-agent.dequeueAllByCallback("processEmail");
-```
-
-### getQueue()
-
-Retrieves a specific queued task by ID.
-
-```typescript
-getQueue(id: string): QueueItem<string> | undefined
-```
-
-**Parameters:**
+Queue owns no storage of its own. Each item is one job in the Lifecycle job
+queue, due immediately; Lifecycle owns the physical Durable Object alarm, the
+alarm event loop, retry policy, the deadman pre-arm, and the memory-limit
+circuit breaker. See [Durable Object lifecycle](./lifecycle.md#the-job-queue).
 
-- `id`: The ID of the task to retrieve
+Queue's API is small: callbacks are registered by name in the constructor,
+`push()` creates items typed against that registration, and `get()`,
+`list()`, `cancel()`, and `cancelAll()` manage them. All of these are
+asynchronous and work inside routed sub-agents.
 
-**Returns:** The QueueItem with parsed payload or undefined if not found
+Queue Lifecycle hooks run without ambient host context. Registered callbacks
+are user code, so they run inside the host invocation context with the
+Lifecycle Object available through `getCurrentAgent()`.
 
-**Note:** The payload is automatically parsed from JSON before being returned
-
-**Example:**
-
-```typescript
-const task = agent.getQueue("abc123def");
-if (task) {
-  console.log(`Task callback: ${task.callback}`);
-  console.log(`Task payload:`, task.payload);
-}
-```
+### `new Queue(options?)`
 
-### getQueues()
+| Option      | Description                                                                                                   |
+| ----------- | ------------------------------------------------------------------------------------------------------------- |
+| `callbacks` | Named callbacks `(payload, item) => unknown`. Register in a field initializer so names re-bind on every wake. |
+| `retry`     | Default retry policy: `{ maxAttempts: 3, baseDelayMs: 100, maxDelayMs: 3000 }`. See [Retries](./retries.md).  |
+| `onError`   | Observes an item's terminal failure after its attempts are exhausted. Runs without host context.              |
 
-Retrieves all queued tasks that match a specific key-value pair in their payload.
+### `push(callback, payload?, options?)`
 
-```typescript
-getQueues(key: string, value: string): QueueItem<string>[]
-```
+Queues one item and returns the `QueueItem`. The item is durable before the
+returned promise resolves, and it runs from the next alarm, so the caller
+never waits for the callback.
 
-**Parameters:**
+- `options.retry` overrides the Queue's retry policy for this item.
+- `options.id` sets a stable id. A push with an existing id replaces that
+  item in place, keeping its position in the queue (and superseding a
+  dispatch of it still in flight); use it for idempotent enqueues keyed by
+  your own identifier.
 
-- `key`: The key to filter by in the payload
-- `value`: The value to match
+Once the Lifecycle has started, the item row is written synchronously before
+`push()` returns its promise, so a push made in the same synchronous block as
+your own SQL writes commits atomically with them.
 
-**Returns:** Array of matching QueueItem objects
+### `get(id)`, `list(criteria?)`, `cancel(id)`, `cancelAll(callback?)`
 
-**Note:** This method fetches all queue items and filters them in memory by parsing each payload and checking if the specified key matches the value
+`list()` returns pending items in push order; `{ callback }` filters by
+callback name. `cancel()` returns whether an item was removed; `cancelAll()`
+returns how many were.
 
-**Example:**
+### QueueItem
 
 ```typescript
-// Find all tasks for a specific user
-const userTasks = await agent.getQueues("userId", "12345");
+type QueueItem<T = unknown> = {
+  id: string; // Unique identifier
+  callback: string; // Callback name
+  payload: T; // Data passed to the callback
+  createdAt: number; // Unix timestamp in seconds
+  retry?: RetryOptions; // Resolved retry policy
+};
 ```
 
-## How Queue Processing Works
-
-1. **Validation**: When calling `queue()`, the method validates that the callback exists as a function on the agent
-2. **Automatic Processing**: After queuing, the system automatically attempts to flush the queue
-3. **FIFO Order**: Tasks are processed in the order they were created (`created_at` timestamp)
-4. **Context Preservation**: Each queued task runs with the same agent context (connection, request, email)
-5. **Automatic Retries**: If a callback fails, it is retried with exponential backoff (configurable per task)
-6. **Automatic Dequeue**: Tasks are removed from the queue after successful execution or after all retry attempts are exhausted
-7. **Error Handling**: If a callback method does not exist at execution time, an error is logged and the task is skipped
-8. **Persistence**: Tasks are stored in the `cf_agents_queues` table and survive agent restarts
+## Using the queue through Agent
 
-## Queue Callback Methods
-
-When defining callback methods for queued tasks, they must follow this signature:
-
-```typescript
-async callbackMethod(payload: unknown, queueItem: QueueItem<string>): Promise<void>
-```
-
-**Example:**
+`Agent` installs a `Queue` and resolves callback names to its own methods, so
+`this.queue("methodName", payload)` keeps working with no registration:
 
 ```typescript
 class MyAgent extends Agent {
-  async sendNotification(
-    payload: { userId: string; message: string },
-    queueItem: QueueItem<string>
+  async processEmail(
+    payload: { email: string; subject: string },
+    item: QueueItem<{ email: string; subject: string }>
   ) {
-    console.log(`Processing task ${queueItem.id}`);
-    console.log(
-      `Sending notification to user ${payload.userId}: ${payload.message}`
-    );
-
-    // Your notification logic here
-    await this.notificationService.send(payload.userId, payload.message);
+    console.log(`Processing ${item.id}: ${payload.subject}`);
   }
 
-  async onUserSignup(userData: any) {
-    // Queue a welcome notification
-    await this.queue("sendNotification", {
-      userId: userData.id,
-      message: "Welcome to our platform!"
+  async onMessage(message: string) {
+    const id = await this.queue("processEmail", {
+      email: "user@example.com",
+      subject: "Welcome!"
     });
+    console.log(`Queued task ${id}`);
   }
 }
 ```
 
-## Use Cases
-
-### Background Processing
+| Method                               | Description                                                         |
+| ------------------------------------ | ------------------------------------------------------------------- |
+| `queue(callback, payload, options?)` | Queue a method by name. Returns the item id. Accepts `retry`, `id`. |
+| `dequeue(id)`                        | Remove a pending item. Resolves to whether one was removed.         |
+| `dequeueAll()`                       | Remove every pending item. Resolves to the count.                   |
+| `dequeueAllByCallback(callback)`     | Remove every pending item for one callback. Resolves to the count.  |
+| `getQueue(id)`                       | Read a pending item.                                                |
+| `getQueues(key, value)`              | Pending items whose payload has `key` equal to `value`.             |
+
+## How queue processing works
+
+1. **Validation**: `queue()` checks the callback exists and validates any
+   retry options. Invalid input throws immediately.
+2. **Durable first**: the item is a row in the `cf_agents_jobs` job queue
+   before `queue()` resolves. Items created before this capability existed
+   are migrated out of the old `cf_agents_queues` table on the next start.
+3. **Alarm-driven**: every push re-arms the Durable Object alarm. The
+   Lifecycle event loop runs due items in push order, awaiting each callback
+   before starting the next, in a fresh invocation rather than the request
+   that queued them.
+4. **Retries**: a throwing callback is retried with exponential backoff per
+   its retry policy, emitting `queue:retry` on each extra attempt.
+5. **Terminal failure**: after the last attempt the item is dropped, a
+   `queue:error` event is emitted, and Agent's `onError` (or the Queue's
+   `onError` option) observes the error.
+6. **Recovery**: an isolate that dies mid-callback wakes again on the
+   Lifecycle deadman alarm and resumes the queue, so callbacks should be
+   idempotent.
+
+## Use cases
+
+Queue work that must not block the current request or WebSocket message:
 
 ```typescript
 class DataProcessor extends Agent {
@@ -221,52 +160,31 @@ class DataProcessor extends Agent {
     await this.notifyUser(data.userId, results);
   }
 
-  async onDataUpload(uploadData: any) {
-    // Queue the processing instead of doing it synchronously
+  async onDataUpload(uploadData: { id: string; userId: string }) {
     await this.queue("processLargeDataset", {
       datasetId: uploadData.id,
       userId: uploadData.userId
     });
-
     return { message: "Data upload received, processing started" };
   }
 }
 ```
 
-### Delayed Operations
-
-```typescript
-class ReminderAgent extends Agent {
-  async sendReminder(data: { userId: string; message: string }) {
-    await this.emailService.send(data.userId, data.message);
-  }
-
-  async scheduleReminder(userId: string, message: string, delayMs: number) {
-    // Note: For true delayed execution, combine with the scheduling system
-    // This example shows queueing for later processing
-    await this.queue("sendReminder", { userId, message });
-  }
-}
-```
-
-### Batch Operations
+Split large requests into batches that run one after another:
 
 ```typescript
 class BatchProcessor extends Agent {
-  async processBatch(data: { items: any[]; batchId: string }) {
+  async processBatch(data: { items: unknown[]; batchId: string }) {
     for (const item of data.items) {
       await this.processItem(item);
     }
-    console.log(`Completed batch ${data.batchId}`);
   }
 
-  async onLargeRequest(items: any[]) {
-    // Split large requests into smaller batches
+  async onLargeRequest(items: unknown[]) {
     const batchSize = 10;
     for (let i = 0; i < items.length; i += batchSize) {
-      const batch = items.slice(i, i + batchSize);
       await this.queue("processBatch", {
-        items: batch,
+        items: items.slice(i, i + batchSize),
         batchId: `batch-${i / batchSize + 1}`
       });
     }
@@ -274,56 +192,32 @@ class BatchProcessor extends Agent {
 }
 ```
 
-## Best Practices
+For work that should run at a specific time or on a schedule, use
+[Scheduling](./scheduling.md) instead. Both ride the same Lifecycle job queue.
 
-1. **Keep Payloads Small**: Payloads are JSON-serialized and stored in the database
-2. **Idempotent Operations**: Design callback methods to be safe to retry
-3. **Error Handling**: Include proper error handling in callback methods
-4. **Monitoring**: Use logging to track queue processing
-5. **Cleanup**: Regularly clean up completed or failed tasks if needed
+## Best practices
 
-## Error Handling and Retries
+1. **Keep payloads small**: payloads are JSON-serialized into the job row.
+2. **Idempotent callbacks**: an item can run again after an isolate reset.
+3. **Bounded callbacks**: the event loop awaits each callback, so a long one
+   delays every other job on the object. Detach unbounded work and return.
+4. **Stable ids for dedupe**: pass `id` when the same logical task may be
+   queued more than once.
 
-Queued tasks are automatically retried on failure with exponential backoff. The default is 3 attempts. You can customize this per task:
+## Error handling and retries
 
 ```typescript
-// Retry up to 5 times with custom backoff
 await this.queue("reliableTask", payload, {
   retry: { maxAttempts: 5, baseDelayMs: 500 }
 });
 ```
 
-If you need custom error handling in the callback:
-
-```typescript
-class RobustAgent extends Agent {
-  async reliableTask(payload: { data: string }, queueItem: QueueItem<string>) {
-    try {
-      await this.doSomethingRisky(payload);
-    } catch (error) {
-      console.error(`Task ${queueItem.id} failed:`, error);
-      // The retry system will catch this error and retry automatically
-      throw error;
-    }
-  }
-}
-```
-
-See [Retries](./retries.md) for full documentation on retry options and patterns.
-
-## Integration with Other Features
-
-The queue system works seamlessly with other Agent SDK features:
-
-- **State Management**: Access agent state within queued callbacks
-- **Scheduling**: Combine with `schedule()` for time-based queue processing
-- **Retries**: Built-in retry with exponential backoff. See [Retries](./retries.md).
-- **Context**: Queued tasks maintain the original request context
-- **Database**: Uses the same database as other agent data
+See [Retries](./retries.md) for full documentation on retry options, and
+[Observability](./observability.md) for the `queue:create`, `queue:retry`,
+and `queue:error` events.
 
 ## Limitations
 
-- Tasks are processed sequentially, not in parallel
-- No priority system (FIFO only)
-- Queue processing happens during agent execution, not as separate background jobs
-- Failed tasks are dequeued after all retry attempts are exhausted (no dead-letter queue)
+- Items run sequentially, not in parallel.
+- No priority system (FIFO only).
+- Failed items are dropped after all retry attempts (no dead-letter queue).

package/docs/resumable-streaming.md

@@ -70,7 +70,7 @@ function Chat() {
 - Chunks are batched (every 10 chunks) and flushed to SQLite for performance
 - When a client sends `CF_AGENT_STREAM_RESUME_REQUEST`, the server checks for active streams and responds with `CF_AGENT_STREAM_RESUMING`
 - Stale streams (older than 5 minutes) are cleaned up on restore
-- Stream buffers are garbage collected from a scheduled alarm: completed or errored streams are retained for 10 minutes (a brief reconnect-and-replay grace; the assistant message itself is persisted separately), and abandoned in-flight streams are retained for 1 hour after their last chunk before being reclaimed
+- Stream buffers are deleted in the same transaction that persists the assistant message (the cutover), so a finished turn leaves nothing behind and no cleanup alarm is armed. A buffer a crash left behind is reclaimed when the next stream starts: finished streams immediately, abandoned in-flight streams after 1 hour without a chunk (recovery has until then to rebuild the message from it)
 
 ### Client-side (`useAgentChat`)
 

package/docs/retries.md

@@ -188,7 +188,7 @@ await this.queue("processWebhook", webhookData, {
 });
 ```
 
-If the callback throws, it is retried before the task is dequeued. After all attempts are exhausted, the task is dequeued and the error is logged.
+If the callback throws, it is retried before the item is removed. After all attempts are exhausted, the item is dropped, a `queue:error` event is emitted, and the error is logged.
 
 ## Validation
 

package/docs/routing.md

@@ -601,6 +601,94 @@ Each agent is accessed via its own path:
 
 ---
 
+## Routing to independent Agents
+
+A hub Agent often owns an open-ended set of independent peers: one Durable Object per chat, document, or session for a user. `RoutedAgents` from `agents/routing` codifies that topology as a Lifecycle capability. The hub keeps a durable catalog of public IDs mapped to opaque physical names, and forwards requests under one route segment to the selected Agent:
+
+```typescript
+import { Agent, callable, routeAgentRequest } from "agents";
+import { RoutedAgents } from "agents/routing";
+
+export class ChatAgent extends Agent<Env> {
+  // An ordinary top-level Agent: its own storage, alarms, and placement.
+}
+
+export class UserAgent extends Agent<Env> {
+  readonly chats = new RoutedAgents<ChatAgent, { title: string }>({
+    namespace: this.env.ChatAgent,
+    route: "chats"
+  });
+
+  constructor(ctx: DurableObjectState, env: Env) {
+    super(ctx, env);
+    this.lifecycle.use(this.chats);
+  }
+
+  @callable()
+  createChat(title: string) {
+    return this.chats.create({ metadata: { title } });
+  }
+
+  @callable()
+  listChats() {
+    return this.chats.list();
+  }
+
+  @callable()
+  deleteChat(id: string) {
+    return this.chats.delete(id);
+  }
+}
+
+export default {
+  async fetch(request: Request, env: Env) {
+    // Routes both /agents/user-agent/{id} and the forwarded
+    // /agents/user-agent/{id}/chats/{id}/... paths — RoutedAgents claims
+    // the latter from inside UserAgent once the request reaches it.
+    return (
+      (await routeAgentRequest(request, env)) ??
+      new Response("Not found", { status: 404 })
+    );
+  }
+} satisfies ExportedHandler<Env>;
+```
+
+The client keeps one connection to the hub and one to the active chat, both addressed through the hub:
+
+```
+/agents/user-agent/alice                    -> UserAgent "alice"
+/agents/user-agent/alice/chats/{id}         -> the ChatAgent behind that entry
+/agents/user-agent/alice/chats/{id}/...     -> same ChatAgent, suffix preserved
+```
+
+```tsx
+const user = useAgent({ agent: "UserAgent", name: "alice" });
+const chat = useAgent({
+  agent: "ChatAgent",
+  basePath: `agents/user-agent/alice/chats/${encodeURIComponent(chatId)}`
+});
+```
+
+What the capability guarantees:
+
+- `create()`, `list()`, and `setMetadata()` touch only the hub's SQLite. No target wakes.
+- `list()` orders most-recently-updated first, ties broken by write order rather than by the random entry ID. Each write scans the route's own entries to derive that order — an intentional trade for a route sized like one owner's own catalog, not a route meant to hold thousands of entries.
+- `get(id)` returns an initialized, typed stub for RPC, or `null` for an unknown or deleted ID.
+- A WebSocket upgrade is answered by the target, which then owns the socket. Chat frames never wake the hub. This is the same two-socket shape as connecting to the chat directly, but the hub stays the authority that resolves an ID, so it can gate, migrate, or redirect entries later.
+- `delete(id)` hides the entry first, condemns the target, then removes the row. The target wipes its own storage on its next wake, moments later, and the condemned marker survives interruption. A failed call leaves a hidden row, and calling `delete` again retries.
+- Physical names are random UUIDs that never leave the hub. Clients only ever see entry IDs.
+- `namespace` is any `DurableObjectNamespace`, including a binding to a class exported by another Worker via `script_name`, so the hub and its targets can be deployed and scaled independently.
+- Destroying the hub retries condemning every remaining entry before its own storage is wiped, but this is best-effort: the platform wipes the hub's storage right after disposal regardless of outcome, so a target that is still unreachable after retries is orphaned, with no catalog row left to retry from later.
+
+The catalog stores existence, ownership, and application metadata. Conversation data stays in the target, and a target that needs its hub calls back with `getAgentByName(this.env.UserAgent, ownerName)`. When to prefer this over facets is covered in [Dynamic agents](./sub-agents.md#when-to-use-dynamic-agents).
+
+Two sharp edges to design around:
+
+- **Pick a route that can't collide.** Forwarding matches every occurrence of the route segment anywhere in the path, so if the hub's own name, class, or another one of its own routes is also literally `"chats"`, a coincidental match with no active entry behind it returns `404` instead of reaching the hub's own handler for that path.
+- **A routed suffix can't address a target's own dynamic agents.** `Agent.fetch()` resolves a `/sub/{class}/{name}` marker against the _hub's_ exported classes before this capability's request handling ever runs, so `/chats/{id}/sub/{class}/{name}` is served as a facet of the hub, not forwarded to the chat. Reach a target's dynamic agents through a direct connection to that target instead of through the hub's route.
+
+---
+
 ## Routing with Authentication
 
 Check authentication before routing to agents:
@@ -737,6 +825,23 @@ Get an agent instance by name for server-side RPC or request forwarding.
 
 **Returns:** `Promise<DurableObjectStub<T>>` - Typed stub for calling agent methods or forwarding requests
 
+### `new RoutedAgents(options)` (from `agents/routing`)
+
+A Lifecycle capability installed on a hub Agent with `this.lifecycle.use(...)`. See [Routing to independent Agents](#routing-to-independent-agents).
+
+| Parameter           | Type                        | Description                                      |
+| ------------------- | --------------------------- | ------------------------------------------------ |
+| `options.namespace` | `DurableObjectNamespace<T>` | Target binding the entries are created in        |
+| `options.route`     | `string`                    | One URL-safe path segment this capability claims |
+
+| Method                      | Returns                                              | Description                                           |
+| --------------------------- | ---------------------------------------------------- | ----------------------------------------------------- |
+| `create(options?)`          | `Promise<RoutedAgentEntry<Metadata>>`                | Create an entry without waking the target             |
+| `get(id)`                   | `Promise<DurableObjectStub<T> \| null>`              | Resolve an active entry to an initialized stub        |
+| `list()`                    | `Promise<ReadonlyArray<RoutedAgentEntry<Metadata>>>` | Active entries, most recently updated first           |
+| `setMetadata(id, metadata)` | `Promise<boolean>`                                   | Replace an active entry's metadata                    |
+| `delete(id)`                | `Promise<boolean>`                                   | Hide the entry, condemn the target, then drop the row |
+
 ### `useAgent(options)` / `AgentClient` Options
 
 Client connection options: