Digital Natives: bring your own pain point

Track: Digital Natives · In the room: open — no pre-assigned accounts · Seed use case: bring your own pain point, or pick one of three suggested shapes.

Who this is for

No named accounts, on purpose. For anyone whose company already runs its own product, ships fast, and doesn't need the "why agents" pitch — every other track is anchored to one company's pain point; yours doesn't have to be. That freedom is also the trap: an open brief burns twenty minutes picking an idea instead of building one. This playbook gives you three shapes common enough for almost any SaaS or consumer product, detailed enough to swap in your specifics in five minutes.

Synthetic data only

Invented users, accounts, and tickets. Whatever product you have in mind, build against invented data — this is a shared account and nothing resembling a real customer belongs in it.

Three suggested shapes

Pick one. Building all three is the fastest way to end the hour with nothing deployed.

1. Support-deflection agent — the worked example below

Trigger. A support ticket or chat message arrives.
Decides. Docs-answerable question, human account lookup needed, or genuinely novel and needs escalation.
Tools. draft_response grounds an answer in your docs, citing the section used. escalate_ticket hands off anything docs don't cover, with a summary of what was tried.
Human in the loop? Selectively. A drafted answer to a documented question can go out fast, maybe automatically. Anything touching billing, a refund, or an account change waits for a human — "the agent thought it was fine" isn't an answer for a customer charged twice.

2. Activation-nudge agent

Trigger. A scheduled sweep of recent signups who haven't hit the activation milestone.
Decides. Who's stalling, at which step, and whether a nudge would help or the user's already disengaged.
Tool. plan_nudge picks the stalled step and drafts a relevant message, not a generic "come back!" email.
Human in the loop? Not for a plain nudge email — safe. Yes for anything costing money, like an extended trial or discount code — a budget decision, not a messaging one.

3. Rollout-guard agent

Trigger. A feature flag or canary release is partway through a staged rollout.
Decides. Whether the exposed cohort's error rates or key metrics look worse than control, and by how much, on every check.
Tool. assess_rollout compares the two cohorts and returns a verdict: healthy, watch, or roll back.
Human in the loop? Asymmetric — worth stating in your demo. Rolling back automatically is safe, no approval needed, since it only shrinks blast radius. Widening needs a human, since that can turn a small mistake into a large one.

The 60-minute cut

Build shape 1, the support-deflection agent: ground the answer, gate anything touching an account.

In scope:

A short hardcoded "product docs" corpus — five or six invented paragraphs of common questions. Invented content only.
A hardcoded array of 5 synthetic tickets — questions the docs answer cleanly, one not covered at all, one mentioning a refund or account change.
One tool drafting a grounded, cited answer, saying "escalate" instead of guessing when nothing fits.
A Workflow holding anything touching an account or refund for approval before it's sent.
A one-page queue: ticket, drafted answer, whether it cites the docs, approval state.

Out of scope, and say so: a real helpdesk integration, real account lookups, actual email, auth, and a general-purpose chatbot. Build the triage decision, not a knowledge base UI.

The demo that wins. Send a ticket the docs clearly answer — the cited draft appears instantly. Send one mentioning a refund — it sits in PENDING APPROVAL even though the agent could have answered it, because the point is that it knows it shouldn't.

Primitives — exactly three

AI Search over your own documents. A support answer is trustworthy only if it points at the paragraph it came from — "the agent thinks the limit is 10,000 rows" vs. "your docs say so, here's the line." Simulate with a hardcoded corpus for the hour; real docs is the natural next step.
Workflows. Anything touching an account or money must wait for a human who might be asleep, and be exactly-once so a retry can't send the same refund twice. step.waitForEvent() gives both for free.
Persistent Durable Object state. Support conversations aren't one-shot — the same customer returns, and remembering what was already said is the difference between helpful and irritating. An Agent instance addressed by customer id, with this.sql, is that memory, hibernating between messages.

Skip schedules — a ticket arriving is an event, not worth polling for (shape 2 is the schedule-driven version of this track if that fits better). Skip Browser Rendering — you're grounded in your own docs, not a third party's page.

Paste-ready starter prompt

Scaffold the starter first:

npm create cloudflare@latest -- team-natives-support-deflection --template cloudflare/agents-starter
cd team-natives-support-deflection

Then paste this into your coding agent:

I'm working in a fresh clone of Cloudflare's agents-starter template. The agent code is in
src/server.ts and the React client is in src/client.tsx. I have 60 minutes. Keep the
existing chat agent working — extend it, don't replace it.

Build a support-deflection agent that grounds every answer in a docs corpus and gates
anything account-touching behind human approval.

1. Add a hardcoded "docs corpus" array in a separate file: 6 short invented paragraphs, each
   with a topic id and the paragraph text, covering things like pricing tiers, export
   limits, password reset, and cancellation policy. Invented content only.

2. Add a hardcoded array of 5 synthetic support tickets to src/server.ts: ticketId, customer
   name, and the message text. Make 3 clearly answerable from the docs corpus, 1 not covered
   by any paragraph, and 1 that asks for a refund.

3. Add a tool called draft_response. Given a ticketId, use a Workers AI model to find the
   best-matching corpus paragraph (or none) and return JSON: matchedTopicId (or null),
   draftAnswer (citing the paragraph if matched), needsHumanReview (true if the message
   mentions billing, refund, or an account change, OR if matchedTopicId is null), and a
   one-sentence reason for that flag. Never invent an answer not supported by the corpus —
   if nothing matches, needsHumanReview must be true and draftAnswer should say the docs
   don't cover this.

4. Add a Cloudflare Workflow called TicketResponse in a new file, with steps as step.do():
     a) draft — call draft_response and store the result
     b) await_approval — ONLY if needsHumanReview is true, use step.waitForEvent() with a
        generous timeout, waiting for an event of type "response-decision". If false, skip
        straight to sent.
     c) finalize — record whether the response was sent, edited-then-sent, or declined, and
        by whom
   Import WorkflowEntrypoint, WorkflowStep and WorkflowEvent from "cloudflare:workers", and
   add the workflow binding to wrangler.jsonc.

5. Store each ticket's draft and final state in the Agent's SQLite storage using this.sql,
   keyed by customer name so a repeat customer's agent instance can see their prior tickets,
   addressed via routeAgentRequest or an explicit name lookup.

6. Add routes:
     POST /ticket/:ticketId   starts a TicketResponse workflow for that ticket
     GET  /queue              HTML page: every ticket, the draft answer, cited topic (or
                               "not covered"), and approval state, with PENDING APPROVAL
                               shown prominently
     POST /decide/:ticketId   sends the "response-decision" event with approved true or
                               false and an agent name from the body

Requirements: TypeScript. Route every Workers AI call through AI Gateway by passing
{ gateway: { id: "agenthack" } } as the options argument. Run `npx wrangler types` after
changing wrangler.jsonc. Then deploy with `npx wrangler deploy` and give me curl commands
that show one ticket auto-drafting cleanly and the refund ticket waiting for approval.

The Worker name team-natives-support-deflection follows the shared-account rule <team_prefix>-<slug>. Eight teams deploy into one account today, so if the Scoping agent issued you a different prefix, use that one instead. If you build a different shape, keep the prefix and swap only the slug.

What "production" looks like

Index your real docs, measure the deflection rate honestly. Track what fraction of tickets get a correct, cited answer with no escalation — that number, not a demo, earns this a place in your support stack.
Make the approval queue someone's actual job. A gate nobody watches isn't a gate. Route flagged tickets into your team's existing triage and track how often they accept the draft unedited — your roadmap for what to automate next.
Let the agent's memory span channels, not just tickets. A customer who emailed yesterday and chats today should reach an agent that already knows — a routing decision, not a rebuild, using the same per-customer Agent instance regardless of channel.

Next: Level Up explains each primitive, the cheat sheet has the snippets.

Who this is for​

Three suggested shapes​

1. Support-deflection agent — the worked example below​

2. Activation-nudge agent​

3. Rollout-guard agent​

The 60-minute cut​

Primitives — exactly three​

Paste-ready starter prompt​

What "production" looks like​