How Claude Built Me a Support Agent in a Few Hours

A few weeks ago, the CTO of BAFTA pointed Claude at the Events booking system codebase, one of the products I manage, to see how well it could document the product directly from the code. A few hours later he sent me a PDF explaining how Events worked. My immediate reaction was that this could be more useful than documentation alone: we had created a large body of structured product knowledge that an AI could query. I asked him to do the same for Nucleus.

Nucleus is BAFTA’s awards entry and judging platform and has been developed over many years, so the codebase is huge. I know the product well, but that is different from having every setting, dependency and edge case in mind when someone asks a question. Support has the same problem. Some questions reach a developer because the answer is not obvious from the UI or help guides, even though the behaviour is known and documented somewhere.

I had also recently been working on Herbie, the AI support assistant we built for BAFTA View — which we later rebuilt as production code — so I already knew that an AI agent could provide an interface to a controlled set of product knowledge. The idea became more concrete in a development meeting. The developers and I were looking at Nucleus functionality and using Claude’s documentation to understand how parts of the existing product behaved. It was useful enough that, at one point, it found something we probably would have missed. We started discussing an interface similar to Herbie that would let support query the documentation directly. I suggested putting the agent in Slack, where the team already worked, rather than creating another interface or system to remember.

Document the approach first, build nothing

I started by giving Claude a zip containing 49 internal Nucleus developer documents and asking it to design a Slack and Make.com agent. I specifically told it to document the proposed approach first rather than build anything. Claude checked what it could do through Make, then returned an architecture, security considerations and rollout approach. I reviewed that and asked it to set everything up without me. It rewrote the source material into 22 documents intended for support. That distinction mattered: I did not want to expose engineering documentation directly through an AI. Support needs to know what a status means, which settings affect it, where controls are and what behaviour to expect; it does not need file paths, database tables, server details or security findings. Claude used parallel agents to process the material, retaining behaviour and configuration information while removing implementation detail. Potential bugs were retained only when they affected users and were explicitly labelled as unverified possible issues.

It then built the Make scenarios, Slack intake, test agent, logging and tools for adding and removing knowledge. It also wrote the Slack app manifest, although I still had to create the app, install it and authorise the connections because Claude could not do those things on my behalf. I was not building Make scenarios alongside it. Most of my involvement consisted of answering questions, making product decisions, supplying source material and handling the relatively small number of tasks that required my account or credentials.

The first useful version was running after roughly two or three hours of my time. It was called Nucleus Helper and deliberately had a simple interaction: mention it in Slack or message it directly, ask a question about Nucleus and receive an answer based on the documentation. It added an eyes reaction while working, then replied in the thread with the sources it had used.

Adding the help guides, then Events

Testing showed that the engineering documentation covered only half of what support needed. It answered questions about product behaviour, but we also had extensive procedural documentation on the public Nucleus help site. I gave Claude the help-site URLs and asked it to work out how to use them. It discovered that the sites were running WordPress, found a way to retrieve their content through Make and began importing the articles. When it reached Make’s limit on knowledge files, it changed approach and grouped the help content by category rather than stopping and asking me to reorganise it. It eventually imported 257 help articles across Nucleus and Events into 19 category documents.

The help guides made the answers considerably more useful. The agent could combine an explanation of how something worked with the steps for configuring it and, where appropriate, provide a public help article that support could send to the client. The Nucleus version worked well enough that I decided to add Events. I supplied the Events internals documentation and Claude repeated the process, producing another 11 support-level documents and adding the Events help guides.

Splitting the products behind a router

Initially we kept both products together, but testing showed that questions could be ambiguous. Refunds are a good example: both Nucleus and Events have payments and refunds, but they mean different things. When I asked, “How do refunds work?”, the agent asked whether I meant Nucleus or Events rather than guessing. After I replied “Events”, it gave me the Events refund flow.

As the knowledge base grew, I also became uncomfortable with both products competing inside one agent. I asked Claude whether we should separate them while keeping a single user interface. We ended up with a small router in front of separate Nucleus and Events specialists. The router identifies the relevant product, asks for clarification when it genuinely cannot tell and passes a clean version of the question to the appropriate specialist, which searches only its own product knowledge. Testing also changed the implementation. We found that lower reasoning levels made the specialists more likely to invent explanations when the knowledge was insufficient, so Claude increased the reasoning level and tightened the rules. Changes are now tested against a separate Brain version before going live, including normal product questions, ambiguous questions, follow-ups, attempts to make it discuss code and prompt-injection tests. The same structure makes it straightforward to add a product, since each one gets its own specialist and knowledge behind the shared router. I have since added a Jury specialist, with BAFTA View and Voting to follow, so the agent will eventually cover all the BMT products.

Using it for my own product work

By then I had started using the agent for my own product work rather than only testing its support answers. I have recently been looking at Nucleus viewing functionality as part of new work around Rounds. Viewing is a good example of the agent’s value because its configuration is spread across several parts of the admin interface. I began by asking where the control was that allowed viewers to search entries. The first answer was not quite right, so I challenged it. It explained which questions could be made searchable, where those settings lived and how the viewing title worked, but I knew it was missing an important distinction. By continuing to question it, we established what was and was not configurable about the search itself.

The conversation expanded into a broader map of the existing viewing functionality. I asked which question types supported searching, how the “Title for viewer score download” option worked and where the other viewing controls were located. The agent brought together settings across Control Centre, categories, form questions, viewers, media, approval and payments. I still challenged answers when they did not match my understanding. For example, when it described the site-level controls for video downloads, I pointed out that award-level settings also existed. It then explained the relationship between the site, award and individual media settings. I did the same with redacted PDFs, which led us through the site-level PDF setting, category setting and question-level option controlling whether an individual answer appears in the redacted PDF.

By the end, I had used the agent to map where viewing controls are distributed across Nucleus and how some of them interact. That is useful even though I have worked with Nucleus for years, partly because I know the product well enough to interrogate the answers rather than accept them uncritically. I do not expect an AI agent to replace my understanding of the product. I want it to make years of accumulated knowledge easier to retrieve while I work. That was not part of the original support use case, but it is now probably the aspect I find most interesting. The same agent that can prevent a straightforward support question from reaching a developer can help me scope a change and identify existing behaviour that might be affected. I still do not assume its answers are correct. The conversations so far show why that would be unwise: I can challenge an answer, point out when something seems wrong and keep drilling into the underlying knowledge.

Deliberate limits

The agent has deliberately strict limits. It cannot see a client’s Nucleus or Events site, inspect entries or bookings, or change anything. It is not connected to live application data and is specifically designed not to expose code or technical internals. If support needs to know why a particular client’s booking failed, engineering investigation may still be necessary. The aim is to avoid escalating questions whose answers already exist but are difficult to find. We considered adding Jira and Jira Service Management so the agent could search known bugs and previous client support cases, but I have put both on hold. JSM introduces client data and additional access considerations, and I am not yet convinced we need it. I would rather let the team use the current system for a couple of weeks and assess its value before adding more capability.

What was actually different

I have spent roughly five to seven hours on this over about a week getting the first Nucleus version running, tested, adding the help guides and Events and reworking the architecture when one combined agent proved less effective, and refining it since. The core difference was how I spent that time. I chose the problem, defined the scope, selected the products Make and Slack, supplied the source material and decided what the agent should and should not do. Claude then completed the work by proposing the architecture, turning the engineering docs into support-safe knowledge, building and versioning the Make scenarios, importing the content, working around platform limits and testing changes and writing up all the decisions and documentation in Confluence. My hands-on work was mostly creating and authorising the things Claude could not reach itself.

I do not think the interesting part is that I built a support chatbot in a few hours. I have built AI workflows before and none of the pieces is novel. What feels different is being able to say “document the approach, do not build anything yet”, review it, then say “now set this all up without me” and have that produce a working system rather than another set of instructions to follow. There is still plenty to prove, and the team needs to use it against real questions, but it is already useful enough that I have started using it in my own product work, which was not what I set out to build.