Occasionally I do a Foundation post. Back to basics. This is one of them.

I've been writing this thing for three and a half years and about 290 issues. Most of them chase what just happened. This one does the opposite.

Here is the problem I keep running into, in firms and in my own inbox. Two people use the same word and mean different things, and neither of them knows it. A partner says "agent" and pictures a chatbot. The vendor across the table says "agent" and means a piece of software with autonomous access to the document management system. Everyone thinks they are talking about the same thing. And nobody is talking about the same thing, and the buy decision gets made anyway.

The terms drift. That's not sloppiness on anyone's part, it's what happens when a field moves this fast. That is why this issue is a reset: what the core words actually mean right now, in August 2026, translated for people who practice law rather than build models.

Some of you have been building agentic systems for a year. Some of you opened ChatGPT last month. Read what's useful, skip what isn't.

August 2026 Glossary Update

MODEL

A model is a function. You put something in, you get something out.

That's the whole thing. If you give it an image and it tells you what's in the image, it's an object recognition model. If you give it a series of words and it produces the words that should come next, it's a large language model. Input, transformation, output.

Say that out loud the next time a vendor demo makes something sound mystical. Not magic. A data transformation implemented in software.

Models are named by what goes in and what comes out. Text in, text out is a large language model. Text plus images in, text out is a language-vision model, which is what reads your scanned exhibits. Text in, image out is an image generation model. There are forecasting models, anomaly detection models, and plenty of others, and not all of them are built on neural networks, though most of the ones dominating the conversation are.

Why a lawyer should care: because "AI" is not one thing you adopt. It's a category of functions, and the useful question is always which transformation you actually need. A firm asking "what's our AI strategy" is asking a question too vague to answer. A firm asking "which transformations, on which inputs, in which workflows" is going to get somewhere.

INFERENCE

One run of the function. One input in, one output back.

You care about this word because it's the unit you're billed in (related to tokens below). When your vendor quotes usage, when your CFO asks what the AI line item is, when someone tells you an agent ran overnight, the underlying meter is counting inferences and the tokens inside them.

WEIGHTS (parameters)

Running a model takes two separate things. Software that executes the function, and a large set of numbers that configures the software to behave the way it does. Those numbers are the weights, sometimes called parameters.

Think of the software as the kitchen and the weights as the recipe. Both are required. They're owned and distributed separately, which is the entire basis of the next definition.

OPEN WEIGHTS VS. CLOSED

An open weight model is one where you can obtain the numbers (the recipe). Download them, run them on your own hardware, in your own environment, under your own control. Google's Gemma family works this way, along with a long list of others.

A closed model is one where the weights, the software, or both stay with the company that built them. You reach the model through an API or a chat window, and the model itself runs on the vendor's infrastructure. That's the arrangement behind most of what your firm is licensing today.

Note the sloppiness worth avoiding: people say "open source" when they mean "open weights." Those aren't the same claim. Open weights means you can run it. Open source implies you can see and modify the code that produced it. Precision here matters when you're reading a vendor's security page. But don’t worry, unless you are working with a top tier forward deployed engineering expert like Rob Saccone or company like Palantir, you are not getting this option. But you will want it soon, trust me.

Why a lawyer should care: this is the single most consequential distinction on the list, and it's the one most often skipped in procurement. It determines where client-confidential material physically goes, what you can promise a client about data residency, and what you'd actually be able to take with you if you left the vendor. I spent an entire issue on that last question recently. The short version: if the answer is "our prompts and a negotiation over data export," you don't own what you think you own.

One huge complication. If a firm wants to run a genuinely capable model on its own infrastructure today, the strongest openly available options largely come out of Chinese labs. American labs lead at the closed, API-accessed frontier. That's a real tension for firms with government contractor clients, national-security-adjacent work, or clients who will ask pointed questions about provenance. I'm not telling you what to conclude. I'm telling you it's a question your IT committee should be able to answer out loud.

FRONTIER MODEL

The largest and most capable models, the ones requiring hardware most organizations can't justify owning. This is the Claude, GPT, and Gemini tier. Enormous data centers, enormous capital.

The counterpoint that gets lost: not everything needs the frontier. Smaller models run on modest hardware, sometimes on a laptop (I have a few doing this), and for a well-defined narrow task they're frequently sufficient and dramatically cheaper. Routing every task to the most expensive model available is the most common waste I see inside firms.

AI FEATURE VS. AGENT

This is the distinction that costs firms the most money when they get it wrong, so slow down here.

An AI feature is a model wired into software for a one-to-one interaction with a person. It's turn-based. You type, it responds, you type again. A drafting assistant in Word is a feature. A clause suggestion in your CLM is a feature. Chat is a feature.

An agent is software wrapped around a model that has been given a goal, some degree of autonomy, and access to real systems. Your email. Your calendar. Your document management system. Your billing platform. You express an outcome rather than a prompt, and it works toward that outcome without a human turn between each step.

The difference is not sophistication. It's goal plus autonomy plus system access.

Why a lawyer should care: those three things are exactly what your professional obligations attach to. A feature produces a draft you review before it goes anywhere. An agent takes actions in systems of record, sometimes while you sleep. Supervision, competence, and confidentiality all read differently against the second one, and "we deployed an AI tool" is not a description that distinguishes between them. Make your vendors and your own innovation team say which one they're building.

AGENT HARNESS

The software layer that runs the agents. It decides which model gets called, in what order, with which tools, and with access to what.

Why a lawyer should care: the harness is where your firm's actual policy lives. Not in the memo circulated to the partnership. In the configuration. Permissions, boundaries, what an agent may touch and what it may never touch, whether a human approval step exists before an action executes. If you want to know a firm's real AI governance, ask to see the harness configuration rather than the policy document.

FLEETS AND SWARMS (advanced)

More than one agent, each with a defined role and its own access, working on parts of a larger problem.

A swarm is usually a fleet, but a fleet is not necessarily a swarm. A fleet is a group of agents doing assigned work. A swarm adds heavy cross-communication and task-sharing among them.

This is also where mixed model architectures show up. A large model for the reasoning-heavy step, small specialized models for the narrow ones. Nobody serious is running everything through one brain anymore.

VERTICALLY INTEGRATED VS. INTERCHANGEABLE

Two shapes in the market, and you're choosing between them whether or not you realize it.

Vertically integrated: one vendor supplies the compute, the model, the harness, and the interface, in an opinionated bundle. Copilot across the Microsoft estate. Gemini across Google Workspace. The hyperscalers' agent platforms.

Interchangeable: the harness and the model are separate layers, and you can swap the model underneath. Open or closed, one or several.

Both shapes will persist and both are legitimate. The failure mode is arriving at a vertical stack by default, without deciding.

OPINIONATED VS. UNOPINIONATED

This is the word I most want you to leave with, because it explains why using Harvey or Legora feels so different from sitting in front of Claude or ChatGPT, and because nobody in a sales meeting will define it for you.

"Opinionated" comes from software design. An opinionated tool has decisions already made inside it. It holds a view about the right way to do the work, and that view is built in rather than offered to you as a setting.

Here is what specifically gets decided for you inside an opinionated legal AI product:

The model. The vendor picked it. You usually cannot swap it, and often cannot find out which one you're using on a given day.

The instructions. Every product injects a hidden layer of instructions that shape the model's behavior before your text ever reaches it. You don't see that layer. I made this the whole point of an earlier issue: ask your vendor for their system prompts, and watch what happens.

The workflow. When you press the contract review button, the tool runs somebody's contract review methodology. Steps, order, what gets checked first, what gets skipped.

The definition of good. Someone decided what a good diligence summary looks like. What belongs in it, how long it runs, how much hedging is appropriate, when to flag versus when to stay quiet. That judgment now operates inside your matter.

Retrieval. What sources it reaches for, how it breaks documents up, what it treats as authoritative.

Refusals. What it declines to do, which is set for a general customer base rather than for your criminal defense practice.

The closest analogy in our world is using another firm's precedent bank. Genuinely useful. Fast. Written by capable people. But it encodes their risk tolerance, their client base, and their house style, and a lawyer who works exclusively from it slowly stops developing their own.

The case for opinionated. Speed to value is real and shouldn't be sneered at. Nothing to assemble, nothing to configure, no prompt engineering required from people who bill by the hour. You get consistency, which means the floor rises: your least sophisticated user produces something defensible. The vendor has seen thousands of firms and their opinion may honestly be better than the one your firm never wrote down. Training burden drops to one button. Someone else maintains the thing, upgrades the model, tunes the prompts, handles the security review. For most firms on most tasks, this is the correct starting point, and I'd rather a firm ship an opinionated tool than spend eighteen months designing the perfect flexible one.

The case against. The ceiling drops as the floor rises. Output converges toward the vendor's average, which is a problem if what you sell is that your diligence is different from the firm across the street. You cannot inspect the opinion, so you are supervising an output without visibility into the process that produced it. The opinion changes without telling you: a model swap or a prompt update lands on a Tuesday, your outputs shift, and there is no changelog you get to read. The tuning and workflow knowledge your people accumulate stays with the platform. And when the embedded judgment is wrong for your practice, it's wrong consistently, at scale, across every matter that touched it.

Unopinionated is the other end. Going directly to Claude or ChatGPT, or building on a harness where you choose the model and write the instructions. You supply the judgment. Your method, your standards, your definition of good, visible and adjustable because you wrote them. Model choice stays yours. Marginal cost is often far lower. And what you build compounds into something the firm actually owns.

The cost is brutal in a specific way: you have to have an opinion. Most firms do not have a documented method to encode. They have partners who each do it their own way and have never written it down. Unopinionated tooling exposes that immediately. It also brings setup cost, maintenance cost, real inconsistency between users, and no guardrails except the ones you build.

Two things to hold onto. First, this is a spectrum and not a binary, and most firms should end up with both: opinionated products for high volume standardized work, unopinionated capability where the firm's actual differentiation lives. Second, there's a growing middle, where you take an opinionated platform and layer your own configuration, playbooks, and standards on top of it. That middle is where I see the most serious firms operating right now.

The diagnostic question, and it's short enough to ask in any demo: whose judgment is in this output, and can I see it?

TOKENS, AND THE END OF TOKEN MAXING

Tokens are the units of text a model reads and writes, and they're what you're billed on. Inference (above) consumes tokens.

The relevant news is behavioral. There was a stretch where the reflex was to throw maximum context and maximum model at every problem. That's over, and it ended for the least surprising reason: the invoices arrived. The current posture is architectural. What's the cheapest configuration that reliably accomplishes this task?

This matters more with agents than it ever did with chat. An agent operating autonomously for hours or days has a cost profile that looks nothing like a lawyer typing into a chat window, and firms are discovering that in arrears.

BENCHMARKS VS. EVALS

These two words get used interchangeably in vendor materials. They are not the same, and confusing them is how firms end up buying on evidence that means nothing to their practice.

A benchmark is a standardized public test, run against many models so they can be compared. You've heard the names even if you haven't registered them: MMLU, GPQA, and in our world LegalBench and CaseHOLD. When a vendor's slide shows a bar chart of their model beating another, that's a benchmark.

The right analogy is the bar exam. Standardized, comparative, and genuinely informative about one thing: whether someone cleared a general threshold. It tells you almost nothing about whether that person can handle your matter, for your client, in your jurisdiction, to your standard. We learned this lesson already and then forgot it. When the headline was that a model passed the bar exam, the profession treated it as proof of competence at legal work. It was proof of competence at the bar exam.

Three specific reasons to discount benchmarks. Contamination, meaning test questions leak into training data and the model may have effectively seen the answers. Overfitting or benchmaxxing, meaning labs optimize for the tests that generate headlines. And generality, meaning even a clean, honest benchmark measures capability in the abstract rather than performance on your work.

An eval is your own test. A set of representative tasks drawn from your actual practice, with a defined standard for what a good answer looks like, run repeatedly against a system to see whether it performs and whether it's still performing after something changes.

I wrote a full issue arguing that firms should own the exam rather than accept the vendor's. Here's the practical version of how you build one.

Start by collecting twenty to fifty real examples from a single workflow. Real matters, redacted, representative of what actually comes through the door rather than the clean hypotheticals. Then have a senior lawyer produce or approve the correct answer for each one. That step is the hard part, it cannot be delegated to the vendor or to the innovation team, and it is where most eval projects die.

Next, define failure concretely. Not "was this good," which no two partners will score the same way, but specifics: did it miss the indemnity cap, did it catch the change of control provision, did it cite a case that does not exist, did it flag the issue a first year would have missed. Then run the system against the set and score it. Then run it again after every meaningful change, including the ones you didn't authorize.

That last point is the one I'd underline. The highest value use of an eval isn't the initial buying decision. It's regression testing. Your vendor updates a model or adjusts a prompt, your outputs quietly change, and without an eval you find out from a client. With one, you find out on Tuesday.

Notice how this connects to the previous section. The more opinionated your tool, the less you can inspect the process, which means output testing is the only inspection available to you. Opinionated tooling doesn't reduce your evaluation burden. It concentrates it.

And here's the uncomfortable thing about building an eval, which is also the argument for building one. Writing down what a good answer looks like, at the level of specificity a test requires, is the same work as articulating your firm's method. Most firms have never done it. The ones that do get a testing capability and a written account of their own standards, which turns out to be the more valuable of the two.

IN CLOSING

Start small, iterate fast, experiment your way in, and keep backup plans. I'd also add one thing specific to us.

You will hit guardrails. Frontier models refuse things that lawyers legitimately need like a criminal defense matter involving violence, a harassment case with explicit content in the record, a hostile investigation. When it happens, that isn't a reason to abandon the work. It's a reason to have already known which alternative you'd reach for.

There are a lot of people on LinkedIn calling themselves AI strategists, and if you claim the title, the job is figuring out how to apply these specific resources to the actual needs of the business inside a genuinely messy ecosystem. Anything less than that is just vocabulary, not expertise.

The words are only worth anything if you can act on them.

To read previous editions, click here.

DISCLAIMER: None of this is legal advice. This newsletter is strictly educational and is not legal advice or a solicitation to buy or sell any assets or to make any legal decisions. Please /be careful and do your own research.