home  /  automation & building
department of automation & building

Most firms should not build AI. They should configure and connect it.

The evidence on internal builds is not close, and the wins that are available without building are larger than most firms expect.

begin here

Where is your firm?

Start a conversation with the AI Adoption Concierge, already scoped to automation & building. Choose the question closest to yours, or describe your situation directly.

AI Adoption Conciergeautomation & building · orientation, not legal or ethics advice
Tell me the firm's size, what practice management system you use, and the process that irritates you most. I'll help you work out whether it's an automation, a configuration or a purchase.

There is a persistent assumption that getting serious about AI means building something. The evidence points the other way: research across enterprise deployments has found internally built systems succeeded roughly a third as often as buying from specialists, and the failures cluster around integration, data quality and ownership rather than model capability. Meanwhile the automation that reliably pays for itself in a law firm is unglamorous and largely pre-dates AI — matter opening, e-signature chasing, deadline synchronisation, review requests. The genuinely new development is connection: standards emerging through 2025 and 2026 mean a firm's document system and research provider can now be reached by whatever AI it uses, without a bespoke integration project. That is configuration, not construction, and it is where the leverage is.

specialization areas

Areas in this part of the practice.

The automation worth doing first, connecting what you already own, and the decision about whether to build at all.

methodology

How this department investigates.

How the Institute approaches this.

Honest about build failure ratesThe published evidence on internal builds is unflattering and firms deserve to see it before committing partner time.
Cost and skill stated plainlyWhether something needs a weekend, an operations person, or an engineer — because that is the question that actually decides it.
Human gates named explicitlyEvery automation described here specifies where a person must remain, particularly on deadlines and money.
Connector depth verified, not assumed"Integrates with" covers everything from a full API to a single trigger. The difference decides whether a workflow is possible.
Categories, never rankingsWhat a category does and what to ask of it. The Institute does not rank vendors.
Maintenance countedAutomations rot. Anything described here carries an honest note on what keeping it alive costs.
common questions

Automation — the questions firms ask.

What should we automate first?

Matter opening, almost always. It is high-frequency, touches several systems, has a clear beginning and end, and every step except the conflicts decision is mechanical — intake data captured, matter and contact created, folder structure built, engagement letter generated and sent for signature, standard tasks and deadlines created, responsible attorney notified. The conflicts check stays a human gate in the middle and the workflow pauses there. Firms that automate this typically see it pay back within weeks, and it is the one that teaches the firm how automation behaves before anything riskier is attempted.

Is it true most firms should not build?

For most definitions of "build," yes. Research across enterprise AI deployments found internal builds succeeding at roughly a third the rate of purchases from specialist vendors, and the failure modes are consistently organisational rather than technical — nobody owns it, the data was worse than assumed, the person who wrote it left. What that does not mean is that firms should do nothing. The productive middle ground is configuration: shaping a vendor product or an open framework with prose, prompts, playbooks and connectors rather than code. That is where firms with no engineering capacity have produced real results.

What is MCP and does it matter to us?

It is a standard for connecting AI applications to the systems that hold data, open-sourced in late 2024 and donated to a neutral foundation in December 2025. It matters because two dominant law-firm document management systems shipped support for it in 2026, along with research providers and a body of court data. The practical consequence is that a firm can point an AI tool at its own governed document repository without commissioning an integration — and that the connection inherits the existing permissions rather than bypassing them. It also means an agent can be given tool access, which is a security question covered elsewhere.

Do we need a developer?

For most of what is worth doing, no. Workflow automation between systems is a configuration exercise a capable operations or knowledge person can run, and the platforms are priced in tens of dollars a month rather than thousands. Prompt and template libraries need editorial discipline rather than engineering. Where a developer genuinely becomes necessary is building retrieval over the firm's own document corpus with permissions enforced correctly, and running agent frameworks — both of which are things most firms should be buying rather than building anyway.

Not sure whether to build, buy or configure?

Describe what you are trying to change. The Institute will help you work out which it is.

AI adoption conciergeorientation · not legal or ethics advice
Tell me the firm's size, what practice management system you use, and the process that irritates you most. I'll help you work out whether it's an automation, a configuration or a purchase.