Bringing AI in at Cloudflare

Spot stalls in onboarding when the sandbox looks healthy

Published Nov 1, 2026

You’re a forward deployed engineer working with Cloudflare’s customer success team. The team is in the room.

The setting

's is a platform for deploying and running application code, static sites, and full-stack applications around the world. Developers use it without managing servers.

A working sandbox does not settle whether onboarding is moving.

Telemetry protects a consistent view of technical activity, while customer notes preserve exceptions to the agreed plan.

Who you’d be doing this for

“We got the sandbox running last week, and today's call started with the same setup questions instead of our launch blocker.”

Aitana Lopes · Application Engineering Lead · a character in this brief

Leads a customer team moving its first application into production and depends on onboarding conversations to clarify the next technical step.

What is at stake

CSMs disagree about whether new accounts with working sandboxes have stalled or agreed to pause. You decide whether ambiguous notes can trigger a stalled-step flag or require a CSM to confirm the account's current plan first.

Why it isn’t already fixed

Every obvious fix costs something else. That’s the part you’d have to decide.

  • standard milestones vs customer-specific agreements
  • early stall signals vs planned pauses
  • telemetry consistency vs conversational context
  • broad blocker coverage vs irrelevant support activity

Why Cloudflare

Production adoption of Workers, R2, and D1 matters more than successful sandbox provisioning in the technical onboarding journey.

Written with these in mind

Customer-embedded integration engineersForward deployed engineersSolutions engineers building operational AI systems

Not your kind of problem? 100 more at Cloudflare, or browse every organization.

Where the organization context comes fromThe postings this brief was written from, and the reporting read before it.

The organization context comes from public information. The situation and characters are written for the brief.

Job postings it was written from

Public descriptions of the work at Cloudflare. They are listed as sources, not as openings. The lines under a posting are its own words, where it meets this brief.

  • Technical Support Engineer - Developer Platform (opens in a new tab)
  • Technical Support Engineer, Developer Platform (opens in a new tab)
    • Replicate reported behavior in a sandbox environment, analyze platform logs and request telemetry, and guide customers on enabling observability and tracing to isolate root causes.
    • As a Technical Support Engineer on our Developer Platform team, you’ll help developers build and run applications on Cloudflare Workers, Workers AI, Durable Objects, R2, D1, Workflows, Pages, Queues, and Workers KV.
  • Senior Customer Engineer, Digital Native - Vancouver BC (opens in a new tab)
    • Customer Adoption & Value Realization: Provide oversight to technical onboarding and implementation, but not execute the implementation, serving as the primary executive and engineering contact for the customer.
    • Technical Validation: Partner closely with Account Executives to lead technical deep-dive discovery, capture business requirements, and map complex customer infrastructure - DNS, CDN, Zero Trust, Network Security, Workers - to fit-for-purpose Cloudflare architectures and bespoke solutions. .
  • Technical Support Engineer, Application Services (opens in a new tab)
    • You will work with our largest and most technically sophisticated customers on a variety of technical support issues to ensure they can deploy and operate Cloudflare's App Services solutions with confidence.
    • Work with Engineering and Operations teams to remediate issues, suggest steps to mitigate, and apply the appropriate mitigation, when applicable.

This is the setup. The work is inside.

Running it puts you in the room: the full situation and its constraints, stakeholders who push back in their own words, and the decisions that are yours to make. What you produce becomes a Day One Plan — work you can show someone instead of describing.

Other live briefs connected to this one, and what connects them.

Similar problems at other organizations

Like this one, each of these is about the everyday tools people rely on silently breaking.

The same setting, from another role

Each is set around Cloudflare’s Cloudflare Workers, written for a different role. They’re separate briefs, not the same scenario.

Other problems with a similar purpose

In each of these, as in this one, the aim is to turn observed user friction into a fast, confident decision that visibly restores a better experience.