Scaling community support without losing the human touch
At Vercel, the developer community has always been the core of what we do. As it grew, automation was the obvious answer for scaling support operations. But raw automation had limits: questions fell through cracks, routing consumed time, and constant context switching pulled the team away from the work that truly demanded human judgment. And no amount of tooling could replace genuine human connection.
So the team built agents to absorb the work that doesn't require a person: routing, triage, and follow-ups. The result is the Community Guardian, a system we believe anyone — engineers and non-engineers alike — can replicate.
Under the hood: how the Guardian routes support
When a new post arrives, the Guardian analyzes it, checks for duplicates, and routes it to the team member with the right specialty and available bandwidth. Workload balancing keeps each person capped at 10 open questions before new ones are assigned elsewhere, preventing timezone or schedule imbalances from overburdening anyone.
The Guardian also monitors follow-through. After 48 hours without an answer, a question gets reassigned. It pings the team when waiting on more information from the user and flags conversations as resolved once they wind down.
Technically, the Guardian runs on Vercel Workflows with Claude accessed through AI Gateway. This setup checks in every 10 minutes and sleeps between cycles, so it consumes no resources while idle.
Going deeper with a research agent
The Guardian handles logistics; context comes from c0, a separate agent living in Slack where the support team already works. When a team member needs background on a thread, c0 assembles a context package by searching the knowledge base, documentation, GitHub issues, and past conversations. That gives support agents the information they need to respond quickly and accurately, rather than relying on memory.
c0 also closes the loop between support and product teams. Instead of manually auditing a week's worth of posts, the team asks c0 for "top product feedback" and brings concrete data on sentiment and recurring technical hurdles to product discussions.
Measuring what agents freed up
The system's first 23 days show the impact of working this way:
Metric | Outcome |
|---|---|
Initial context gathering | 4,716 first responses triaging issues and gathering logs before a team member arrives |
Thread revival | 1 in 8 "ghosted" threads brought back to life, resulting in 23 confirmed solutions |
Operational scale | Over 1,400 agent runs in a recent two-week period, from stale-checks to auto-solving |
Duplicate detection | 4 duplicate threads detected via vector similarity, with 3 auto-closed at 95%+ confidence |
Every substantive answer still comes from a human. Agents handle everything that happens around those answers — the repetitive triage, the tracking, the follow-ups. With that overhead removed, the team spreads limited human time across complex pair-debugging, relationship building, and creating content for the wider community.
You don't need a title to build this
The key insight is that shipping an agent doesn't require being a developer. The team behind this includes a community manager who isn't writing production code daily — just someone who understands the problems worth solving.
The path started at a talk in Zurich, where the community lead showed traditional automation: scripts, rules, if-this-then-that logic. It functioned but stayed brittle, requiring a new rule for every edge case. Agents turned out to be the flexible layer that could scale genuinely — leaving humans for the interactions we can't replicate.
