We deployed the agent, with the third-party contract review skill ready to go. We handed it over to the client, a global travel technology company. We were excited to see the first results land. The first request came in, and the user asked for the agent’s output to be in a different format than we expected: a table of redlines, not the contract itself redlined. We scrambled. We quickly released a feature that enabled this output. Phew! But this exposed a problem that dawned on me and Martin, our CTO. We were still operating as a software company in the agentic paradigm. Where was the config I could quickly update to enable this workflow? It was a black box that needed an engineer. Every enterprise has its version of “we do it slightly differently”: different inputs, outputs, workflows, approvals, and systems to plug into. The new paradigm opens a novel opportunity - to discard the old world of one-size-fits-all, where square pegs are forced into round holes, and instead build a platform that deploys bespoke agents into unique workflows, at scale. We realised this was our product. And this is what we have been building ever since.
The lawyer in the middle
There are some great tools out there. We use them. The problem with general tools that lawyers use is the lawyer. They still need to be in the middle. Owning legal AI software does not get legal work done. The hard part is deploying AI into existing workflows, aligning with playbooks, templates and rules, and still needing someone to stand by the work. The alternative option is outside counsel. 64% of legal teams expect AI to reduce reliance on outside counsel, and yet only 7% see a reduction in cost per matter (Source: ACC and Everlaw). A generic tool only works because the lawyer in the middle ties it into the specific constraints: the existing workflows, templates and rules. If an agent is to really do legal work, it must be bespoke and not general, and have that specific information built into it.
But bespoke makes people nervous. We all know what “bespoke” looks like: months of consulting, endless slide decks, a black-box system only the vendor can configure, every tiny change a ticket that takes weeks to be picked up, and a multi-million-dollar bill for the privilege. No thanks. Bespoke agents only work if we can deploy them at scale and at a low cost (our clients see the agent working on their own work before any agent fee, and agent fees only start once it’s live). At Flank, we are building tools that build the agents. Our engineering team stops building features for lawyers and builds tools for the people who deploy agents.
The bespoke part
An agent is three things:
Skills: legal know-how for the agent. Instructions, playbooks, templates, schemas and approval rules, built per client from their precedent.
Tools: what the agent can do, the execution building blocks. Review, redline, analyse, draft, file into the record. Engineers build these, and agents use them across many different use cases. If there is a capability gap when setting up a use case, new ones can be spun up in under a day.
Connectors: where agents live and work. Microsoft Exchange, Salesforce, SharePoint, Word, CLMs. Purpose-built integrations so the client never has to change where the work happens.
Skills are the bespoke part, the knowledge. How do we get this knowledge encoded into the agent? When we speak to most legal teams, the message is the same: playbooks are incomplete or exist only in precedent; templates are Word documents with some notes and highlights; and the “how to” lives in people’s heads. You can see how even a simple deployment can stretch on for months. This is why we are building the tools for the people building the agents. Our forward deployed engineers (FDEs) are the stars of the show. They work hand in glove with our clients, understanding their needs, mapping out the workflows, and quickly building and deploying agents that plug straight into their systems. Building tools for our forward deployed team has become our focus and has unlocked our ability to deploy dozens of agents across our enterprise clients, while we stay lean.
Starting with the Agent Design Document
Our FDEs sit down and agree on an Agent Design Document (ADD) with the client. This specs the agents we will deploy: the outcomes they must achieve, how this is measured, what systems they connect to, what skills they have, how they should operate, and what approval flow they should follow. Once agreed (we get customers to sign; we take it very seriously), the FDE uploads the ADD to the Flank system and watches as a first pass of agents and skills is built before their eyes. Our FDEs then iterate on this first pass using real client data, building up an automated test suite that ensures the agents’ results are accurate and consistent. Back to our opening example: the unexpected request becomes a test case, and the FDE adds a docx tool to the agent and updates the skill instructions to draft a table of redlines. They run the test, check the output and, if it passes, set it as an exemplar test case. No scrambling, just part of the agentic build process.
When the playbook is the problem
What about playbooks and templates? Honestly, these are sometimes the biggest gaps when we look to deploy an agent. Rubbish in, rubbish out still holds true, and I’m sure you recognise that in most companies these are all over the place. Our FDEs sit down with the client and take whatever they have, no matter how messy or incomplete, and run it through our template and playbook labs. The output: a structured, sensible first pass that can be tested and iterated in the lab, and that the client can add to whenever they want. I demoed our template lab on my recent webinar. See below. What is great about these tools is that they are built on the same agentic engine as our Flank agents, and so they can be tested live as the playbook builds. I remember when we first showed this to one of our FDEs. They had a starter playbook from a client and couldn’t understand why the agent kept redlining a compliant clause. “Why is this broken?” was the query to the lab. “Nothing’s broken. The agent is doing exactly what the playbook’s telling it to do” was the response, with a suggested improvement that fixed the internal inconsistency written into the original playbook (by a human). Fixed.
What you can’t automate away
AI has transformed software development, and it is going to transform how other work gets done. We were able to build and iterate these tools in timeframes unimaginable three years ago: first versions working in hours. It will be the same for deploying agents into your organisation. And, as with code, you can’t automate away context and judgement. That is where humans are still needed. That is why we are so confident in the forward deployed model: FDEs who know our clients intimately, working hand in hand, often on site. We are building the tools to take away the manual work, freeing up more time for them to focus on ensuring the outcome is delivered, the work is done, and our clients haven’t wasted more money on another tool that sits unadopted. An outcome delivered never goes obsolete.
