It's a sign that the industry is converging on the same insight: AI agents need more than raw intelligence. They need structured, reusable know-how they can pick up and apply consistently so that users can rely on predictable behaviour. Here's how the two approaches compare, and where they part ways.

What are Agent Skills

A Skill is a standardised, packaged set of instructions that an AI agent can pick up and use for a specific task. Instead of explaining from scratch how to do something every time, you write the instructions once, package them up, and any compatible AI tool can load and follow them. The goal is portability and reusability: build a Skill once, use it across different AI products without rebuilding from scratch. It’s a sensible, well-designed standard for general-purpose AI agents.

(A brief note: Anthropic’s product naming in this space — Skills, plugins, connectors, MCP servers has become genuinely hard to follow. We don’t blame them; it happens with fast-growing companies. They are cleaning it up. But it’s worth knowing that the “legal thing” they launched with the most pomp is actually called a plugin, not a Skill.) 

What are Blueprints and Why They Go Further

Arna runs on Blueprints: curated packs of expert knowledge, templates, strategies and processes designed to solve specific legal challenges from start to finish. They require the user to provide information specific to the organisation for which a blueprint is used.

And here’s the fundamental distinction: Skills are methods. Blueprints are strategies. A Skill tells an agent how to perform a specific task. A Blueprint runs an entire process from a triggering event through to a completed outcome, calling the right tools at each step, creating deliverables, routing work to the right people, and deciding when a human needs to be involved.

To make this concrete: a Skill for contract review tells an agent how to extract key clauses from a document. A Blueprint for contract review kicks off the moment Arna receives it, she flags deviations against your playbook, and escalates to in-house or outside counsel if a redline threshold is hit, chases approvals, and logs the outcome wherever you instruct her to. The Skill is a technique. The Blueprint is the whole process.

That distinction matters especially in legal work, where no step happens in isolation. A GDPR data subject request isn’t a single task. It’s a sequence of decisions, verifications, drafts, approvals, and deadlines, some of which a machine can handle, and some of which require a qualified human. A Blueprint knows when to keep moving and when to pause.

The Bigger Picture

Agent Skills is building useful infrastructure for the broad arrange of human users. We respect that, and we’re glad the concept has gained traction.

Blueprints are doing something more specific: encoding not just how to do work, but instructing an AI agent how to orchestrate entire processes end-to-end with more or less human intervention. Legal and compliance work carries professional responsibility that general-purpose frameworks simply weren’t built to handle.

Arna’s whole thesis is that legal AI shouldn’t just answer questions. It should run entire processes, moving work forward across multiple people and steps without lawyers becoming the bottleneck at every turn. Blueprints are the building blocks of that. Structured, predictable, repeatable and built for a domain where the stakes are real.

Same concept at the surface. Different ambitions underneath.

A Question for You

Anthropic called theirs Skills. We called ours Blueprints, and we think we both proposed a name that fits its purpose.

But we’re curious what you think.

Does "Blueprints" feel right for our purpose, or would you have suggested a different name? Drop a comment or reach out. We'd genuinely like to know. We want to name things in ways that resonate with the people using them.

Some businesses are contract-heavy, some are contract-light, but almost none have no contracts. At a minimum, they need to handle purchase orders, general terms, and a handful of employment or service agreements.

For a while, a shared drive is fine. Then somebody asks which agreements are governed by the laws of England and Wales, which expire this year, or which supply contracts carry an uncapped indemnity, and a folder structure stops being an answer. That is the problem contract lifecycle management software was built to solve, and it solved it: categorise contracts, track obligations, run deadlines, keep a hundred vendors on one template rather than a hundred. Underneath sits the point most people skip. A governed contract portfolio is worth more than one that isn't. Rights you cannot find are rights you do not exercise.

So the case for CLM is sound. It just never really won.

Roughly one company in ten runs a CLM company-wide. Most of them have a love-hate relationship with it. The rest are on SharePoint, Google Drive and Dropbox. Shared drives are far cheaper, and they work about as badly as a poorly maintained, complex and overpriced CLM.

The true cost of CLM is data entry, not licenses.

Every incoming contract has to be uploaded, tagged, categorised, linked to its parent and updated when it is amended. Do that diligently and you have a genuine single source of truth. Miss it once and something worse than an error happens: the user learns to check. The first time somebody opens the underlying PDF because they did not trust the field, the field is finished. Trust in a system of record is binary, and it does not come back.

Metadata fails in four predictable ways, and each one is human. Somebody keys it in wrong. Two teams tag the same thing differently. The record is captured once at signature and never touched again. And nobody ever goes back to check whether a field is still true. The consequences are the ones CLM users complain about constantly: obligations that are hard to track, related documents that are hard to link, contracts that are hard to find inside the CLM itself, and people quietly working around the system.

Then the deployment. Migration, template preparation, integrations, workflow redesign, training, and deciding who enters what and who chases whom. Every time an in-house colleague has told me about a CLM implementation, it has sounded like a horror story. Timelines that slipped and slipped. Budgets that went well past the number anyone signed off on. Whole activities pushed back outside the system because the system would not let them do it the way the business actually worked. And the less technical members of the team quietly wondering whether they should leave, or change profession altogether.

So CLM became large company software. It works if you can afford the discipline. The bitter joke is that the discipline required to make a CLM worth having is the same discipline whose absence made you want one.

A CLM with an AI add-on is still the same CLM, with the same problems

Through 2025 and 2026, every legacy leader in the category shipped their AI upgrade: conversational front ends, clause extraction, automated metadata capture on upload. It helped. It extended the architecture's life expectancy rather than changing it.

These assistants live inside the system, and they are reactive: you go to them, you ask, they answer. CLMs do have workflow features, but those workflows are built once and rigid, so the process bends to the software rather than the other way round. Operators are compelled to follow the configured path even when they can see a better one. And the real process runs past the boundary anyway, into other tools, other people, and now other AI assistants and agents. The board approving the deal does not log in. Neither does the procurement lead doing the negotiating. An assistant inside the CLM cannot run a process that mostly happens outside it. That takes an agent sitting outside the CLM. Meanwhile, at a moment when everyone already has three chat windows they did not ask for, it was one more application and one more login, oblivious to everything the person had been doing everywhere else.

Systems of record exist to translate documents into structured, human-readable data, because no one can read four thousand contracts to answer one question. Adding AI made that translation faster. It did not ask whether the translation was still needed.

The contract is the record, not the database

A human needs the table. A machine does not. An agent will happily open the relevant fifty agreements and read the indemnity clause in each, because it takes seconds rather than a fortnight.

Which exposes the category error. The CLM treated the derived table as the system of record. It never was. The contract was always the record. The table was a workaround for human reading speed, and we mistook it for the truth.

Two things follow.

Data entry dies. Nobody should be entering a contract into the CLM, any more than anybody should be entering a prospect into the CRM. The agent does it, or does not need to. It may keep an index, and at real volume it should, because sweeping an entire corpus on every question is neither instant nor free. But it maintains that index itself, and it can always go back to the document to check. That is the difference between a database that is authoritative because somebody typed carefully and an index that is disposable because the source is one step away. It also answers the trust problem that killed the CLM. A field can drift from the contract because it is a copy. An answer read out of the contract cannot.

And the interface built on top of that database dies with it. The CLM’s screens exist because a table underneath needs viewing, filtering, and manipulating. Dashboards, saved views, report builders: all of it is downstream of the assumption that a human has to go somewhere and look. Once you can simply ask, none of it has a reason to exist. A dashboard becomes something you request, in the shape you want, on the day you want it, not a legacy screen that constrains how you are allowed to ask.

The record survives all of this, and gets better. What dies is the obligation to feed it by hand and the screen you had to visit to use it.

Your agent might read a contract, or query a CLM. That is her problem, not yours

We get asked where an agent like this sits: a new category, a CLM substitute, or somewhere on a quadrant with other legal AI tools. It is the wrong question.

Before agentic AI, software was something you gave people so they could work faster and so you could see what was happening. Then assistive AI made individuals dramatically more productive, which is why so many legal ops leaders quietly stopped delegating downwards. Both are questions about equipping people. Agentic AI is not. We assume enterprises will move beyond assistive intelligence and implement solutions that commit to workflow results instead. People will steer the system and supervise execution, rather than doing the work themselves.

So the buying question changes. It used to be: which tools do I give my team, so that when I ask which contracts expire this year, somebody can answer. Now it is: which work would I be happy never to do again, and does my agent have the access it needs to do it? Notice that the second question does not mention a CLM. Your agent might read the contracts. She might query a CLM. She might go and ask the person in procurement who already knows. That is its problem, not yours, in exactly the same way it is a junior associate’s problem and not yours. You never asked the associate which system they used. You asked for the answer.

An assistant answers the question. A coworker does the work

Do not evaluate an agent by how well it answers in a chat window. Evaluate it by whether you can hand it a piece of work and get the finished thing back.

Assign it a task in the tool you already use. Forward it the email. Then see whether the renewal notice actually goes out, whether the vendor questionnaire comes back completed, whether procurement’s request is resolved without anybody in legal touching it, and whether every step is on the record afterwards.

That is what a coworker does. You don't ask a colleague which internal systems they used, and you don't buy them a licence per screen. You give them work.

Arna is your AI legal coworker. Your lawyers instruct her once: which template, who to loop in, who signs off. Then anyone in the company can assign her a task, and she runs the process start to finish inside the tools you already use, with every step on the record. If you are weighing a CLM implementation, or wondering why the one you have isn't being used, that is the conversation we would like to have.

If your legal and compliance teams are already running on Claude, Copilot or Gemini, you have done more than most. You bought the licences, ran the training, set the policy, and got the first wave of sceptics to admit the drafts come back faster.

That work is real. It is also where most companies are about to plateau.

Publicly reported figures put the time savings from generative AI for legal professionals at anywhere from 5 to 15 hours per week per user as adoption matures — roughly the value of one extra working day a week, recovered. Estimates show that 44% of legal task hours are exposable to large language models, the second-highest share of any white-collar function after administrative work.

Those numbers describe an enormous productivity gain for the lawyer. They do not describe a faster company. The lawyer types faster. The queue at the lawyer’s inbox does not move.

That is the gap worth talking about.

The holy grail is organisation-level automation. Not individual productivity.

A copilot is a productivity tool. It makes one person faster at one task. Whatever it saves the lawyer, it saves in the lawyer’s day.

The thing the business actually needs is different. It needs the request from the salesperson, the vendor manager, the new hire, the engineer — none of whom are lawyers — to be answered at organisation speed. The metric that matters is not “minutes saved per lawyer.” It is “how many of the company’s questions got resolved this week without anyone in legal touching them.”

Doing that at the individual level is easy. Every modern copilot ships ready for it.

Doing it at the organisation level is the hard part — and it is where almost every legal AI deployment we have seen stalls. Four reasons it stalls:

1. The policy is in the lawyer’s head, not in writing. A copilot will draft against a prompt. Routing requests to AI without a lawyer in the loop requires the positions of the legal team to be codified — sometimes for the first time.

2. The end user is not a lawyer. A salesperson asking an LLM for a contract review is one hallucinated clause away from a problem they cannot detect. The interface that works for the lawyer is the wrong interface for everyone else.

3. Governance has to be designed in, not added later. Audit trail, access control, regional data residency, exception escalation — these are the entire job once requests are running without a human reviewer in the path.

4. There is no single owner. Productivity tools have an obvious user. Organisation-level automation has a designer (legal), a runner (the AI), an audience (the rest of the business), and an auditor (GC, DPO, security). Getting those four roles into one system is the work.

This is why the next layer is harder than the first. And why getting it right is worth far more.

When the end user is not a lawyer, you do not want a probabilistic LLM. You want a deterministic answer.

LLMs are extraordinary at language. They are also probabilistic by design — the same question, asked twice, can return two different answers. Inside the legal team, that is fine, because a trained lawyer is reading the output before it leaves their desk.

Outside the legal team, it is dangerous.

When a salesperson asks “can I sign this NDA?” they are not equipped to second-guess the answer. They will trust whatever comes back. If your automation layer is just a chat box pointed at a model, you will get the same five questions answered three different ways by Friday — and you will not know it happened until a deal closes on the wrong position.

For routine legal and compliance work that bypasses the expert, what the organisation needs is the opposite of free-form LLM output:

• A single, named position for each repeatable question — written by the in-house team, enforced consistently.

• Deterministic logic for routing: this NDA gets approved automatically, this one escalates to the GC, this third one needs a redline first. Same input, same outcome, every time.

• An audit trail that shows the lawyer exactly which policy ran, on which request, for whom, and what it returned — so they can refine the policy, not re-check every answer.

The AI is doing language. The decision layer is doing rules. That combination is what makes an answer trustworthy to a non-expert end user.

A copilot, on its own, cannot give you that. It is built to be helpful in the moment, not consistent across a thousand requests.

What “automating the executional layer” actually looks like

The work most legal and compliance teams do divides cleanly into two categories.

Strategic work — the M&A, the regulator response, the bet-the-company contract, the new market entry, the litigation call. This belongs in the room with the C-level. No copilot, and no automation, should be pulling that work away from a senior in-house lawyer.

Executional work — NDAs, vendor reviews, DSARs, policy lookups, standard SaaS subscriptions, sanctions screens, “can I use this AI tool for this,” “what’s our position on indemnity caps.” It is repeatable. It follows the team’s own internal playbook. It exists because policies need to be enforced consistently, not re-decided each time.

Three examples from our pipeline.

A 180-person fintech with two lawyers. Before: every vendor NDA waited for the GC’s review queue. Turnaround four to seven days. After: the GC defined the NDA position once. Standard NDAs now route back to the requester within minutes with a recommended action; only edge cases land in the GC’s inbox. Review queue dropped by roughly 70%. The GC did not work less — she stopped doing NDAs and started building the data governance framework she had been deferring for a year.

A 60-person iGaming operator. Before: the Head of Legal hand-answered “can we run this promotion in this jurisdiction” questions from marketing. After: the compliance ruleset for each licensed market sits in a deterministic layer. Marketing asks the question directly. Answers come back cited and logged, escalating to the Head of Legal only when the market combination is novel.

A regulated reinsurer. Before: information-security questionnaires from prospective clients were a two-week round-trip through security, legal, and compliance. After: the questionnaire is answered automatically against the certified knowledge base, with sign-off only at the points where a human is required by policy.

None of these replaced a lawyer. Each of them removed the lawyer from a path where the lawyer was the queue, not the decision.

What this means for your AI plan

If you have already equipped your legal and compliance teams with Claude, Copilot or Gemini, you have completed the productivity layer. The next layer is organisation-level automation: the parts of the workflow where the request never needed to touch a human inbox in the first place — and where the answer to the salesperson, the vendor manager, the new hire, the engineer needs to be deterministic, not best-effort.

A simple diagnostic for whether your organisation is ready for that shift:

• Can you list the five questions your legal or compliance team answers most often? If yes, those are the candidates.

• Does your in-house team have a written position on each one? If yes, that position is the policy. It is also what the automation runs.

• Do other employees currently wait for that team to give them the answer? If yes, that wait is the cost.

Your in-house team designs the policy. Something else should be running it — consistently, the same way, every time.

That is the shift worth making in 2026 — and the reason a copilot, on its own, will not get you there.

Arna is the workflow layer that takes a legal or compliance team’s standard positions and runs them directly for the rest of the company — deterministically, with the audit trail, governance and access control your GC requires. If you have copilots in place and the queue is still the constraint, that’s exactly the gap we’re built for.

That gap between repetition and inconsistency is what we set out to close with Arna’s updated Vendor Onboarding Blueprint.

What’s in the update

Two changes matter most.

1. Fine-tuned vendor categorisation. Not every vendor needs the same treatment. The blueprint now classifies vendors into four types: a general vendor (e.g. office supplies), a normal ICT provider, a critical ICT provider supporting a Critical or Important Function under DORA Art. 8(5), or an outsourced business function under the applicable national framework. There’s also an edge case for vendors that are both critical ICT and an outsourced function. The classification decides which scoring sheets apply, which clauses are mandatory, and which are nice-to-have. You stop applying critical-ICT scrutiny to a stationery contract — and you stop missing it on the SaaS tool that is quietly underpinning your KYC pipeline.

2. Pragmatic Mode. This is the first blueprint we’ve shipped with Pragmatic Mode, and it’s the change we’re most excited about. When Arna reviews a vendor contract, it proposes only the amendments and negotiating points needed to get to DORA and MiFID compliance. Not commas. Not stylistic preferences. Not a wishlist of clauses your in-house counsel might prefer in an ideal world. The smallest possible set of changes that gets the contract over the regulatory line.

That matters because vendor negotiations are zero-sum on attention. Every redline raised costs goodwill and time. Pragmatic Mode keeps your political capital for the clauses that actually move the risk needle such as Art. 30(3) audit rights, exit strategy, business continuity, data location, subcontracting consent.

End-to-end, with humans in the loop only when needed

Arna runs the process from the moment a vendor is proposed through to a signed audit report. It identifies the vendor, asks clarifying questions where it needs to, classifies the vendor type, scores the contract against the applicable sheets, calculates a weighted risk classification, and produces a standardised PDF report you can hand to a regulator.

It loops in a human only when needed: when a clause is genuinely ambiguous, when a risk crosses an escalation threshold, or when final approval is required. Otherwise, it runs through. The audit reports it produces are standardised across vendors, comparable across deals, and predictable in structure. A Head of Compliance reviewing a quarterly batch sees the same output shape every time.

Use ours, or make it yours

Arna gives our customers two paths. The first is to run our blueprint as-is. It encodes the regulatory baseline, and for many firms, that’s enough. The second is to adjust the blueprint to fit how the firm actually runs: who approves, who escalates, what the audit trail looks like, what the deliverable is shaped like, and where the human-in-the-loop checkpoints sit. The blueprint is the floor, not the ceiling. Many of our customers also build their own blueprints from scratch in Arna, encoding internal know-how that has previously lived only in the heads of their senior compliance team.

The point is that you don’t have to choose between “buy a rigid tool” and “build everything yourself.” You inherit the regulatory work we’ve done, and you keep the parts of your process that already work.

“Why not just use ChatGPT or Claude?”

Off-the-shelf LLMs are incredibly helpful. Used carefully, with a good prompt, they help an experienced lawyer think through a vendor contract. You can even build your own prompts and skills on top of them. Where Arna pulls ahead is at the organisational level, not the individual one.

- Standardisation across the firm, not the user. Anyone onboarding a vendor follows the same process. The Head of Legal isn’t auditing whether the procurement lead actually checked Art. 30(3). They know the blueprint did.

- No learning curve. A non-lawyer can run a vendor review end-to-end. The blueprint encodes the regulatory framework, so the user doesn’t have to.

- Knowledge you don’t have in-house. If you don’t have deep DORA or MiFID II expertise sitting at every desk, the blueprint still gives you a reasoned, defensible review.

- Scale and oversight. A manager can monitor the queue, see which cases are stuck, and intervene. You don’t get that visibility from one-off conversations in a chat window.

- Audit trail by default. Every review produces a standardised PDF that a regulator can ask for tomorrow. You’re not stitching together screenshots after the fact.

- Predictable behaviour. The same input produces the same shape of output. Risk classifications are calculated, not vibed.

A general-purpose chatbot is a tool that an individual uses well. A blueprint is something an organisation runs.

What this means for you

If you’re a COO trying to make vendor onboarding less of a fire drill, a Head of Legal tired of every contract review starting from a blank page, or a Head of Compliance who wants to know the same process is being followed regardless of who at the firm clicked “approve”, this is the blueprint to look at.

We’d love to walk you through it.

Get a demo

There was a common fallacy in the enterprise SaaS world that a product’s adoption depends solely on the quality of user experience. “If we could only polish the UI to the point at which it starts reminding users of Apple, they will love our product.” In reality, it’s the quantity of user experience that drives adoption much more.

Mr Weber from HR doesn’t bloody want to learn another UI, no matter how polished it is. He hasn’t quite mastered the previous eight he was all but forced into.

Most of us, AI enthusiasts, are failing to realise how small of a bubble we’re in. Most people in most organisations won’t utilise Claude Cowork. Some won’t because of red tape. Others simply won’t want to.

That doesn’t mean they won’t necessarily be able to reap benefits of working with AI.

Software has indeed made life better for those who mastered it, but AI is not software as we know it, save for the fact it is code that is running on a computer. Unlike traditional software, AI can connect with people via tools they already use, in unstructured ways every human is already used to.

There is no need for new, “AI-powered” editors, plugins, spreadsheets. These are just examples of people applying old solutions to new problems. And failing to understand whose time has come.

Stage One: Legal Assistance Tools

When ChatGPT, Claude, and Gemini entered the mainstream, they were genuine productivity boosters for lawyers. These tools could draft documents, analyse contracts, summarise information, and generate legal analysis at speeds that would have taken hours manually. They empowered individual lawyers to get more done in less time.

But here’s the catch: the lawyer remained the bottleneck. If the AI generated three contract variations, a lawyer still had to review them, pick one, and manually move it to the next step. If nobody asked the AI to do something, nothing happened. The AI was a task executor responding to direct instructions, not a system pushing a process forward. Productivity increased, but workflow dynamics didn’t fundamentally change.

Stage Two: Legal-Specific Tools

The next generation - tools like Harvey and Legora - added legal domain expertise. They understood legal workflows better and could handle more complex tasks. But they inherited the same structural problem: they still required lawyers to pull information from them and manually orchestrate what happens next.

These generation of tools has recently started to add self-service or agentic functionality. However, having an assistant and an agent in the same box is tricky. These two solutions are fundamentally different in how they operate, and what is the level of knowledge of their users. It is hard to have it under the same umbrella.

Stage Three: Legal Process Automation (we are here now)

Enter process automation. Instead of AI assisting individual tasks, AI now orchestrates entire multi-step, multi-stakeholder processes end-to-end. Think hiring someone, onboarding a supplier, organising an annual general meeting, or issuing new shares. The AI runs the entire workflow, collects information at each stage, generates necessary documents, and pushes the process forward automatically.

Here’s what makes this different: humans stay involved, but as intelligent decision points rather than process drivers. You define which steps the AI can autonomously finalise and which require human input, approval, or judgment. One organisation might want human sign-off on every NDA; another might trust the AI to handle routine supplier onboarding but require approval on contract terms. You control the risk profile.

This removes the lawyer as a bottleneck. The process moves forward with or without active direction. The AI reminds, collects, analyses, and proposes; humans verify, decide, and approve where it matters.

Stage Four: Autonomous Legal AI

Eventually, we’ll see fully autonomous AI systems operating as proactive general counsel. These systems won’t just run processes when asked; they’ll identify legal risks, flag opportunities, and make certain decisions independently. Many decisions will always require human judgment, but routine and mid-way decisions will be made by the AI.

We’re not there yet. But understanding this trajectory helps you think clearly about what you actually need today.

This is one of the biggest resource wasters in modern organisations. Because such an email provides limited (or no) relevant information, the lawyer has to ask a series of questions to better understand the situation. This back-and-forth process, often like a game of ping-pong, can be frustrating for both legal and non-legal teams. The time it takes to gather all the necessary details and understand how to proceed can be significant, leaving everyone involved feeling the strain of inefficiency.

Legal AI assistants that help with review, drafting, and summarising do not solve this problem at all, because the bottleneck is communication between the lawyer and the business manager requesting legal support.

Even more, in-house departments often struggle even with the basic triage of dividing incoming matters into urgent and non-urgent. The cause is not necessarily the lawyers, but rather the fact that they often lack sufficient information for triage.

This problem is not isolated to a few companies but is a widespread issue affecting many in-house legal teams. Even the teams themselves are acutely aware of it. 90% of legal staff report feeling they slow down other companies’ functions. On average, it takes 32% longer to close a deal with a customer due to the involvement of legal.

Through time, companies come up with a unique and ingenious solution: a form to fill in, with questions like “Why should we sign this?” and “What is the business goal?” which are often answered without conveying any meaningful information, such as “It’s a good deal, and we need to hurry”.

Triage is often an underlying source of the problem.

In-house legal teams often struggle to allocate work efficiently. You can’t blame them. They are flooded with diverse matters, and allocating them correctly is challenging. Requests can be easy or complex, urgent or non-urgent, high- or low-value, and repetitive or unique, and they relate to various fields of law. For every request, a responsible layer must understand the factual background, the legal grounds, the business goal and commercial challenges.

Without optimal triage, matters are not allocated to the correct lawyer, and much time is wasted in back-and-forth discussions with the assigned lawyer and the user to gather all relevant information and resolve the matter. Without complete, correct and relevant information, AI does not return correct results.

Offer an intuitive way to request legal support.

Users, who are company employees, need an intuitive way to request legal support that naturally fits into their operational flow. Ideally, they should be using the tools they already use daily, such as email, Slack, or Teams. The system should act as a single entry point for all legal requests, so the users do not need to research which in-house lawyer is the competent (and available) one. Filling out an 18-question form is neither user-friendly nor productive. Users should be encouraged to provide all the relevant data and circumstances so that the lawyers can get a complete picture of the matter.

Allocate matters to the most suitable lawyer. Or to AI.

By implementing a triage process, you can ensure that the right people or AI do the right work. Triage should classify matter requests according to various criteria, such as urgency, importance, complexity, risk, value, legal field, and repetitiveness, and allocate them to the most suitable solution provider. Today, this is the most suitable in-house lawyer. Tomorrow, it will also be an AI agent. Allocating matters among the most suitable lawyers and AI can improve the utilisation of in-house lawyers and enhance the quality and timeliness of the legal work.

Collect and manage data.

Collecting and organising data for each matter is fundamental to successful triage. If the data is concise and complete, the responsible lawyer will require less time to provide a solution, or, in the case of AI, the solution is more likely to be correct.

Analytics to manage your resources better

By implementing a triage process, you can manage your legal team effectively. You will be able to understand which tasks burden your legal team the most and which legal fields require more or less capacity. This can enable you to make informed, data-driven decisions about team management, in-house lawyer hiring and implementation of AI automation.

AI to the rescue

AI assistants have become productivity boosters for everyone, including lawyers. But they do not fix the bottleneck problem. Even with AI assistants, matters can get stuck on lawyers’ desks. AI Automation can change that. It can intake requests, collect information, organise it, and either provide solutions or engage the most suitable lawyer from the team.

For the past two months, I’ve been working on a new startup with my old friend, Nejc, and a couple of early customers. It’s called Arna and it can reliably automate in-house legal work, especially when it involves more people.

We have raised a pre-seed round from a group of angels and investors with a track record in entrepreneurship. We are using the money to develop Arna and prove its value across use cases.

Why?

A tech startup can now do one of 3 things: models, assistants or automation.

Model vendors are a prestigious club with unprecedented access to capital and talent. Bless their GPUs. I like to think of them as employment agencies that offer an unlimited supply of artificial knowledge workers who become cheaper and smarter every odd week.

What they have been able to do for us so far has mainly depended on the second type of startup: those building assistants. Unlike models, assistants are easy to make. There are hundreds of them in legal alone. While some have skyrocketed, there are now lawyers who are vibe coding their clones in a weekend.

Assistants help us do our job faster, but they don’t attack the inefficiencies inherent to human organisations. You “hire” one or two of them to “sit” next to you and help you research, code, draft or review documents, etc. but they don’t actually pick up your work.

Automation is when AI agents aren’t assistants, but rather parts of our organisation. You email Arna like you would a colleague. It sends a document for you to review, like a colleague would. It is following the same rules and accessing the same internal knowledge as you, so you don’t have to explain everything over and over again.

Assistants scale vertically by enabling us to do tasks faster. Automation scales horizontally, by picking up tasks, so we don’t have to.

AI adoption in enterprises sucks because assistants aren’t enough, while automation isn’t something one can vibe code in a weekend. Knowing what to develop demands building relationships and unlocking internal knowledge. Being “forward deployed”, as it were.

I’ve spent my entire career developing products and engineering teams that serve businesses. The last 3 years I’ve spent building data pipelines and automating various tasks in sales organisations with AI. I will now do the same in legal with the help of Nejc, one of the brightest lawyers I know, who has also learned these lessons over the past 2 years while developing a legal AI assistant.

Legal, because, after coding, it is being most profoundly reshaped by AI. Now, because the models have become both good enough and cheap enough to support complex workflows. Nejc and me, because, besides complementary skillsets, we both love a good conversation, which, in the future, may turn out to be the last viable skill.

I will share more thoughts about our progress, findings and AI in general. I’m told it’s good for marketing. Thank you for your support and looking forward to automating all the boring parts of work.

Founded by Rodoljub Petrovic (formerly led engineering at Celtra, Turtl and Weflow) and Nejc Novak (the founder of law firm Nlaw), Arna represents a strategic fusion of deep legal expertise and high-scale engineering. Unlike the current wave of “assistive” AI tools designed to help lawyers work faster, Arna is built for the company itself, embedded in its operation, aiming to replace the traditional, costly reliance on external law firms for both routine and strategic legal matters.

Beyond Chat: Autonomous Legal Blueprints

At the core of Arna’s platform are Blueprints - curated, end-to-end solutions for specific legal challenges. These are not mere templates; they are intelligent workflows that help companies identify barriers, map out strategies, and execute legal tasks - from securing MiFID licenses to managing global employment compliance - without the immediate need for a billable-hour lawyer.

“The industry has focused on AI as a co-pilot for lawyers. We believe the future is AI as a pilot for the business,” says Nejc Novak, CEO of Arna. “By enabling employees to solve more legal problems with no or minimal involvement of lawyers, we aren’t just reducing the pressure on in-house teams -we are fundamentally changing the procurement of legal services. For many companies, Arna will be the reason they don’t hire a traditional law firm, and their in-house teams will have more time to focus on high-value strategic matters.”

Proven Impact: 60+ Jurisdictions and Regulatory Wins

Arna has spent the last three months in stealth, proving its model with forward-thinking companies, such as Native Teams (on managing employment law compliance across 95 jurisdictions) and Iconomi (on EU financial services licences), demonstrating Arna’s ability to navigate high-stakes regulatory environments.

A pre-seed of European Backing

To fuel its mission, Arna has raised a pre-seed round led by an angel ticket from Jani Valjavec, with participation from Fil Rouge Capital, daFund, and Jernej Strasner (Accel Starter). This group of EU-based investors is providing Arna with access to a wide network across the continent as it prepares for rapid expansion.

“We saw a massive gap between ‘chatting with documents’ and actually ‘getting legals done,” says Rodoljub Petrovic, CTO of Arna. “Our focus now is on expanding our Blueprint library and scaling our infrastructure to support companies across Europe as they transition to a more intelligent, autonomous way of handling legal operations.”

The capital will be used to scale the product and prove its value beyond the first few customers and legal verticals.

About Arna

Arna is a cloud platform that helps companies automate their legal tasks with AI. Through its proprietary, lawyer-designed Blueprints, Arna provides the intelligence and workflows needed to solve legal problems, manage risks, and reduce external counsel spend.

To learn more, visit arna.ai.