Boutique AI Climb: The Institutional Moat
Image generated by gpt-image-2-2026-04-21

Boutique AI Climb: The Institutional Moat

A little over a month ago I published the first Boutique AI Climb piece. In it I named three workflows (intake, matter management, billing), three moves (Stitch, Buy, Build), and the inversion that makes the climb work - workflows first, the data layer building itself underneath. That inversion is the one Helen Fan's Legal AI Value Stack argues for; the Climb operationalizes it for boutiques. The article ended by hinting what's beyond the operational climb, the deeper AI applications opening after it.

This article picks up where the first one left it. And we are going to do three things.

First, refine the operational climb that was in the original - same bones, cleaner moves, wider firm size band. This framework optimization is coming from the learnings reflecting on the last project I was leading after the first article was written.

Second, we are going to further deepen the Boutique AI Climb, splitting it into Arc 1 and introducing Arc 2 - the institutional moat climb, the layer that comes after the operational workflows are wired in. Along the way we'll name what the Climb is actually building underneath each Arc. The operational vault first, the institutional vault on top of it.

Last but not least, we are also going to walk through what Arc 2 looks like and how to climb it.

The Climb Has Two Arcs

I stopped thinking of the climb as one end to end gesture and rather as two arcs of the same journey.

The first arc is the operational climb you already read about. The data layer it builds underneath is the operational vault.

The second arc, the institutional moat climb I gestured at in the first piece, is what Arc 1 makes possible. The agents you set up here go beyond operational work and build the firm's institutional vault on top. That's where the moat gets encoded.

More on each arc and each vault in their own sections.

Article content
The two arcs of the AI climb

Arc 1: The Operational Climb, Refined

First, improvements of the framework. What's gotten clearer about Arc 1 since the first article comes down to a few things:

Squeeze is a new move I'm adding upstream of Stitch, Buy, and Build. The question to ask before any of the others is what the firm has already paid for that isn't being used. Most boutiques have most of what they need on the shelf - Microsoft 365 and Claude alone, used properly, close a lot of workflow gaps.

Stitch in the first piece was one move, but it actually has two variations - Connect and Extend.

Connect is wiring together systems the firm already uses. Connecting Claude to your DMS via MCP connector so Claude can read across matter folders, for example. Or connecting it to your email so it can pull the relevant thread when you're drafting a response or summarizing where a negotiation landed.

Extend is when you add a capability layer on top of a tool you already use. Once you've connected Claude to your DMS, you can set up an agent that takes every new matter, researches the firm's matter history, runs the conflict checks, and prepares the documents the client needs to start work. That capability isn't in Claude or the DMS out of the box - you built it on top.

The idea of building on top of an existing tool was something Richard Tromans and Zach Abramowitz discussed on a recent Legally Disrupted episode. Tromans called it a third way between buying off the shelf and building from scratch - in his case, building on top of a proprietary legal-tech product. The same logic applies to building on top of a general tool like Claude, which is what Extend does here.

Train and Hire. These are a part of a new axis I'm adding and they are choices about talent and not tech. They attach to whichever tool move you're making. The shape it takes depends on what's already in the firm. If there's someone internal who wants to lead the AI work - usually a senior associate or partner who's already been propping it up on personal energy, you train them as the internal champion. A fractional AI partner sits alongside them, steering the efforts and bringing the technical expertise to figure out how to do it in the most effective and sustainable way.

If there's no one internal who wants to take this on, the fractional AI partner has to be more embedded. The cadence is more regular, with additional async access, and they do more hands-on work directly.

Inside a workflow. Once you've picked a workflow, the next question is what to unbundle inside it. Horatiu Druma-Strugariu , a former litigator, now working as a principal legal AI engineer, put it this way: people tend to bundle skills together that don't strictly need to be bundled, because of how we’ve been doing things so far. His example was knowledge management - is the point of KM organising the knowledge, or encoding it and passing it on? Most firms assume they need the first to get the second; the existence of KM specialists and law librarians says they don't.

The same logic applies inside any workflow on the climb. Take intake - it looks like one thing the firm has to handle, but it bundles several distinct skills: capturing the lead (administrative), running conflict checks (procedural), qualifying the matter, and deciding whether to take the client (legal and strategic judgment). At a 5-lawyer firm one person holds most of those; at a 25-lawyer firm they're spread across the support staff, a paralegal, an associate, and a partner. Either way the skills sit bundled inside intake. Separating them is what tells you what to automate and what stays human.


Article content
Arc 1

Arc 1: Order of Operations, Unchanged

I've had conversations with a number of partners at low volume boutiques. And I’m getting a lot of pushback on starting with the intake. It makes sense. If intake isn't the volume bottleneck, why focus there first?

The thing is, almost every boutique I've spoken to in the past four months, at some point, told me the same thing: turnarounds are expected in hours now, not days. The clients don’t accept a four day turnaround on a contract anymore. The offer needs to go out the same day as the request.

And what really hurts the turnaround on new matters is the whole chain of work each one triggers. Let’s quickly walk through this.

A new matter lands in the partner's email. The partner forwards it to a senior associate with a one-liner, usually "let's discuss" or "please pick this up". The senior reads it, realises they need more context from the partner to actually start, and has to wait for a window to catch them between meetings. The partner half-remembers a similar matter from two years ago. The senior opens SharePoint and tries to find it. Some of the relevant files are there. Some are sitting in a personal folder somewhere and never made it onto the shared drive. They pull together what they can - the past templates, the applicable laws, the relevant context from internal databases. They might need to ping another partner about a specific angle, which means another wait. Then, finally, they start the actual legal work. Four, five, six hours gone before a draft begins.

When intake is done well, that chain will compress. The structured context the senior would have spent hours hunting down is already in place when they pick up the matter. They read it, check in with the partner if anything is missing, and start the legal work.

And then there's hiring. When the operational work isn't documented, searchable, or organized, with no playbooks to follow, bringing on an assistant or a paralegal becomes a much bigger pain than it should be. The onboarding takes a long time, the hire keeps getting postponed, and while that happens partners are drowning and matters are suffering.

What I’ve experienced so far is that when you start at matter management you soon find that mapping the work routes back to intake - back to the structured client data, the matter type, the conflict-relevant details, the searchable past matters across the firm. If those aren't in shape, matter management will be slow. And everything downstream will have the same problem. The benefits of doing intake well compound through the rest of the climb. And so do the costs of skipping it.

Arc 1: The Operational Vault

Given the workflows in Arc 1 are set up the right way, they build and use your operational vault underneath. Entities, matters, clients, deals, documents, deadlines, all structured, linked, keyed to the same firm-wide identifiers. Every workflow you set up produces structured data and pulls from it as a side effect of running, and that data accumulates in your vault over time.

In intake, agents extract the structured client data, run the conflict checks, and store everything. In matter management, agents pull templates from the vault and surface similar past matters.

When a new matter lands, the workflow does the assembling. The brief that a senior would have spent hours putting together is sitting in the DMS when they pick up the matter. The lawyer walks in with everything laid out and their job is to exercise judgment.

Knowledge management has been trying to do parts of this at firms for years - pulling the firm's scattered information into one place where templates, precedents, past matters, and partner know-how can be found and reused. But KM has always been a separate project that competes with billable work. It needs someone to own and maintain it. It was also resourced for big firms with dedicated KM lawyers and law librarians, while at a boutique there's nobody who can own that work full-time. So the KM project starts and never gets finished because the actual work always takes priority.

The vault doesn't need to be a separate project because the operational workflows are producing and maintaining it.

Arc 1 pays for itself on its own. It also buys you competitiveness and resilience on the market in the mid-term (mid-term being the next couple of years).

For firms that want to go further than that and build a moat that compounds over time, encoding the firm's institutional knowledge is the way forward. And that is what Arc 2 is for.

Article content
The operational vault

Arc 2: The Institutional Moat Climb

Arc 2 picks up where Arc 1 finishes. By the time you're here, the operational layer is wired in, the team is producing at multiples of its baseline on day to day work, and the operational vault is building up underneath. That's the foundation Arc 2 builds onto.

Arc 2 takes the firm's accumulated practice - how the work actually gets done, how each client has been served over the years, what the firm has learned matter by matter, the judgment behind every call, and the voice the work goes out in, and encodes it onto what Arc 1 has built. The mechanism is the same one Arc 1 ran on. Like Arc 1, it takes some upfront wiring - the workflows and pipelines that feed the vault. Once that's in place, the encoding keeps happening as the firm works, not as a separate project that competes with billable hours.

So how does Arc 2 look like in practice?

Specialist agents carry the firm's criteria and patterns for each part of the work. One drafts in the firm's preferred style - the carveouts the firm always asks for in indemnification clauses, the structuring approach the senior partner has refined over fifteen years of family office work. Another runs due diligence against the firm's red flag checklist. A third pulls past negotiations with the client at hand - what the firm has pushed on before, where it has accepted, what the counterparty cared most about last time. An orchestrator reads incoming work and assigns the right specialists to it. Every draft passes through a reviewer agent whose only job is to challenge what the specialists produced. A second pass layer checks the reasoning behind every challenge before it reaches the lawyer.

Underneath all of it, the substrate captures what's happening at the firm passively. Email threads, call transcripts, document drafts at every iteration, partner comments left during review - all routed into the same vault. The context Arc 1 built (who's a client, what's the matter, what's the latest) keeps accruing, and the institutional layer builds on top of it.

By the time the package reaches the lawyer, the draft is in the firm's voice, the issues are called out, the precedent is surfaced, and the reasoning has been challenged twice. The lawyer reads, exercises judgment, makes the calls. The institutional knowledge accrues as a byproduct of running the firm.

Arc 2: The Institutional Vault

The operational vault holds the instance level facts: who's a client, what each matter is about, what the latest status is. The institutional vault holds the pattern level practice: how the work gets done, the firm's standard positions on the things that come up, and the reasoning behind past decisions.

The vault doesn't build itself. It has two parts. The first is the vault content: the firm's accumulated practice, extracted by agents and stored in a form they can use. The second is the assembly: a live agent that pulls the relevant slice together every time a new matter lands. That "assembly line" is what makes the vault useful. Both parts run on agent workflows and the vault content is roughly organized into five categories.

Voice and style: how the firm sounds when it writes. The way the partners open termination clauses, the indemnification carve-outs the firm always writes into enterprise deals, the language patterns that make the firm's work recognizable.

Decision criteria: where the firm pushes on a term and where it accepts. A partner pushing back on a 1x fee cap with "never below 2x on enterprise" is a criterion. The risk thresholds, the positions the firm takes, the lines the firm doesn't cross.

Patterns and templates: how the firm structures a deal. The recurring moves it has refined over fifteen years, the standard approach to a particular kind of clause or matter. Each one named as a skill attached to the agent that uses it.

Client context: the history with each client. What this client has cared about across past matters, where they've pushed back, what they've accepted, what the counterparty cared most about last time.

Past matter narratives: the why behind decisions, and what the firm has seen go wrong a hundred times. Why a deal was structured a certain way, what came up during negotiation, what almost killed it. The reasoning that lives in the partner's head from doing the work.

There's a natural build order to Arc 2, roughly easiest to hardest. Voice and style first, because the data is already in past drafts; an agent reads them and pulls the patterns.

Decision criteria next, harder because the agent has to classify what's a rule and what's a one-off comment, but mostly automatic once the classification works. Patterns and templates around the same level, extractable from the same corpus. Client context after that, with the one hard dependency on Arc 1: until who-is-a-client and what-is-the-matter are clean, the agent has nothing stable to organize client-specific stuff against. Past matter narratives last, because they're the only category that needs active partner input. The matter-close debrief and walkthroughs come in here.

Unlike Arc 1, the order is less strict. Voice first is the default because it's the fastest to set up and shows immediate results, but a firm strong on voice and weak on criteria can start with criteria. A firm with solid client relationships but no encoded narratives can start with the matter-close debrief and skip ahead. Each stage stands on its own.

Curation is what kills traditional KM at boutiques. There's no standard process or habit built around it, so it never happens in a systematic way, and whatever ad hoc effort someone makes gets crowded out by billable work. Arc 2 survives because the agents do the extraction either way, in the flow of the work, without anyone needing to own a curation project on the side.

Article content
The institutional vault

Arc 2: Where This Positions Your Boutique

Three other people I really respect in this space have published their own maps for the road to AI native. The interesting thing is that all four of us see the same end state. The north star is the same: a position that holds against competitors and earns trust with clients. We just describe it in slightly different vocabularies.

Kaj Rozga 's four stages of evolution climb through Crawl, Walk, Run and Fly. Crawl is off the shelf commodity AI with no differentiation. Walk is practice innovation, an innovation team bolted onto a traditional firm as a cost center. Run is a standalone division with its own leadership and P&L, building tech-enabled service delivery for clients at fixed fees. Fly is an incubator that productizes the solutions and sells them to non-client customers, with eventual NewCo spinoffs.

A boutique that completes Arc 1 lands at Walk moving into early Run.

A boutique that completes Arc 2 lands at Run. The further fork past Arc 2, where the substrate becomes a licensable product, is Fly.

Helen Fan 's Legal AI Value Stack runs five levels, from raw AI capability at Level 1 to the hybrid AI-plus-human law firm at Level 5. Level 2 is AI with workflow, with legal-specific outputs and customizable playbooks. Level 3 is proprietary data, where a platform learns and compounds from how it's used. Level 4 is system of record, where the product becomes infrastructure for how legal teams operate, with the moat sitting in what Helen calls operational gravity. Level 5 is a law firm itself, with AI as the operational backbone and humans handling trust, judgment, and accountability.

A boutique that completes Arc 1 sits at Level 2, with the operational vault accruing as the firm's own proprietary data layer.

A boutique that completes Arc 2 sits at Level 5. Helen's argument is that Level 5 is the only level that survives the AGI era; Levels 1 through 4 all converge toward infrastructure.

Bradley Johnston 's map has five architectures emerging in the legal services market. Architecture 1 is BigLaw incumbents capturing AI gains internally without restructuring the associate-leverage model. Architecture 2 is alternative-structure firms, partners-only or fractional, where AI augments senior judgment and may actually strengthen the firm's position. Architecture 3 is document review and managed services, where AI is dissolving the labor-arbitrage advantage outright. Bradley flags 2 and 3 as the most exposed of the five. Architecture 4 is AI-primary firms with human judgment at the margins. Architecture 5 is boutiques making the flip. The diagnostic Bradley uses across all five, borrowed from Chris Bridges , is whether the operating model has actually flipped or whether AI has been bolted onto existing workflows.

A boutique that completes Arc 1 sits in Architecture 5 with workflows running but the model not yet flipped.

A boutique that completes Arc 2 sits in Architecture 5 with the flip done, or arguably Architecture 4 depending on how technology-led the delivery becomes. Either way, the firm is on the disruptor side of the map.

All four of us are pointing at the same defensible position.

The Stack

Everything I've described, both the Arc 1 workflows and the Arc 2 vault and assembly, can be done with Claude Cowork. I've seen it with more than 1 firm and I've implemented it, and that's where this is coming from. Proprietary software built specifically for the job would be better (and arguably much more expensive to build and maintain), but Claude Cowork gets you very close.

The bottom line is that the stack of today doesn’t matter that much. Which is probably the most counterintuitive point of all of this. Think about it. The shape of the “right” stack changes every quarter as the technology moves. Today's best fit will look different in three months. The question to ask in any given snapshot is "what's the stack that gets the job done right now with what's available?" Then you assemble it, run it, and revisit when you hit a ceiling.  And the switching cost with something like Claude Cowork is much lighter than what firms are used to from legacy DMS or legal AI platform migrations, which can take weeks. The work you put into Cowork lives as your knowledge in files that travel with you to whatever comes next.

Because it’s not the technical stack that is your differentiator on the market, it’s how you assemble your tech stack to supercharge your differentiator.

Now the bigger trap with focusing on the stack too much is overengineering the whole thing to squeeze that extra 2-5% of capability from AI. The last 2% to 5% of quality costs disproportionately more than the first 95-98%. It's the Formula One pattern: shaving the last hundredth of a second off a lap costs more than the entire car that gets you to within that hundredth. The work a boutique gets paid for is evaluated on quality, speed, and whether it holds up. In real world, the last 2% of polish rarely shows up as a significant advantage.

The judgment to exercise on every stack decision: do I actually need the last increment of quality this tool or proprietary software build would buy me, or would I be paying Formula One prices for work that doesn't need to run at Formula One levels?

The Compounding Boutique

A boutique law firm three steps into Arc 2 is substrate-led. The agents do production, the substrate captures what's happening, and the lawyer's judgment runs the firm.

This is the compounding boutique, punching at multiples of its headcount on day to day work. It's structurally uncatchable from both directions: bigger firms can't match the agility, AI-native startups can't match the substrate depth.

A boutique that gets here is sitting where Kaj, Helen, Bradley, and I are independently pointing as the defensible place to be. The work going forward is maintenance, refinement, and the occasional further fork.

The further fork is to productize the substrate. A handful of boutiques will get to a place where what they've encoded is valuable enough to license to in-house legal teams or other firms. That's a rarer arc with its own questions, outside the scope of the Climb as I've written it. The Climb gets you to the compounding boutique. What you do from there is yours to decide.

Arc 1 buys you punching above your weight. Arc 2 buys you keeping it.


This matches our experience as a boutique litigation firm. The moat is not the infrastructure — it is the accumulated judgment about how a firm frames an argument, structures discovery, and decides what a draft still needs before it goes to a client or a court, encoded so the tools apply it by default. That compounds with every matter and costs little beyond the discipline of capturing it. The half-billion-dollar build solves a problem most firms do not have: institutional-scale confidentiality across thousands of lawyers. For the rest of the market, the climb you describe — operational workflows first, then the institutional layer — is the right order of operations.

Like
Reply

A very interesting article; I think you make a lot of good points. I can also definitely confirm from my own experience that a properly designed knowledge management system makes the system surprisingly vendor-agnostic. Given the relatively small data volumes processed in the legal industry and the recent rapid development of AI hardware (e.g., NVIDIA DGX Spark), I would say that this also opens up a very interesting prospect for building systems based on high-performance local models.

Sharp framing. Worth extending into vertical practice areas where the moat looks different. In SSA and VA disability work, the firm's practice and judgment is not separable from the regulatory framework — every functional limitation maps to a CFR section, every listing has paragraph-path criteria (Paragraph A plus B, or A plus C, never all paths required), every treating source persuasiveness analysis splits on filing date pre or post March 27, 2017. The encoded judgment Arc 2 describes is, in vertical disability practice, the encoding of how a 30-year practitioner reads the regulations against a specific claimant's record. The Kirkland owned-stack play makes sense for matter-heavy enterprise work. For a vertical boutique, the moat is sharper: the firm's structured data layer mapped to the specific regulation that governs the practice area. Built once, refined per case, owned. Not rented from a horizontal vendor that does not know the difference between Paragraph B and Paragraph C of listing 12.04. Arc 2 plays the same way in vertical practice. Different texture. Same compounding logic. #ssdi #socialsecurity #vadisability

The operational reality is that formal control over a system does not automatically translate into control over how it is used. Organizations may own the infrastructure, yet still discover that adoption patterns, workarounds, and operational dependencies evolve in ways that governance structures never explicitly anticipated.

Rok Popov Ledinski That's a very good way of putting it, and I totally agree, off to read your article, thanks 👍

To view or add a comment, sign in

More articles by Rok Popov Ledinski

  • The Fractional Boutique AI Partner

    The Multidisciplinary Boutique Rise Every other non-legal function the firm has at this point, like marketing and…

    12 Comments
  • The Boutique AI Climb

    I owe you a warning before I get into any of this: I'm not a lawyer. I've been trying to figure out the operational…

    13 Comments

Others also viewed

Explore content categories