Four attempts in under two years, three of them failures. How customer success at Atlan went from a chatbot you had to ask to an agent that puts the draft in your inbox before you ask. By Dhruv Saharya.
Excavation work used to be a big problem before customer calls. Take an account that’s been with Atlan for three years: that’s something like 100 calls, 20 key people identified across the customer’s organization, and 300 support tickets, seven of them from just the last week. Before a call with an account like that, a CSM had to dig through as much as they could by hand, piecing together what actually mattered from wherever it happened to live: calls in one tool, tickets in another, usage numbers somewhere else, whatever the CSM who last ran the account happened to remember. The size of that dig set a ceiling on how many accounts any one person could carry and how much attention each customer could get.
This wasn’t the first time we’d tried to fix that. Starting back in 2024, we’d already built one tool for searching internal information and another for pulling account data against a set of saved questions. Both helped, in narrow ways, but neither remembered anything between conversations.
Here is the same moment now. A few minutes after a customer call ends, our Customer Success agent Relay puts a draft message in the CSM’s email. “Based on your last conversation, here’s what I’d suggest sending: …” This isn’t a summary or a reminder. It’s a finished email, already sitting in the CSM’s draft folder, waiting for them to read it and hit send.
Relay does much more than this, thanks to lots of work and iterations from its start as a simple chatbot. But Relay isn’t just about writing emails more easily or making decks faster or helping CS people collaborate better — though it does that. Building Relay was part of Atlan’s larger work to become a frontier company, using AI thoughtfully to get more ambitious, not just more efficient. In Customer Success, this is all about empowering CSMs to spend less time on account notes and manual work and more time with the customer helping them do their life’s best work.
Getting from that first chatbot to an autonomous Customer Success agent is the real story of how customer success at Atlan became AI-native. Here’s the story of how Relay was built, version by version, with everything we broke and learned along the way.
Two agents on WhatsApp
When OpenClaw launched in late 2025, I started experimenting with it along with Himanshu, who leads field engineering at Atlan. We decided to see what would happen if we connected our own Claws to our messaging accounts, gave both agents some context about who we were, and pointed them at the same problem described above: the excavation work, the calls and tickets and account history scattered across a dozen places that every CSM had to reassemble before they could do anything useful.
We let the agents loose to talk to each other, and they immediately went wild. The agents exchanged something like a hundred messages. At some point, both worked out from Atlan’s org chart that Himanshu was my skip-level manager, and Himanshu’s agent started assigning tasks to mine. Mine did the work and reported back, and this went on until Himanshu’s agent was satisfied. Then, on their own, the two agents decided the result was worth showing to our CEO for approval. Needless to say, we didn’t carry out that meeting request.
Chaotic as that experiment was, it was a wakeup call. We realized that the technology was good enough to build something autonomous inside customer experience. And after all, if we were helping our customers become AI-native, we should be ready to walk the walk. Himanshu happened to be in India that week instead of the Bay Area, so I flew out to meet him. We turned his house into the site of a mini hackathon, spending two days in our harnesses and at a whiteboard, and what came out of it was the foundation of Relay.
Our previous attempts
Our first real try at solving this problem, back in early 2025, functioned like a “talk to the data” chatbot inside a Slack channel. A CSM would ask a question about a customer, pick which data source to pull from and how many days of history to include, and get an answer back in the thread. It helped, but it wasn’t agentic in any real sense. Every question was a fixed pile of context assembled by hand. Pile in too much and the answers just got worse, not better. Push far enough and it couldn’t answer at all. Around the same time, we tried automatically posting a summary note into a shared document after every call. That failed almost immediately, because no one reads a note they never asked for.
The second attempt in June 2025 let the agent decide for itself what to pull, using an agent framework built on n8n instead of a human choosing the inputs by hand. It hit the same wall from the other direction. There’s still only so much a model can fit into its context window at once, and now we were also paying, quite literally, every time it decided to look at one more thing.
The third attempt was a proper multi-agent system, rolled out just a couple months later. An orchestrator agent we called Hermione routed a question to specialist sub-agents underneath it: one focused on product data, one on strategy, one on commercial context, and so on. This one actually worked decently well. We launched it at a company-wide meetup and within months, most of the team had started using it. But it had real limits too. It was slow. Its output had that flat, over-explained tone that gives AI writing away on sight. And most importantly, it never stopped being something a CSM had to ask. It was a better copilot, but it was still a copilot.
Three failed tools in under a year might seem like a bad track record, but it’s more a measure of progress. At Atlan, we like to try new internal tools in the open, let them fail, and keep the parts that worked. What all three attempts had in common is that each one got better at answering questions about customers, but none could do anything with the answer. This lined up with a lesson we had already learned through our work building the context layer: getting AI right depends less on model intelligence and more on getting the underlying context right.
Teaching Relay to remember
With Relay, the fourth attempt rolled out in early 2026, we started differently. Before asking it to do anything, we onboarded it the way we’d onboard a person. It read the top five books on customer success as a discipline. It read ten of Atlan’s blog posts to better understand the company. It got our values document and org chart, and a walkthrough of all the different tools the CS team was using.
From there, Relay was built around the same principle as autonomous cars: it needs to sense the current state of customer accounts, plan next steps based on that state, and then act on that plan.
This meant that getting the first step right was crucial — get the current state wrong and nothing that follows will be right. Though what we built isn’t quite “state.” It’s closer to long-term memory. Relay works to understand and store each account’s larger context: who the stakeholders are and what they care about, what the customer is actually trying to achieve, the current picture in both numbers and plain language, and a running list of risks and opportunities.
Relay doesn’t simply validate the CSM’s plan. It surfaces a critical missing signal: the executive buyer’s 10-month disengagement.
One early assumption didn’t hold up, and fixing it produced one of the biggest jumps in quality. Our initial bet was that call recordings would carry most of what Relay needed to know. We quickly learned that some of the most important signals were sitting in email threads and Slack messages that never came up on a call at all: a question sent straight to support, a conversation a buyer had with someone on our marketing team, a Slack message a champion sent at 11pm. Once those became inputs too, not just calls, the picture Relay worked from got noticeably sharper.
Before it went out to the wider team, we also ran Relay through a set of evals. This was critical because, early on, Relay would give wrong answers confidently, which is worse than not answering at all. What looked like an intelligence problem turned out to be a context problem, since it simply didn’t have what it needed to reason correctly yet. One of the CSMs took on this problem by building a set of scenarios, each with a defined right answer. They then treated Relay like a new intern, first asking it to tackle these scenarios and then giving it real CS problems, reviewing what came back, and calling out anything that missed the mark.
The promotion Relay read as good news
One example of this learning started with a promotion. The lead stakeholder for one of our largest customers moved into a different role within his company. For him, it was good news, so Relay logged it as a routine stakeholder update and moved on. What it hadn’t learned yet was the question underneath: did the workstream we depended on still have an owner? Nobody noticed until a colleague mentioned in passing that they weren’t sure who was in charge of it anymore.
Relay wasn’t missing something. In fact, it had weighed two correct but contradictory signals, a departure and a promotion, against each other and chose the more cheerful conclusion. Now a stakeholder changing roles gets flagged everywhere that matters, and Relay makes sure to also consider any potential downsides of otherwise good news.
That pattern repeated itself version after version: we kept adding context via skills, knowledge and expertise, testing Relay, taking in feedback, and learning gradually. Eventually Relay was getting things right most of the time, improving its memory and building trust along the way.
The moment it clicked
We realized that Relay was actually working when we launched Context Agents Studio and suddenly had roughly 200 customers interested at once. Every one of those conversations needed a deck built around that specific account’s history and usage, plus a fair amount of unstructured context that lived nowhere tidy: what they’d already used the product for, who on their side cared about it, how it would actually help them. CSMs were drowning trying to assemble that by hand for every single call. Someone built a Relay skill that generated the deck automatically, and what used to take two hours started taking about 30 seconds.
A presentation-ready value deck in seconds. The ask goes into Slack; the deck and the numbers behind it come back in the same minute.
A slide out of that deck. Every figure on it is read from the customer’s own usage, not typed in by a CSM the night before.
That’s the moment Relay stopped being something a CSM asked questions of and started being something that did work on their behalf. Once people saw that shift, they started building their own skills without being asked: a template for weekly updates, a way to match someone’s writing style, a workflow for helping CS leaders draft emails to account leaders. The real signal that Relay had arrived wasn’t usage going up. It was people extending it themselves, unprompted, to take on new problems in their daily work.
What’s different now
We use Relay across all of our customer accounts today for everything from drafting a quick email to prepping for a make-or-break presentation.
Here’s one example: a CSM was working late on an account that had been stuck for months. There was no one to call at that hour, so they opened a conversation with Relay instead and started thinking out loud. Relay pulled up the account and pointed at something they hadn’t quite connected: the account wasn’t just quiet, it had stopped actively using Atlan without any notice. Relay had found and flagged a silent, underlying blocker. The email that came out of that conversation is the one that finally got a response from the account’s buyer. A few months later, the account hadn’t just recovered, it was running a proof of concept with Atlan on a new AI use case.
Relay shows up in smaller ways constantly, too: building a full renewal deck from scratch in less than two hours before a call with a skeptical customer, compiling the state of each customer account before quarterly planning, or turning what used to be two days of scattered updates before a high-stakes demo call (gathered from a CSM, a solutions consultant, an implementation engineer, and whoever else was involved) into something Relay can put together. It’s become the home base for CSMs, one place for all customer information and tools. Relay even has a queue to show exactly where each CSM’s time is best spent: which accounts have a new risk flag, which drafts are ready to review, which relationships haven’t been touched in a while, and so on.
The dig, run by the agent. Two years across calls, tickets, engineering requests and usage, synthesized into one renewal briefing while the CSM does something else.
Relay connects signals scattered across old conversations and tools, surfacing active initiatives a CSM might otherwise miss — and new paths for moving the account forward.
The easy takeaway here is that Relay has helped to increase efficiency and decrease cost. But that’s not why Relay matters. It matters because Atlan’s customer success team runs on a simple principle: customer over company over team over self. Every hour Relay hands back goes to the same place: a CSM who has room to actually think about the customer in front of them, instead of reconstructing their account from scratch.
It also means more time for what hasn’t changed and never will: the human side of customer success. Human judgment and insight is still at the core of our Customer Success team. Even with Relay, a human owns the relationship, makes the judgment call on every risk flag Relay surfaces, and reviews anything before a customer ever sees it. Even the rules Relay follows are human-written: agents follow the guardrails, people write them. Machines are good at recall and repetition, but trust is still ours to build.
What we’ve learned
Accuracy and trust, it turned out, were never something we could grant upfront. Every version built before this one failed at something specific, and each failure taught us what the next version actually needed. The most useful feedback didn’t come from the people who adopted Relay early. It came from the people who were skeptical of it, once we sat down and asked them what it would take to rely on Relay for real customer relationships.
None of that trust happened by accident, and it isn’t the whole story. There’s a lot about what actually runs under Relay that hasn’t been covered here: the skills, the memory architecture, the guardrails that make the autonomy in this story possible. That’s a separate, more technical explanation for anyone who wants to build something like it themselves, and it’s coming next.
There’s also another part of this story not covered here: what happened when Relay was given so much autonomy that it started butting in on human conversations in Slack, and had to learn, the way any new person on a team does, when to speak up and when to stay quiet. That’s its own story too.
Relay isn’t finished, and it probably won’t be for a long time. The version running today will look outdated in a few months, the same way our earlier multi-agent system looked outdated once technology changed and Relay evolved. There are still so many problems to take on, both issues with Relay we want to fix and new challenges we haven’t even considered yet.
What’s left for Customer Success once that work disappears is the part that was always the point: the customer. Atlan only exists if and when our customers succeed. A CSM who isn’t buried in account notes has more time to dive into deep conversations and sit with the problems that really matter. Every hour Relay takes off a CSM’s plate is an hour a customer gets back, and that’s the only measure that really matters.