Cloudflare
Connect 2026

San Francisco · 19–21 October 2026

Some of the sessions

The Agentic Internet: Building and securing what comes next
How publishers can thrive and monetize in the age of AI agents
Why modern software engineering needs Durable Objects
SocialKit: AI social toolset built on Cloudflare
Cloudflare Workers monorepo
Building the future of AI
Securing and scaling the future of AI and agentic platforms
Building EmDash: 10 months of AI, what worked, what broke, what changed
Workers Preview: Isolated environments for every change your agent makes
Leading with curiosity in the era of AI

How publishers can thrive and monetize in the age of AI agents

Content Independence Day: Cloudflare's push to give publishers control over AI crawlers
Frontier AI companies are committing to crawler transparency
Better tooling for detecting and managing crawler traffic
Shift from pay per crawl to pay per use: publishers get paid when an AI answer uses their content, not just when a bot fetches it
Agents and crawlers take the traffic. Publishers are still figuring it out, and adoption is small

Talk slide: Content Independence Day, with a transparency deadline, a business insights dashboard, pay per use and AI search

Talk slide: Transparency and control in an agentic era, with commitments from Microsoft, Apple and Google

Talk slide: a Business Insights dashboard of AI bot traffic and crawl-to-referral ratios

Talk slide: From pay per crawl to pay per use, with Ceramic and You.com as examples

Talk slide: OpenAI signals research pilot, hypothesis and early findings

Talk slide: Best practices and key trends for managing AI crawlers

Say: the talk was aimed squarely at publishers.

Content Independence Day follow-ups: a Sept 15 deadline for crawler transparency (training vs. search crawlers), the Business Insights dashboard, pay per use + AEO ("we have buyers"), and the OpenAI signals research.

Commitments: Microsoft will respect "no training" in robots.txt (targeted early 2027); Apple is building a URL-level inspection tool; Google adds URL-level transparency tools for Google-Extended. Cloudflare's requirements for an accountable crawler include that opting out of AI training must not affect search results.

Pay per use examples: Ceramic (per-query, for non-paywalled news blocked from AI crawlers) and You.com (paywalled archives, real-time bidding). AI companies also send back data on queries, citations and answer rankings.

OpenAI pilot (July 2026, early findings October 2026): helped OpenAI discover unknown pages and important updates; site owners saw fewer unnecessary crawler requests.

Speaker: TODO.

Why modern software engineering needs Durable Objects

Ashley Peacock, Cloudflare

AI agent traffic grew 1,700% in a year, and shared infrastructure fails all at once
A Durable Object is a small but mighty server with its own database
Many small, isolated objects: one busy agent can't take everyone down
Isolates are ~100× lighter than containers, cheap enough for an agent per conversation
Coming: agents that run on without a client, deploys that don't drop connections, automatic retries

Talk slide: Durable Objects, a small but mighty server with its own database

Talk slide: Scale out by adding objects, one big service versus one object per entity

Talk slide: The Agents SDK is built on Durable Objects, with a code example

Talk slide: Four common mistakes, from the hot singleton to memory starting fresh

Talk slide: Long-running agents no longer need a client

Talk slide: Ship code without interrupting your applications and agents

Two problems: AI traffic surges (Cloudflare: agent traffic up 1,700%+ in a year) hit shared databases and containers that can't scale overnight; and everyone needs somewhere cheap to run many agents.

Each object has its own SQLite on the same machine: no lock contention, reads typically under a microsecond. Created on demand, scales to zero, idle costs only storage. Limits per object: 10 GB, 1,000 req/s, 128 MB memory.

Four common mistakes: the hot singleton (per Slack server instead of per channel), accidental placement (calls from one cloud region put every object there), WebSockets that never sleep (use the hibernation API), memory starts fresh (persist anything critical).

Coming: pending I/O keeps objects alive up to 15 min each (default from compat date 2026-10-01); shutdown hook; graceful deploys, with old code allowed up to 24 h; automatic safe retries. Not all public yet.

Q&A: shard per task or conversation, not per user (objects are single-threaded). Avoid chains of objects. D1 is built on Durable Objects; use it for shared config.

Demo moment: this deck syncs through a Durable Object right now. Viewers' cursors are on screen.

SocialKit: AI social toolset built on Cloudflare

Matan Lachmish, Taka

Generic AI makes social "slop": off-trend, off-brand, hard to edit
SocialKit turns a brief into on-brand carousels and videos, also for other agents over MCP
Pipeline: brand → format → visual direction → assets → compose
An LLM judge scores each draft and sends fixes back to the right step
Editable, layered output. ~2,000 agents in production on Cloudflare

Talk slide: a bakery's original carousel next to generic AI output and SocialKit output

Talk slide: What good social looks like, a bakery carousel with four image panels

Talk slide: One brief, an editable result, at the compose step

Talk slide: Creating good social content is hard

Talk slide: A complete creative workflow, 1,970 agents in production

Talk slide: Give your agent a social creative engine

Talk slide: SocialKit, our social creative engine

Taka is a startup (part of monday.com) that runs social media for businesses. Content creation turned out to be the hard part, so they built SocialKit, now also offered as an MCP API.

Demo: a real Boston bakery's paper-tear carousel. A generic LLM gave obvious AI slop; adding "use SocialKit" to the same prompt gave something close to the bakery's own post.

Assets come from three places: provided by the user, scraped from the website or social profiles, or generated. The judge took the demo post from 50 to 62 to 74 out of 100 (headline off-brand, pastry too big, last slide not a real CTA).

Started 5–6 months ago, "thousands of agents every day". Slide: 1,970 agents in production, generation under a minute. Per the session abstract, it runs on D1, Durable Objects, Workers, Containers, Queues and AI Gateway.

Cloudflare Workers monorepo

Laura Poss, Block

4 engineers, ~20 accounts, 250+ zones, hundreds of Workers, all in one monorepo
The platform team builds guardrails so app teams can ship their own Workers
Shared code as versioned npm packages; a Go CLI creates new Workers from templates
Each Worker deploys on its own, with gradual rollouts, approval at each step, and rollback
Guardrails: secrets and code never change in the same PR

Talk slide: What we built, TypeScript, Go and Buildkite

Talk slide: Where we started, Terraform plus TypeScript equals a sad face

Talk slide: Who we are, 4 engineers, 20 accounts, 250+ zones

Talk slide: Shared code, reimagined, from relative imports to packages

Talk slide: CI/CD worker secret changes, the pipeline asking Wrangler which secrets exist

Talk slide: CI/CD high level, three Buildkite pipelines

Talk title slide: Cloudflare Workers monorepo, Laura Poss, Block

Block = Square, Cash App, Afterpay, Bitkey and others. By default one Worker per zone; a new zone almost every day. The abstract says 216+ Workers.

Where they started: Workers inside the Terraform monorepo, before the v5 provider. You had to compile by hand (forget it and nothing shipped), there were no gradual releases (a bug in a key Worker = incident), one group could approve any release, and shared code was copied in by relative imports.

Now: TypeScript monorepo, pipeline logic in Go, Buildkite CI with three pipelines (PR, merge, per-Worker deploy). Rollouts use wrangler versions with a pattern from build.json (e.g. 50/100) and a manual approve-or-rollback at each step. Deleting build.json deletes the Worker.

Accepted limitations: shared package version drift, and only a subset of Wrangler is supported (e.g. no Containers yet).

Building EmDash: 10 months of AI, what worked, what broke, what changed

Matt Kane, Cloudflare

A whiteboard session on how the EmDash open-source project is run with AI
Bots with a near-unlimited token budget automate the project management
They triage, test PRs, and open and close issues

Workers Preview: Isolated environments for every change your agent makes

A prompt to run in your terminal: the agent clones a repo and deploys it to Cloudflare
Hello-world level, nothing new if you deploy every day
Takeaway: no multi-Worker previews yet; coming later with Cloudflare's CI tools

Mostly drawing on a board and talking with the audience, so there were few slides.

Background, from Matt's separate day-1 talk ("EmDash: The secure WordPress successor for humans and agents"), in case anyone asks what EmDash is: an open-source (MIT) TypeScript CMS on Astro that runs on Workers or Node. Built-in MCP so agents can do what humans can, with granular permissions. Plugins sandboxed with declared capabilities, like mobile apps. Started in January, 1.0 this autumn. The Cloudflare blog runs on it.

Freepress angle? Agents doing the project chores: triage, PR testing, issue hygiene.

Workers Preview (a Build It session): honestly not for us. We already do this every day. The interesting bit is what's missing: previews for multi-Worker setups, promised later with Cloudflare's CI tooling.