Skip to main content

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. This track exists for anyone in the room whose company runs its own product on someone else's infrastructure already, ships fast, and doesn't need the "why agents" pitch — you need the "why here, this hour" pitch, and the answer is that every other track is anchored to one company's pain point and yours doesn't have to be.

That freedom is also the trap. An open brief burns the first twenty minutes on picking an idea instead of building one. So this playbook gives you three shapes that are common enough to fit almost any SaaS or consumer product, worked out in enough detail that you can start from one and swap the specifics for your own in the first five minutes, instead of starting from nothing.

Synthetic data only

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

Three suggested shapes​

Pick one. Don't build all three — that is the fastest way to run out of the hour with nothing deployed.

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

  • Trigger. A support ticket or chat message arrives.
  • What the agent decides. Whether this is a question your own documentation already answers, one that needs a specific account lookup a human should do, or one that is genuinely novel and needs escalation.
  • What it does — the tools. draft_response grounds an answer in your own docs and cites the section it used. escalate_ticket hands off anything the docs don't cover, with a summary of what was already tried.
  • Human in the loop? Selectively. A drafted answer to a documented question can go out fast, maybe even automatically for the clearest cases. Anything touching billing, a refund, or an account-level change waits for a human, because "the agent thought it was fine" is not an answer you want to give a customer who was charged twice.

2. Activation-nudge agent​

  • Trigger. A scheduled sweep of recent signups who haven't reached your product's activation milestone.
  • What the agent decides. Who is stalling, at which step, and whether a nudge is likely to help or whether this user has already disengaged and a nudge would just be noise.
  • What it does — the tool. plan_nudge picks the specific stalled step and drafts a short, relevant message, rather than a generic "come back!" email.
  • Human in the loop? Not for a plain nudge email — sending a helpful reminder is safe. Yes for anything that costs money, like an extended trial or a discount code, because that is a budget decision, not a messaging one.

3. Rollout-guard agent​

  • Trigger. A feature flag or canary release is partway through a staged rollout.
  • What the agent decides. Whether error rates or key metrics for the exposed cohort look worse than the control, and by how much, on every check.
  • What it does — the tool. assess_rollout compares the two cohorts and returns a verdict: healthy, watch, or roll back.
  • Human in the loop? Asymmetric, and worth stating out loud in your demo: rolling back automatically is the safe direction and needs no approval, because it only shrinks the blast radius. Widening the rollout to more users needs a human, because that is the direction that can turn a small mistake into a large one.

The 60-minute cut​

Build shape 1, the support-deflection agent, and cut it to: ground the answer, gate anything that touches an account.

In scope:

  1. A short hardcoded "product docs" corpus — five or six invented paragraphs covering common questions for whatever product you're pretending to be. Invented content only.
  2. A hardcoded array of 5 synthetic support tickets, mixing questions the docs answer cleanly, one the docs don't cover at all, and one that mentions a refund or an account change.
  3. One tool that drafts a grounded, cited answer, and honestly says "escalate" instead of guessing when nothing in the docs fits.
  4. A Workflow that holds anything touching an account or a refund for human approval before it is considered sent.
  5. A one-page queue: every ticket, the drafted answer, whether it cites the docs, and its approval state.

Out of scope, and say so: a real helpdesk integration, real account lookups, sending actual email, authentication, and a general-purpose chatbot that answers anything. If you are building a knowledge base UI, you have lost the hour — build the triage decision, not the library.

The demo that wins. Send a ticket the docs clearly answer and watch the cited draft appear instantly. Then send one mentioning a refund and show it sitting in PENDING APPROVAL even though the agent could have answered it — because the point isn't whether it could, it's that it knows it shouldn't, unattended.

Primitives — exactly three​

  1. AI Search over your own documents. A support answer is only trustworthy if it can point at the paragraph it came from — that is the difference between "the agent thinks your export limit is 10,000 rows" and "your docs say your export limit is 10,000 rows, here's the line." For the hour, simulate the pattern with a hardcoded corpus and a matching tool, as the prompt below does; wiring the real product onto your actual docs is the natural next step once you're back at your desk.
  2. Workflows. Anything that touches an account or moves money has to wait for a human who might be asleep or in another ticket, and it has to be exactly-once so a retry can't send the same refund twice. step.waitForEvent() gives you both for free.
  3. Persistent Durable Object state. Support conversations are not one-shot — the same customer comes back, and an agent that remembers what it already told them is the whole difference between helpful and irritating. An Agent instance addressed by customer id, with this.sql, is that memory, hibernating between messages.

Skip schedules for this shape — a ticket arriving is an event, not something worth polling for (shape 2, the activation nudge, is the schedule-driven version of this track if that fits your product better). Skip Browser Rendering — you're grounded in your own documentation, 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​

  1. Index your real docs, and measure the deflection rate honestly. Once it's grounded in your actual documentation, track what fraction of tickets get a correct, cited answer with no escalation — that number, not a demo, is what earns this a place in your real support stack.
  2. Make the approval queue someone's actual job, not an afterthought. A gate nobody watches is not a gate. Route flagged tickets into whatever your support team already triages from, and track how often they accept the draft unedited versus rewrite it — that ratio is your roadmap for what to automate next.
  3. 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 what happened yesterday. That's a routing decision, not a rebuild — the same per-customer Agent instance, addressed the same way regardless of which channel reached it.

Next: the Level Up page explains each primitive, and the cheat sheet has the snippets. Both are in the sidebar.