---
title: "Cloudflare Agents, meet Blyp"
description: "Follow RPC calls, tool results, schedules, workflows, and recovery events with Blyp's new Cloudflare Agents connector."
canonical_url: "https://www.blyp.dev/docs/changelog/2026-10-23"
markdown_url: "https://www.blyp.dev/docs/changelog/2026-10-23.md"
last_updated: "1970-01-01"
x_farming_labs_generated_preamble: true
---

# Cloudflare Agents, meet Blyp
URL: /docs/changelog/2026-10-23
LLM index: /llms.txt
Description: Follow RPC calls, tool results, schedules, workflows, and recovery events with Blyp's new Cloudflare Agents connector.

## Cloudflare Agents, meet Blyp

An agent's work continues beyond a single request. A tool returns a result, a scheduled callback runs later, an MCP connection changes state, or a stalled chat stream triggers recovery. Understanding what happened means following those events with enough context to connect them.

Blyp v0.1.36 adds `@blyp/core/ai/cloudflare`: a connector for the Cloudflare Agents SDK's native observability events. Attach `blypObservability()` to your agent and get structured records for its lifecycle, RPC calls, tools, schedules, workflows, MCP activity, recovery, and errors.

### Start with one property

The connector targets Agents `~0.30.0`. Add it to your existing Workers project:

```bash
bun add @blyp/core@0.1.36 agents@~0.30.0
```

The pinned Agents SDK also requires Zod and MCP peers. If your application does not already provide them, install:

```bash
bun add zod@^4 @modelcontextprotocol/client@2.3.1 @modelcontextprotocol/server@2.3.1 @modelcontextprotocol/sdk@1.32.1
```

Keep any additional SDK peers your application's features require. Then set the agent's `observability` property:

```ts
import { Agent } from "agents";
import { blypObservability } from "@blyp/core/ai/cloudflare";

export class SupportAgent extends Agent {
  override observability = blypObservability({
    metadata: { service: "support" },
  });
}
```

Keep your existing Durable Object bindings, migrations, and Wrangler `nodejs_compat` configuration. Blyp needs no additional binding or storage for this connector.

By default, records go to the Workers console through `console.info`, `console.warn`, or `console.error`. The default writer works without loading Blyp's Node logger, reading project configuration, or writing files or SQLite queues. Configure its redaction through `blypObservability({ redact: ... })`; `initWorkersLogger()` does not configure this default writer.

### See the event and its context

Each selected native event produces an `ai_agent_event` record with a unique group ID. The `ai` object identifies Cloudflare as the provider and retains the native event type, source timestamp, and agent class and instance names when available.

For example, a `tool:result` event can produce these fields within the record:

```json
{
  "type": "ai_agent_event",
  "level": "info",
  "ai": {
    "sdk": "cloudflare-agents-sdk",
    "provider": "cloudflare",
    "operation": "cloudflare.agent.event",
    "eventType": "tool:result",
    "agentName": "SupportAgent",
    "instanceName": "support-42",
    "timestamp": "2026-10-23T09:00:00.000Z",
    "attributes": {
      "toolCallId": "call-123",
      "toolName": "lookup_order"
    },
    "metadata": {
      "service": "support"
    }
  }
}
```

Known scalar attributes carry technical context such as request and workflow IDs, method names, callbacks, timings, counters, and statuses. This gives you fields to filter and correlate across events.

Blyp also assigns severity. Events ending in `error`, `failed`, or `exhausted`, events carrying an error, and events with an error or failed status become error records with `ai.hasError: true`. Retry, warning, stalled, interrupted, deadline, degraded, and conflict endings map to warnings. Other events use informational severity, including cancellations and approval rejections.

### Capture the detail you need

Detailed native payloads are off by default. Blyp keeps an allowlist of technical attributes and omits unknown fields, free text, error text, email addresses and subjects from email payloads, and authorization URLs from its default records.

You can narrow the event selection, exclude a tool entirely, or opt into payload capture for a workflow that needs more detail:

```ts
import { blypObservability } from "@blyp/core/ai/cloudflare";

const observability = blypObservability({
  operation: "support.events",
  events: ["rpc", "rpc:error", "tool:result", "schedule:error"],
  metadata: { service: "support", environment: "production" },
  capture: { payload: true },
  exclude: {
    toolNames: ["private_lookup"],
    payloadPaths: ["result.internal"],
  },
  redact: { keys: ["customerEmail"] },
  limits: { maxContentBytes: 16_384 },
});
```

Enable payload capture when you are comfortable storing the application content those events contain. Recognized credential fields and MCP authorization URLs are removed even with capture enabled. URL credentials, query strings, and fragments are stripped. Exclusions and redaction apply before a record reaches a custom logger, too.

The content budget applies separately to attributes, payload, and metadata. Each defaults to a maximum of 16,384 serialized UTF-8 bytes. If one exceeds the budget, Blyp omits that value and sets `ai.truncated: true`, keeping the event's identifying fields.

### Keep Cloudflare diagnostics working

The connector forwards the original event to Cloudflare's `genericObservability` by default, preserving native diagnostics-channel and Tail Worker behavior.

Blyp's filters, redaction, and limits apply to the Blyp record. The native forwarding path receives the original event, so excluding a tool from Blyp does not exclude it from Cloudflare diagnostics. Use `forward: false` to disable forwarding, or provide another observability implementation as the forwarding destination.

Both paths run independently. A forwarding failure does not prevent Blyp logging, and a logger failure does not prevent forwarding. Emission is synchronous and best effort, with at most one generic failure warning per adapter instance. Asynchronous observer rejections are caught, but the connector does not extend the Worker invocation's lifetime to await delivery.

If you already have a compatible structured logger, pass it through the `logger` option. The connector requires only its `createStructuredLog` method; a Blyp Workers request logger satisfies that interface.

### Follow the agent's runtime activity

This connector produces one record per native event. Model transcripts, token usage, aggregated turn summaries, and direct `env.AI.run()` calls are outside its scope. Blyp's other model tracing adapters have their own runtime requirements.

For agents running on Cloudflare, this gives you a direct starting point: attach the observer, keep payload capture off, and follow the lifecycle, tool, scheduling, and recovery events your agent emits.

Read the [Cloudflare Agents guide](/docs/ai/cloudflare) for the full configuration, or explore the [connector source](https://github.com/Blyphq/blyp/tree/main/src/ai/cloudflare).

## Sitemap

See the full [sitemap](/sitemap.md) for all pages.
Docs-scoped sitemap: [/docs/sitemap.md](/docs/sitemap.md).
Well-known sitemap: [/.well-known/sitemap.md](/.well-known/sitemap.md).