Building a BAFTA View Support Agent with Make and Claude

Since ChatGPT gained wider attention at the beginning of 2023, one question that has come up repeatedly in my work with BAFTA Media Technology is where AI can genuinely improve a product rather than simply adding AI because it is available. One of the more obvious opportunities has always been support.

BAFTA View, the video-on-demand platform I originally helped launch in 2021, is used by BAFTA members to watch content as part of the awards process. Like any product serving a large audience, it generates support questions. Some are straightforward, such as problems signing in or finding content, while others require more diagnosis. A well-designed support agent could answer many of those questions immediately while reducing the number of routine queries handled manually by the Membership team.

BMT had already explored the idea. In 2024, one of the developers produced a prototype using OpenAI's APIs which proved the basic concept, but it remained an early prototype and required further development before it could realistically move towards users.

When the subject came up again during a BAFTA View meeting, I asked what had happened to the original prototype and why it had not progressed. The team still intended to use it, but the next stage depended on developer resource that was already committed elsewhere. I could see both the problem and, because of how much the technology had changed since the original prototype was built, a different way around it.

The technology had moved on

Two years is an extremely long time in AI development. During that period I'd spent a lot of time experimenting with AI-assisted development, building products and prototypes using Claude Code, Make and other tools. Make had also introduced AI Agents, providing conversation history, knowledge, access to different models and integrations without requiring us to develop all of that infrastructure ourselves.

That made me question whether progressing the idea still needed to depend on bespoke development. Developer capacity was the blocker, but at this stage the actual requirement was to prove whether a useful BAFTA View support agent could work and give stakeholders something realistic enough to evaluate.

I proposed building an alternative prototype myself and estimated that I could get enough working in around half a day to test the approach. After checking with the BAFTA View Product Manager and BMT Director, I received the go-ahead.

The aim was not to replace software development with agentic engineering. It was to remove the development bottleneck from discovery and find a quicker, cheaper way of testing the concept before committing engineering time and budget to a production solution.

Building rather than waiting

One principle I apply regularly in consultancy work is to understand whether something actually needs to be built. Bespoke development is valuable when it solves a requirement that existing products cannot, but it also introduces ongoing ownership and maintenance. For the AI layer, Make was an obvious candidate because its AI Agents already provided most of what this particular use case required.

Rather than developing our own agent framework, model integrations and conversation management, I could use a commercial platform and concentrate on the actual support experience. There are still costs in Make operations, API usage and maintaining the workflows and knowledge, but that is very different from taking ownership of another bespoke AI platform.

I split the prototype into two parts: a reusable chat interface and the AI workflow behind it. I gave Claude Code a short brief for a white-labelled chat component that could potentially be reused across other BMT products, then worked through the interface, refining the design and removing features I didn't think were necessary.

That last part has become increasingly important when using AI-assisted development. It is very easy to add functionality because producing the code is cheap, but every feature still creates something that needs testing, understanding and potentially maintaining. Cheap development does not automatically make more development worthwhile.

I then created the Make workflow, with the interface sending messages to the agent and returning its responses to the user while maintaining the previous conversation. The agent also needed reliable BAFTA View knowledge, so I used Claude to organise information from the existing help site and combined this with documentation supplied by the Membership team. This meant its responses could be based on information BAFTA controlled and staff could review rather than relying on whatever general knowledge happened to exist within the underlying model.

Within a short period I had a functioning support agent that could answer realistic member questions. At that point the question moved from whether the technology worked to what the product should actually become.

Turning a chatbot into a product prototype

I've found that stakeholders make much better decisions when they can interact with something close to the intended experience. Describing an "AI support agent embedded in BAFTA View" leaves plenty open to interpretation, while putting a functioning agent alongside a recognisable film page makes the proposition much easier to understand and challenge.

I gave Claude screenshots and references from BAFTA View and created enough representative screens to make the prototype credible without rebuilding the whole site. The agent could sit unobtrusively in the corner and expand when required, giving stakeholders something realistic enough to discuss where it should appear, how it should behave and when it should hand over to a person.

Building it into a realistic BAFTA View experience also prompted a more interesting question. If a member reports that "this film isn't playing", why should the agent have to ask which film they mean?

BAFTA View URLs already contain identifiers relating to the award and entry being viewed, while Nucleus, the awards management product I manage, contains the underlying entry data. I therefore tested passing that page context into the agent so it could identify what the member was looking at without asking them to repeat information the product already knew.

This makes the interaction shorter and reduces frustration, but it also has an operational benefit because every unnecessary exchange consumes Make operations and model tokens. More importantly, it opened the door to a much more useful support model where an agent can use product context and potentially diagnostic information rather than behaving like a generic chatbot sitting on top of a website.

Knowing where the agent should stop

Once I had proved that context could be passed into the agent, there were obvious possibilities for expanding it further. BAFTA View users authenticate using their membership details, so integrations with systems such as Salesforce could potentially allow the agent to understand more about the member, record interactions or initiate other workflows.

I deliberately did not add those capabilities to the prototype. Being able to connect an AI agent to personal or operational data does not mean it should have access to it, and those decisions need proper consideration around privacy, permissions and whether the capability actually improves support.

Instead, I focused on escalation. If the agent could not solve a problem, it could collect the relevant information and send a structured summary to the support team. This demonstrated the hand-off between automation and human support without designing the feature around the assumption that AI should solve everything.

There are plenty of potential extensions, from support tickets and diagnostics to CRM integrations and automated checks, but the prototype did not need all of them. Its purpose was to prove the approach and give stakeholders enough evidence to decide where further investment would add value.

Getting it in front of stakeholders

The final step was moving the prototype off my machine and putting it somewhere stakeholders could actually use. I stored the project in GitHub and deployed it through Cloudflare Pages, then ran it through security, accessibility and code-quality reviews before widening access.

Those reviews resulted in further changes. The connection to Make was protected rather than leaving the underlying webhook exposed, access to the demo was gated, inputs were validated and requests were rate-limited. I also hardened the escalation workflow so user-supplied content could not become unwanted markup or links when it reached the support inbox.

This still does not make the prototype production software, nor was that the objective. If the feature moves into BAFTA View, the development team will review it against the existing product architecture and determine how the production implementation should work. The difference is that they will be starting with a tested workflow, identified integration points and stakeholder feedback rather than an abstract idea.

What this actually proved

The useful outcome was not simply that I built a chatbot quickly, but that I identified why the project had stalled and found a different way to move it forward. Using Claude Code and Make, I took something that was waiting on developer availability and turned it into a working prototype that stakeholders could use and evaluate without committing engineering resource first. I am now continuing to lead the work as a pilot with the Membership team, refining the agent's behaviour and knowledge and deciding what context, actions and safeguards would be appropriate for a real implementation.

This is where AI-assisted development is becoming particularly useful in my consultancy work. It does not replace proper development, architecture or testing, but it means I can get much further into a problem before asking a client to commit significant development time or budget. In this case I was able to identify the problem, test an alternative approach and put something tangible in front of stakeholders in less than a day, so if we take it into production the development team will be starting with a much clearer understanding of what we actually need to build.