I’m Daanveer Hehr, founding Forward Deployed Engineer at Default.
I joined as an intern on July 1st, 2025 to answer support tickets in shared customer Slack channels. Six weeks in, I got a full-time offer as one of our first FDEs and had to decide between returning to California for my last semester of undergrad or staying in New York to keep building.
I stayed.
Since then, I’ve handled everything from technical product implementations, customer support, fixing bugs, and most importantly: building what customers want. I’ve sat directly between our customers and the product for almost a full year, which has helped me see and understand what people are trying to do, where they get stuck, what breaks, and what’s missing.
That’s where our customer support agent (aka: DaanBot) came from.
As an FDE at a Series A-stage company, I’ve answered A LOT of support tickets — enough to realize that the questions often seemed repetitive: the same product quirks, requests, and explanations, week after week. These tickets were different enough to require their own troubleshooting but similar enough to make me wonder if someone—or something—could help offload the repetition.
As every great experiment starts, we started off with a simple question: how could we scale support and customer education across hundreds of shared customer Slack channels? We look at a lot of off-the-shelf agent builders and support platform options, but nothing did everything we needed to provide a great customer experience. Documentation-native chatbots were limited to the strength of the documentation, and built-in support platform agents didn’t meet our standards for conversation quality.
We decided to build our own in-house customer support agent starting with a simple v1: answering product questions accurately.
Version 1: Answering product questions in Slack
Answering product questions is a great initial use case for a customer-facing agent because product questions are asked in high volumes over Slack, and the answer is usually known. The hard part isn’t deciding what to say, it’s finding the right context fast and returning it clearly. For a reasonably narrow scope, this is a perfect use case for an agent.
The first version of DaanBot was simple, and was fed by Plain. When a new support thread was created, the agent would read the customer’s message and would then run a RAG search against Pinecone, where product context and our team’s historical replies were stored. We used Anthropic’s Sonnet 4.5 model to draft replies. Each draft reply would then be reviewed by a member of our team before being sent to a customer over Slack.
This simple initial loop was designed to answer simple product questions better than any doc or generic bot, but it wasn’t intended to carry full conversations or investigate bugs.
Version 2: From support bot to autonomous agent
The real shift came when support moved to Pylon. I rewrote the agent on Vercel’s AI SDK, and that rewrite became DaanBot version 2.
Vercel’s AI SDK made it much easier to handle tool calls, classification, retrieval, and different modes of agent behavior. The agent grew beyond the trivial “read, search, answer” into something with meaningful branches.
Today, DaanBot ingests Pylon threads, classifies them, and searches the related context. Then, it drafts and sends public replies when it should, leaves internal notes when it shouldn’t, and stays out of the way when a human is already on the thread.
It can also analyze images, something I underestimated at the outset. Customers send screenshots all the time (errors, workflow states, config screens) and a significant chunk of the context is in those images rather than the text. DaanBot reads them alongside the thread context and can almost always figure out what the customer is asking about.
I also gave it product path knowledge: slugs and routes in the Default web app. So when someone asks how to do something, DaanBot can actually describe the solution flow across surfaces in the product, instead of describing it generically.
Classification runs on a Haiku-class model, which is much cheaper than the models used for synthesis and resolution. It categorizes issues as either product questions, bug reports, feature requests, billing issues, or other issues. Each label dictates what the agent does next.
The biggest lesson from all of this is to avoid leaving everything to the main model. Agent reliability comes from the harness wrapped around it. In our case, that was building solid classification logic, behavior gates, and scopes around what the agent can/should do (and when), then letting the model work within the parameters.
DaanBot results: 1,750+ support threads handled
Between February and May of 2026, DaanBot managed 1,750+ support threads, sent 1,250+ public replies, and created 2,500+ drafts or internal notes.
The framing I keep coming back to is that most threads aren’t “human or agent.” They’re “agent first, human faster.” A human still touches a lot of threads, but they aren’t starting from a blank page. They’re supported by drafts, notes, and direction.
That’s the part I actually care about. It didn’t replace the team; it made it much easier for us to deliver great customer support at scale, without growing headcount.
Lessons from building an AI support agent
The thing that worked was starting with one repeated, mostly deterministic task, and refusing to expand until that one was solid.
If you find yourself doing the same thing over and over, there’s a process buried in there. It’s usually informal, living in someone’s head, scattered across Slack and threads and calls. But if it has a shape that you can codify, you can give it to an agent.
That’s how DaanBot grew, from one repetitive function to writing drafts, then threads, then Pylon, then classification, then images, then product paths. Next is routing and bug triage.
I’ve watched a fair number of AI projects start by trying to handle everything at once, and it almost never works. There’s no loop to debug because there’s no single loop to begin with.
The other thing I’d flag is that the model isn’t the special part. The reason DaanBot does great work is in the support history, the product knowledge, the real questions, the screenshots, and the slugs. A generic support agent doesn’t have any of that. DaanBot does, because it was built inside the place the work actually happens.
The AI support agent stack
Anthropic handles reasoning on Vercel AI SDK as the framework. OpenAI embeddings plus Pinecone handles retrieval, with Pylon as the support surface. Slack is the human-review loop. Supabase, Vercel, Railway, Doppler, and GitHub cover everything underneath.
The components matter far less than does their assembly. The agent isn’t one model call, it’s a workflow with inputs, retrieval, classification, tools, guardrails, outputs, and human checkpoints. That’s what brings DaanBot from a good demo to a production-grade chatbot.
What’s next: routing, bug triage, and internal agents
The next step is escalation.
Right now DaanBot classifies and assists. The next version should actually move tickets onto the right path. High-confidence bug report? Acknowledge, move it into a bug preview state, flag the team, and stop trying to answer it like a product question. Feature request? Route it. Billing? Billing path.
The version after is what I’m the most excited about: the support agent becoming the front door for a deeper internal agent system. A bug report comes in, the agent reads the message and the screenshots, searches recent product changes, reproduces it in a sandbox, files a Linear ticket with a trace attached, and drafts a PR for an engineer to review.
We may not be there just yet, but the foundation was built with such an endgame in mind.
And this is where it all ties back to Default! DaanBot is technically a support agent, but its underlying structure is a workflow. Default was founded on the same principles: repeated human processes have shapes. Write the shape down, wrap it in context and guardrails, and you’ve got a playbook the machine can follow. That’s the AI-native future I’m excited about: rather than AI bolted onto every product, what if we use AI to govern the way work actually moves through the system?
Takeaways for building reliable support agents
DaanBot started because I was tired of typing the same answers into support threads.
It soon turned into a way to make our support history valuable, and then into a production agent that takes the cold start problem off the hands of our success team so they can dive right in on the hard part—making people happy.
The lesson—if there’s one worth keeping—is that the agents that work don’t start big. They start with one task, strong context, and a clear edge. It’s only these agents that earn the right for more responsibility.
That’s where DaanBot is now.