Mel – Building a Structured AI System for Accountants and Lawyers

The thesis behind the build is simple: AI is the magic dust; structure is what keeps clients in business. A big language model on its own is a demo. A structured system, where the firm’s own data does the reasoning, security is architectural rather than procedural, and costs are engineered from day one, is a product a regulated firm can actually buy.

The problem the client set us

Every accounting or law firm has a small number of senior rainmakers whose business development instinct isn’t in a playbook. It’s muscle memory. Who to introduce to whom. Which prospect to call this week. Which client mentioned a merger three years ago at an awards dinner. That knowledge is the firm’s most valuable growth asset, and it is largely locked inside a handful of heads.

The result is that revenue growth becomes fragile and succession becomes hard. When a rainmaker retires, so does the knowledge.

The client’s brief was to build an AI assistant that could act like an extra business development team member across the whole firm. Not a chatbot, not a summariser, but something that could research prospects, surface opportunities, coach fee earners through meetings, and prompt the right next action. Something that turned the firm’s collective network into a unique advantage everyone could act on.

Anyone who has actually deployed AI into a professional services firm knows the real problem isn’t “can the model do it?”. It’s “can it do it consistently, at a sensible cost, on data the firm trusts, without hallucinating something that ends up in a client-facing email?”

That’s the problem structure solves.

What Mel does day to day

Mel is a web platform built around the daily rhythm of a fee earner in a professional services firm. On any given morning, Mel can:

• Deep-research the people and organisations attending a networking event, from an uploaded delegate list or a scraped programme
• Turn overnight news into conversation openers tailored to the themes of tomorrow’s event
• Coach a fee earner through meeting prep: the lines to take, the questions worth asking
• Recommend which contacts, referral partners, or cross-firm introductions to prioritise this month
• Extract the important content from proposal documents, whether they arrive as clean PDFs or as scanned images
• Answer live coaching questions (“Ask Mel”), grounded in the firm’s own history and relationships

Three ideas that made Mel work

1. Turning the firm’s relationships into a queryable asset

A professional services firm’s growth depends on relationships, and structurally those relationships are a graph: which partner has history with which company, who introduced whom, who sat next to a prospect at that awards dinner three years ago. Mel makes that graph queryable.

We build the graph inside each firm’s own database from the data Mel already captures (contacts, companies, opportunities, activities, networking events), and weight the connections by how frequently and how recently people have interacted. It rebuilds itself on a schedule. Nobody authors it by hand, and no AI model is permitted to write to it. An invented relationship would silently corrupt every future answer, so an edge in the graph exists only when a human has confirmed the underlying activity.

Ask Mel reaches the graph through three questions a fee earner might actually ask:

• “What’s our firm’s full history with Acme?” Every touchpoint the firm has ever had with a company, across every colleague, in a single answer.
• “Who here can introduce me to Acme’s CFO?” The question that turns a firm’s collective network into an individual’s advantage.
• “Who else looks like this prospect?” Matching a live opportunity against the firm’s own track record by sector, service line, and shape of deal.

The design detail we were most deliberate about is disclosure. A warm-path query is inherently a question about someone else’s relationship, and team members are rightly protective of their contacts. So Mel returns the path, not the payload: “Sarah has a strong relationship here, speak to her” rather than handing over Sarah’s contact record. Whether a given user can even ask the question is governed by the same granular permission model that runs the rest of the platform.

There is a second benefit to the graph that isn’t obvious at first: it lets us remove AI calls rather than add them. Mel’s recommendation engines no longer ask a frontier model to reason across relationships. The graph does that deterministically, and the model only writes the explanation. A far cheaper job, on a far cheaper model, with a more reliable answer.

2. A database per firm: client confidentiality by design

Most multi-tenant AI products isolate customers with a filter. One shared database, one shared vector index, a tenant identifier stamped onto every row, and a great deal of care taken never to forget the WHERE clause. It works right up until the moment somebody forgets it.

Mel doesn’t work that way. Every firm on the platform gets its own physically separate database, provisioned automatically the moment the firm is onboarded. Tenants are identified by subdomain, and the application swaps its database connection per request. Sessions live inside the firm’s own database and are validated against the active tenant on every request, so a session cannot be carried across firms even deliberately.

The consequence for the AI layer is the part we think is genuinely differentiating. A firm’s Mel conversations, its AI audit log, its content embeddings, the relationship graph itself, and the entire CRM all sit inside that same isolated database. There is no shared vector index with a namespace filter. There is no cross-tenant query to write incorrectly.

Cross-firm data leakage in Mel isn’t mitigated; it’s structurally impossible, because the data is never in the same place to begin with. For law and accounting firms, where client confidentiality is a regulatory obligation rather than a preference, that distinction carries real weight in procurement.

It’s also why the relationship graph runs inside each firm’s own database rather than on a shared, dedicated graph store. Adopting a shared graph would have meant reintroducing exactly the “one filter away from a breach” model we designed out. That wasn’t a trade we were willing to make for query syntax.

3. A security posture built for regulated clients

Mel has been through a substantial infrastructure programme to meet ISO 27001 requirements, and the work went well beyond documentation.

The application runs on AWS in the London region on serverless infrastructure, with every function placed inside private subnets of a dedicated network. There is no public network path to the application tier at all. Outbound network access is deny-by-default: traffic reaches only a short, explicitly enumerated set of destinations, and any new dependency has to be added deliberately rather than inherited. The network topology, the rules that enforce it, and the supporting evidence are maintained as a controlled document in the codebase itself, versioned alongside the application, so the audit position is always the deployed position.

All customer data is encrypted at rest. Migrating the production database onto encrypted storage was executed as a planned cutover on a live platform, without data loss, not a greenfield assumption.

The AI layer sits inside the same posture, and this is where the architecture becomes procurement-relevant. Mel’s language model traffic runs through Amazon Bedrock in the client’s own AWS account, in region, authenticated by the platform’s own execution role. In practice that means there is no AI provider API key anywhere in the production environment. There is no long-lived credential to store, rotate, leak, or explain to an auditor. Model usage bills to the client’s own AWS account. And every single call the platform makes to a model is written to a per-firm audit log recording the agent, the model, token counts, duration, cost, and outcome. Any question about what the AI did, for whom, and at what cost has a queryable answer.

For a firm’s information security officer, that combination (physical data isolation, no long-lived AI credentials, complete per-firm auditability) is the difference between “AI product we’re evaluating cautiously” and “AI product we can actually buy.”

Why we built it on Laravel

We’re a Laravel agency by conviction, not by convenience, and Mel is a good example of why.

Mel is a full business platform, not just an AI feature. Under the AI it is pipelines, engagements, users, permissions, billing, integrations, media ingestion, event management, and quite a lot of ordinary professional-services business logic. Laravel handles that beautifully, which means we could concentrate our engineering effort on the parts that are genuinely novel (the graph, the tenancy model, the AI layer) rather than reinventing the ordinary.

The laravel/ai package matters more than it looks. It let us build the AI part of Mel inside the firm’s domain model, using the same permissions, the same authorisation checks, the same audit patterns, the same background job system as everything else. That’s the reason Mel’s AI can never see or do something a user wouldn’t be permitted to see or do themselves: it goes through exactly the same authorisation layer as a human clicking a button in the UI. There’s no separate AI service with its own privileges to keep in sync.

In practice, that structure gave us three things quickly: speed to market without losing correctness, a much shorter path to ISO 27001 evidence than a fragmented multi-service architecture would have offered, and a codebase we can extend safely as Mel’s product roadmap grows.

Structure, applied consistently, is what let a small team ship something this substantial without the usual trade-offs.

Outcomes

Mel is live, in the hands of real customers, and was recently featured on BBC News as an example of AI applied usefully in professional services. Mel’s co-founders Oonagh O’Reilly and Marie-Claire McGreevy have been vocal about the impact it’s already having.

For Metadeck, Mel is a proof point for how we think about AI in serious business software: structure first, magic dust second. A big model on its own is a demo. A structured system, where the firm’s own data does the reasoning, client confidentiality is architectural rather than procedural, and every AI call is auditable, cost-attributable, and grounded in what the firm actually knows, is a product a regulated business can build growth around.