Last week Anthropic ran a session called Claude for Legal Teams. Twenty thousand people registered. The room submitted 51 questions and upvoted them 2,470 times. The upvote pattern is the most honest piece of legal-tech research I've seen this year. This is the conversation the webinar didn't have time to finish — what Mark Pike (Anthropic's legal product lead) and Maggie Russo (applied AI) said when they got to a question, what they didn't get to, and the parts I think they got partially right but not all the way home.
Last week Anthropic ran a session called Claude for Legal Teams. Twenty thousand people registered. Their host, Nancy from marketing, said on air she had never seen a number like that for a legal webinar. I believe her. The room submitted 51 questions and upvoted them 2,470 times, and the upvote pattern is the most honest piece of legal-tech research I've seen this year.
Key facts
- Anthropic's Claude for Legal Teams webinar drew 20,000 registrants, 51 submitted questions, and 2,470 upvotes.
- Four privilege/security questions captured 1,050 upvotes — 42% of all session attention; the top single question got 372 votes.
- HAQQ serves ~9,800 firms, mostly small and mid-size, mostly outside the big tech-buying centers.
I run a company in this space. We build HAQQ, a legal-AI platform that today serves around 9,800 firms — mostly small and mid-size, mostly outside the big tech-buying centers, mostly the firms nobody runs webinars for. So when 20,000 of their cousins show up to a session about Claude, I pay attention. I downloaded the recording. I read every question. I sat with the transcript for an evening. Then I wrote this.
This isn't a recap. The recording is online if you want one. This is the conversation the webinar didn't have time to finish — what Mark Pike (Anthropic's legal product lead) and Maggie Russo (applied AI) said when they got to a question, what they didn't get to, and the parts I think they got partially right but not all the way home. I'll mark each clearly. Where the room asked something nobody on stage answered, I'll answer it the way I'd answer it to a partner who paid me to.
A note before I start. The questions are not mine. They came from real lawyers, real paralegals, real legal ops leads, and they put their names on them. Where I quote a question I'll attribute it. The upvote counts come from the live session. The story you're about to read about Andrew the paralegal — that one stays with me, so I'll start there.
A four-person team. One MLaw 200 firm. A jury verdict.
Mark told this on stage and I want to retell it because it's the answer to a question nobody upvoted, but everyone secretly asks. Is this stuff actually useful, or are we doing AI theater?
Andrew is a paralegal. He was on a four-person pro bono team — two lawyers, two paralegals — defending an elder abuse case against an MLaw 200 firm. That's a fight you don't win on hours billed. So Andrew built a tool on Anthropic's API that sat at counsel's table during the trial, pulling in cross-examination angles in real time, sometimes before opposing counsel finished asking the question. The four of them walked out with a large jury verdict for their client.
I want you to hold that for a second. A paralegal. Wrote code. At trial. Won.
Now read the next sentence carefully: that is the median use case, not the ceiling.
The webinar opened with that story for a reason. The 51 questions that followed are what happens when 20,000 people in a profession that survived on quill-pen tradition for 800 years collectively realize the technology is real and the only remaining question is whether they will use it well or use it badly. Nobody upvoted will AI replace lawyers. That debate is over inside the profession. Everything in the chat was operational. How do I do this without losing privilege. How do I verify. How do I roll out. How do I integrate. How do I avoid the naughty list.
Let me walk you through what they asked, in the order the upvotes ranked them — but first, the framing Mark used to set up the entire session. It's worth keeping in mind as you read the rest, because every question that followed connects back to one of these four ideas.
§1 — Mark's four pillars: how Claude actually knows your legal work
Mark walked through what he called the four pillars of how Claude does legal work. I'm going to use them as the spine of this article because (a) they're the right frame and (b) most of the audience questions map onto one of them. If you watched the webinar, this section will feel familiar; if you didn't, this is the thirty-second version of the architectural picture Anthropic is selling.
Pillar 1 — Live data via Model Context Protocol (MCP). Mark called MCP the "USB-C of AI." It's an open protocol that lets Claude connect to your live systems — your matter management software (iManage, NetDocuments), your CLM, your Drive, Outlook, Microsoft suite, Slack, calendar. The point is not that Claude uploads a snapshot of your work; it's that Claude reads the same files your team does, live. The redline that lands at 4 p.m. is visible at 4:01 p.m. without anyone reuploading anything. This sounds obvious until you remember that most enterprise AI deployments today are still PDF-uploads-over-Slack with eternal staleness.
Pillar 2 — Legal skills. A "skill" in this world is a markdown file that codifies a workflow your team already runs every week. NDA review. Contract redlining. Privilege log drafting. Matter intake. Clause library checks. Precedent search. Deal point analysis. Mark's framing was important: "Claude doesn't just start from a blank page on the work you do hundreds of times a year. It pulls from that corpus of knowledge that you've created within your department." Skills make institutional muscle memory portable. They are also, Mark said, recursively buildable — you can ask Claude to write skills for you by feeding it examples of past work.
Pillar 3 — Document comprehension. This is the pillar most people underrate. Claude reads agreement structure the way a lawyer does. It tracks defined terms across exhibits and schedules. It explains in plain English what a clause actually does and flags exactly where the risk sits. This is not keyword search and it is not text summarization. It's structural comprehension of how legal documents hold together — defined terms cross-referenced to where they're used, exceptions traced to where they overrule the general rule, schedules linked to the operative provisions they expand. The capability gap between "summarize this MSA" and "find every place this MSA's standard terms are quietly overridden by a side letter" is enormous, and Pillar 3 is what closes it.
Pillar 4 — Context across apps. The redline you ran in Word becomes a summary slide in PowerPoint, becomes an email draft in Outlook, becomes a follow-up calendar invite — and Claude carries the context of the original work all the way through. One thread. No re-explaining. No copy/paste handoffs. Mark's exact phrase: "The work moves with you." If you've ever spent twenty minutes restating the matter background to a colleague over Slack, or worse, to an AI that forgot what it was doing between two interactions, you understand viscerally what this pillar is solving.
You don't need to fine-tune models to give Claude the engineer a legal degree. Instead, you just need to give these tools access — the same tools that the lawyers use every day to get their work done. And that's what helps it become a great teammate within the legal context.
That sentence is the whole architectural bet. Anthropic isn't building a "legal AI" that's a different product from its general AI. It's building a single capable model and giving it the same surfaces lawyers already work in. The tailoring happens in skills, plugins, connectors, and matter context — not in the model weights. Whether that bet is correct over the long run is a question I'll come back to. For now, hold the four pillars in mind. Almost every audience question lands on one of them.
A second piece of vocabulary you'll see throughout: Mark's coinage amp-fooding. Anthropic employees call themselves "ants," so the dogfooding equivalent is amp-fooding. They use Claude to build Claude. Mark's legal team uses Claude on its own legal work. That recursion is doing more work than people noticed in the webinar — when you hear about a 742-JIRA-ticket analysis or a redline workflow that took 20 minutes, those are amp-fooded artifacts. Not hypotheticals. Things Anthropic's legal team did to itself before showing them to you.
§2 — Privilege is the question behind every other question
Four questions on attorney-client privilege and security got 1,050 upvotes between them. That's 42% of the entire session's attention focused on a single concern. The number-one question, with 372 votes, was Jewel Seo's: "How is your team dealing with attorney-client privilege when using Claude?"
Mark answered it directly, and his answer was honest in the way only a lawyer can be: I'm not your lawyer. Talk to your lawyer. But underneath the disclaimer he made three substantive points and one meta-point, and they're all worth pulling apart.
The substance was this. First, the recent Heppner ruling — which Mark said the legal industry is "really sort of waking up to" — involved a non-attorney using a consumer-grade AI plan, working at their own direction, with privacy settings unconfigured. That's the case being passed around LinkedIn as a privilege cautionary tale, and the framing matters: it was not a case about whether lawyers can use AI. It was about what happens when you use the wrong tier. Second, on Anthropic's commercial offerings — Team and Enterprise — with privacy settings configured correctly, Mark said he was "quite confident" you can maintain privilege. Third, the ABA actually has ethics rules requiring lawyers to stay current on technology. Not using AI is not a neutral position; it's a deliberate one, and increasingly a defensible-only-on-purpose one.
The meta-point was the most interesting. Mark compared the moment to the late 1990s arguments about whether lawyers could use email, and the early 2000s arguments about cloud-based SaaS. We won those. We are going to win this one. The only question is whether your firm wins it gracefully or scrambles.
Here's what Mark didn't say, and what I'd add as someone who builds in this space.
Privilege isn't a feature you toggle in a settings page. It's a workflow property that has to be true at every layer simultaneously. There are four layers, and most of the conversations I have with general counsel collapse them into one and miss two.
The contract layer. Your AI vendor cannot use your inputs to train models. This is contractual, not technical. On Anthropic's enterprise tier this is in writing. On free Claude.ai it isn't. If your firm is using the free tier on real matter work, that is the conversation to have on Monday morning, not whether AI is risky in general. AI is fine. The free tier is the problem.
The infrastructure layer. The vendor's systems should be SOC 2 Type II audited, have zero-data-retention options for sensitive matters, and route through a region that satisfies your data-residency obligations. Most US-based vendors clear this bar. Many overseas-headquartered ones don't, and the contract paperwork takes longer than people budget.
The deployment layer. This is the one Mark gestured at without naming. Your firm's own configuration of the tool — who can install which connectors, which Slack channels are wired in, who can read whose chat history — is what determines whether privilege survives contact with your own staff. The most common privilege break I see in the wild is not a model leaking data; it's a partner pasting a sensitive memo into a workspace where a non-lawyer admin can read it. The vendor cannot fix this for you. You configure it or you don't.
The matter layer. The deepest layer, and the one I believe legal-specific platforms exist for. Privilege isn't a property of you; it's a property of this matter, between this client and this attorney, for this purpose. The moment you can't tell which workspace a piece of work belongs to, you can't tell whether privilege is intact. General-purpose AI has no concept of a matter. It has projects, folders, conversations — useful, but not the same thing. (At HAQQ we treat matter-as-the-atomic-unit because the firms we work with don't have the engineering muscle to bolt that on themselves; they need it shipped.)
Mark's answer was correct at layers 1, 2, and 3. The fourth is where the legal industry will spend the next two years figuring out its conventions. If you're in-house at a tech-comfortable company with a strong IT function, you can probably get away with stitching layer 4 together yourself in Cowork projects and plugin scopes. If you're a regional firm with twelve lawyers and one IT person who also runs the print server, you are not going to wire that yourself, and the vendor that hands it to you turnkey is the one you'll buy.
The MCP question, and why it deserved more time
Julie Saliba's 150-vote question was specifically about MCP. "What security considerations should be taken into account when linking to inbox or using via MCP?"
Maggie answered the broader security question and gestured at MCP's permission model — connectors inherit your source permissions, so Claude cannot access files you yourself can't access, and there's a per-action permission grid: always allow, needs approval, blocked, or custom. She demoed the Gmail connector and showed how you can take a "send email" action from "always allow" down to "needs approval." All of that is true and useful.
What she did not say, and what Julie was probably driving at, is that MCP connectors are persistent ambient access. They are not one-shot pulls. Once you wire your inbox to Claude, Claude has standing capability to read that inbox in any future conversation that has the connector enabled, until the moment you revoke it. This is a different security posture than uploading a file to a chat. It's closer in shape to an OAuth grant, which means it should be governed like one: log every retrieval, audit periodically, revoke aggressively, and never wire personal accounts to firm-licensed tools.
The webinar showed Maggie's personal Gmail wired to her personal Cowork. That's fine for a demo. It would be a fireable offense at most firms with a real information governance program. The reason isn't that Anthropic is unsafe; it's that the audit trail of "what did this AI read about my client today" lives in two systems instead of one, and matter teams need it in one. This is solvable, but it has to be solved deliberately. The default of "wire the inbox up because the demo did it that way" is exactly how firms end up with a privilege incident in 18 months.
Mark earned a small note of credit for one thing he said as Maggie demoed the always-allow / needs-approval grid. He said many of the lawyers he meets are "very concerned about AI taking action without their approval" and that the permission grid was "a really good solution to something that the people have raised questions about." He's right. The permission grid is the concrete control that makes "human in the loop" real instead of aspirational. If you do nothing else after reading this article, set every "send", "delete", and "modify" action on your connectors to needs approval. Read-only actions can stay on always-allow. This is a five-minute hardening that buys you most of the operational safety with almost no friction loss.
What the room asked but never got to
Three security questions got upvoted but not answered live.
Syed Ali Khan, 29 votes: "Is information provided to Claude 'sandboxed' — i.e. not used to train or improve the product?" The short answer is yes on commercial plans, no by default on consumer Claude.ai unless you opt out. This belongs in writing in your firm's AI policy, not in your IT lead's memory. While we're at it, Cowork specifically runs in an isolated virtual machine on your desktop — Maggie mentioned this in passing when answering the security cluster — which limits the blast radius of anything that happens during a Cowork session. Files Claude touches in Cowork stay sandboxed to the directories you point it at.
Tom Harriman, 9 votes: "What enterprise-level controls are in place for skills? Can they be provisioned and assigned to specific user groups (e.g. Real Estate users with focused skills specific to their practice)?" Anthropic shipped role-based access control for Claude Enterprise recently — Maggie mentioned it in passing. Practice-group-scoped skill libraries are technically possible today via the org plugin marketplace and RBAC. They are not turnkey. Your IT team will build the scaffolding once and then it works.
Rodney Younce, 200 votes: "How do we explain to clients that their data is safely used?" This is the question I think Anthropic should have answered most carefully and answered the least. Lawyers cannot tell their clients "Anthropic said it's safe." They have to be able to make their own representations. The right answer here is a vendor security questionnaire, an attestation letter for sensitive matters, and a one-page client-friendly explainer the firm's marketing department can hand to a wary GC. Anthropic publishes the underlying material at trust.anthropic.com — Mark mentioned it — but the translation into client-facing language is firm work. Most firms haven't done it. They should.
§3 — The legal plugin is barely a product yet, and Mark said so himself
Thirteen questions clustered around skills and plugins. Rebecca Wright's 50-vote question — "can we get a glossary?" — was the most upvoted moment of plain-English honesty in the session. The webinar dropped skills, plugins, Cowork, Claude Code, MCP connectors, artifacts, and projects into the same paragraph more than once, and the chat noticed.
Here is the glossary the webinar should have started with.
A skill is a markdown file. That's it. It tells Claude how to do one specific thing — review an SOW against a playbook, draft a privilege log, triage incoming NDAs — by writing out the procedure the way you'd write it for a new associate. Mark showed one on screen. It was about 200 lines of plain text. Anyone can write one. Many people do.
A plugin is a bundle of skills shipped together. Anthropic's "legal plugin" is a collection of legal skills — meeting briefs, NDA triage, contract review, privilege log drafting, and a handful of others. You install it from Cowork → Customize → Plugins → under "Anthropic and Partners" → click install. Two minutes.
A connector (sometimes called an MCP server) is the live data pipe. iManage, NetDocuments, Outlook, Gmail, Drive, Slack, your CLM. Connectors are how Claude reads what your firm actually works in.
Cowork is Anthropic's collaborative desktop application. Demoed extensively in the webinar. It is now generally available — Andra Robinson asked if it was still in beta and the answer is no, GA. You can think of it as Claude with a laptop instead of just a chat window. It opens folders, writes files, runs things in parallel.
Claude Code is the developer-facing CLI. Same engine as Cowork but in a terminal. Maggie's analogy was excellent: Claude Code is to Cowork what a terminal is to an IDE. If you're not an engineer, use Cowork.
Artifacts are live outputs Claude generates inside a conversation — a dashboard, a doc, a small app — that you can interact with right there.
Projects are shared workspaces inside Claude. They hold instructions, files, and connector configurations that everyone on the project inherits.
That's the whole vocabulary. The webinar should have spent two minutes on this slide. They didn't. Rebecca's question carries 50 upvotes for a reason.
"Don't use the legal plugin out of the box"
It's at its best when it has actually been remixed and incorporates your own company's voice and risk matrices and your playbooks and your fallback language. You wouldn't wear a suit you bought off the rack — you would get it tailored to ensure it fits you well.
Mark said this on stage and it was the most important sentence in the entire webinar. He said it about the thing he himself built. Translation: the legal plugin is a starting template, not a finished product. It exists to show you what the format looks like and to give you a hundred-yard head start on your own playbooks. If you install it and use it as-is, you are getting Anthropic's general-counsel theory of how a transactional skill should work, not your firm's. The whole leverage is in the customization.
This is good news and bad news. The good news is that customization is recursive — you can sit Claude down and ask it to write your skills for you, by handing it a few examples of your firm's past redlines and saying "extract the playbook." Mark called this out and it works in practice. We use the same trick for the skills HAQQ ships to firms onboarding onto our platform: hand the model fifteen of your old NDA reviews and ask it to produce the playbook. You'll need to clean it up. But it's a 90% solution in 30 minutes. There is also a built-in "skill creator" skill that walks you through the process if you don't want to think about the meta-prompting yourself; Maggie showed it during the demo.
The bad news is that this work is real work, and most of the firms watching the webinar do not have the spare capacity to do it. This is where the two-tier reality of the legal industry becomes visible. Anthropic-the-employer has a dedicated legal product lead (Mark) building skills full-time. Most firms have a partner in charge of "tech" who already has 1,800 billable hours and a kid in middle school. The customization is leverage, and leverage is unevenly distributed.
Ben Kühnel asked about the future of the legal plugin, observing accurately that it "right now only consists of some Claude skills." Mark said it's only the start, more office surfaces coming, the pace of innovation is fast. I believe him. I also think the legal plugin will continue to be a starter kit rather than a turnkey solution for the same reason that Microsoft Word is not a contract management system. General platforms ship general primitives. Specialization happens in the layer above.
Tyler Niederwerder's question is more important than its 33 votes suggest
"Can Claude automatically decide which skills to use?" Yes. And the answer is one of the small details from the webinar that I think is going to matter more than the audience realized.
I didn't actually use a slash command or anything special to make sure that the skill is being used. I just used its name. I could also use a description like 'I'm prepping for the meeting, help me create a brief for it,' and Claude will know that that is what I'm talking about.
This is the difference between AI that requires its users to memorize a control panel and AI that picks up natural language and dispatches itself. For the legal partner who refuses to memorize commands, this is the difference between adoption and shelfware. Maggie didn't dwell on it. I would have. Building the skill once and then having Claude auto-invoke it whenever the user phrases a relevant request — that is the UX design that turns "we have AI tools" into "we use AI tools."
There's a subtler implication too. If you write a skill called triage-nda and Claude can auto-invoke it on a sentence like "look at the NDAs in the inbox folder, tell me which ones we should redline," then your skill library is functionally a natural language API for your firm's institutional knowledge. The lawyer who wrote the skill once is leveraging themselves across every colleague who will ever use a sentence containing the right intent. This is the mechanism by which one careful associate's playbook becomes the firm's house style.
Robert Graham's question is the one that matters most
Eleven votes only. "How do you suggest feeding Claude skills that incorporate our voice, tone, and position, in combination with the legal plugin?"
This is the actual customization question and Mark answered it indirectly when he told the story about analyzing 742 JIRA tickets. His method was: dump the corpus into Claude, ask it to find patterns, ask it to suggest where automation would create the most lift, then have it draft the skills. He used this to discover his team was spending too much time on NDA triage and open-source software questions. He then built skills targeting exactly those workflows.
Apply it to your own firm. Take your last 200 client intakes, or 200 redlines, or 200 client emails. Hand them to Claude in a Cowork project. Ask: what patterns do you see in how I do this work that I could codify as a skill? The answer will surprise you. Some of what you think is bespoke judgment is actually pattern-matched against your last six matters and could be pre-filled. Some of what you think is mechanical is actually where your value lives and should never be automated. You will not know which is which until you read what the model finds.
The mindset shift Mark described — and Montserrat Mazo asked about with four votes — is from being a doer to being a manager of agents. You stop drafting and start reviewing. You stop researching and start verifying. You stop typing and start checking. This is uncomfortable for lawyers because lawyering and typing have been roughly synonymous for thirty years. The lawyers who get past that discomfort fastest are the ones who win the next decade.
Skills as institutional knowledge: the Pamela story and why it scales
Maggie demoed something called /schedule quickly, and then Mark told the story that justifies the entire feature. His teammate Pamela on the regulatory team was spending two hours every day synthesizing global regulatory news. She asked Claude to do it on a schedule. Now it runs at 8 a.m., produces a daily newspaper, and publishes it to a Google Site that the whole legal team reads with their morning coffee. Two hours a day became zero, the deliverable improved, and the whole team gets the same brief.
This is the right shape for AI in a legal department. Not "lawyer chats with bot." A scheduled automation that produces an artifact the team consumes. It's the same shape as a research analyst's weekly market note, except the analyst is a model and the note is generated overnight.
Alexis Hartwell-Gobeske asked the related question with 13 votes: "Can Claude be set up to provide automatic updates about filing deadlines, hearing dates, etc.?" Yes. The mechanism is exactly Pamela's: connect Claude to your case management system via MCP, write a skill that knows what counts as a deadline, schedule it to run twice daily, have it post to Slack or email or a Sharepoint page. The hard part isn't the AI; it's connecting the case management system. If your DMS supports MCP today, you can build this in an afternoon. If it doesn't, you're waiting on the vendor — and most case management vendors are 12 to 18 months behind on this. The platforms that cover their ground will own the small-firm market.
Sharing skills inside a firm is a one-button affair, by the way. Maggie demoed it. Once you've written or remixed a skill in your personal library, you can share it with a teammate, a listserv, or push it to your organization's plugin marketplace if your admin is curating one. This last part — the org marketplace — is the mechanism by which a firm's skill library becomes a real asset rather than a collection of partner-owned shadow tools. If you're at a firm with more than fifty lawyers and you don't have someone curating an internal plugin library, you're leaving compounding leverage on the table.
§4 — Hallucinations got fewer votes than I expected, and that tells a story
Four questions on accuracy and hallucinations got 161 votes. It was the fourth-ranked theme, not the first. A year ago this would have been the dominant concern. The fact that privilege beat hallucinations by 6.5x is the loudest signal in the dataset.
The profession has moved past will it lie and onto how do we verify systematically. Nikolaj Nielsen put it plainly with 70 votes: "often requiring full verification. How does Anthropic differentiate its models on mitigating hallucinations and ensuring reliability?" Aviv Geron with 60 votes: "What's your recommended methodology for verifying Claude's legal outputs before they go to senior reviewers or regulators?"
Mark gave the right answer. He referenced the over-2,000 court filings now documented as containing hallucinated citations — yes, two thousand — and said the way you stay off that list is to ground the AI in real case law via tools and connectors, ask it to cite its sources, and keep a human in the loop. Maggie added that million-token context windows help and that asking Claude to cite sources gives you "that confidence that it's not hallucinated information."
This is correct but incomplete. Let me say the part the webinar didn't.
Citation verification is necessary but insufficient. Claude can cite a source that exists but doesn't say what Claude says it says. The model will produce a real Westlaw citation and then summarize it incorrectly, and a busy associate will paste the citation into a brief without checking the underlying case. This is the primary mechanism by which careful firms still end up with hallucinated filings. The mitigation is not "ask for sources." It's "ask for sources and verify the quoted language exists in the cited document." That second step is the one your verification skill should automate.
The verification methodology I'd recommend, and the one we built into HAQQ because we got tired of explaining it case by case: every claim Claude makes in a legal output is annotated with the specific paragraph or page it came from. Every quoted phrase is round-tripped against the source document and flagged if it doesn't appear verbatim. The human reviewer's job is not to verify everything; it's to verify the flags. This collapses the verification cost from "read the entire output and then read the entire source" to "read the output and check the items the system itself doesn't trust." That's the difference between AI that saves time and AI that creates a new pile of work.
Valter Pasanen asked the granular version of this with 21 votes: "Can you verify sources and paragraphs used in texts in detail when using Claude?" The answer in raw Claude is partly. The answer in a legal-specific system that's been built to do it is yes, with a specific paragraph reference per claim, and a flag if the paragraph doesn't say what the system claims. This is a category of feature that does not yet ship standard with general-purpose AI and is one of the few honest reasons to use a legal-specific tool over a general one.
The Heppner ruling Mark mentioned earlier circles back here. The non-attorney user had no verification workflow because the consumer plan didn't surface citations as first-class artifacts. The general lesson: citation infrastructure is not a feature lawyers should be expected to bolt on themselves. It should be in the box.
Priyanka Mehta with 10 votes: "Do you rely completely on Claude's output, or do you need to recheck documents to ensure it hasn't missed points or red flags?" Mark's answer was the correct lawyer's answer: not 100%, must review. The honest follow-up is that the delta between the AI output and what a senior reviewer would have caught has been shrinking by something like 30% per generation of model. We are not at the point where you skip the review. We are at the point where the review takes 20 minutes instead of two hours. The economics of the practice change at that ratio even if the workflow looks the same on paper.
§5 — The 70-page document problem (and why agentic harnesses solve it)
Anonymous, 101 votes, the fifth-most-upvoted question of the entire session: "Legal work can involve 70+ page documents. With detailed context and tool calls, there's increased risk of context rot and degraded output. How does Claude's legal team address this?"
Mark answered this on stage and his answer is one of the most important architectural points in the whole webinar, so I want to expand it carefully because it explains why Cowork exists as a separate product surface and not just a longer chat window.
The problem the question describes is real. Large language models have something called the "lost in the middle" problem: as you stuff more text into a single conversation, accuracy on details from the middle of that text degrades. This happens even with a million-token context window. The model can technically see everything; it doesn't reliably attend to everything. For legal work, where the difference between paragraph 27 of an exhibit and paragraph 28 of the same exhibit can be the entire question, this is not a theoretical concern.
This is why I love Cowork so much. The agentic harness allows things to swarm and make plans and execute and distill a lot of the mass corpus of knowledge that legal teams often have or encounter in their work and make sense of it all. In chat-based or turn-based conversations with AI, yeah, you get that degradation. But when Claude is able to make use of a local computer, store files in the right places, and use these types of file systems, we've really found that it's able to keep up and it doesn't have that context rot.
Translation. In a chat window, you hand the entire 70-page document to the model in one shot, and it either fits in context or it doesn't, and either way the model has one chance to read it. That's the regime where context rot kicks in.
In Cowork, the model has access to a real file system on your laptop. So it does what a human associate would do: it opens the document, splits the analysis into stages, writes intermediate notes to disk, reads them back when needed, and uses parallel sub-processes for independent sub-tasks. The 70-page document doesn't have to live in the prompt; it lives on disk, and the model fetches the parts it needs when it needs them. This is what the word "agentic" actually means. Not "AI that does things" — that's the marketing version. The technical version is "AI that uses tools, including a file system, to extend its working memory beyond what fits in a single prompt."
Maggie added the second half of the answer in her demo: ask Claude to cite its sources. When the model is operating across a long document and producing output, you want it to point at exactly which page or paragraph each claim came from. This serves two purposes. It gives you a verification handle (you can check the cited section directly). And it forces the model into a more grounded reasoning mode, because writing down "I'm asserting X because page 14 says Y" is harder to fake than "X is true, trust me."
Practical implication for a legal team. If your work routinely involves documents over fifty pages — think large M&A deals, complex regulatory filings, multi-volume discovery, dense expert reports — you should not be doing that work in chat. You should be doing it in Cowork, where the agentic harness can actually decompose the problem. Doing 200-page document analysis in plain Claude.ai chat is the workflow equivalent of trying to read a textbook by holding the whole book up to your eyes at once. Cowork lets the model open a chapter at a time.
This is also where the Pillar 3 capability (document comprehension) and the Pillar 4 capability (context across apps) compose well. Cowork can run a multi-stage analysis on a long document, write intermediate findings to a file, then continue the work in the Word add-in where the actual redlining happens. The 70 pages don't have to fit through any single tool's eye of a needle. They flow.
One small honest note. The agentic harness is not magic; it is a structured way of letting the model work around its own limits, and the limits are still real. A skill that calls itself fifteen times to analyze fifteen sections of a document can drift in style or reach inconsistent conclusions across sections. Good skills handle this by defining a "synthesis" final stage that reads all the per-section outputs and reconciles them. If you're writing your own skills for long-document work, plan for that synthesis stage. It's the difference between fifteen partial answers and one coherent output.
§6 — The document zoo is real, and the webinar mostly skipped it
Six questions on document handling got 175 votes. Most of these did not get answered live, and they're the questions I'd most like to see the next webinar tackle, because document handling is where legal-AI sales decks meet legal practice and the truck-sized gaps appear.
Shivangi Agarwal with 44 votes, the question I think most viewers wanted answered: "File types used so far are docx, md, csv. Does Claude have the same accuracy with PDFs of old sale deeds and illegible documents? What about JPEGs? These are common in IP and property litigation."
The honest answer in three parts.
Modern PDFs with embedded text — your standard deal documents, recent filings, anything generated digitally in the last 15 years — Claude handles excellently. Accuracy is comparable to docx. No surprises.
Scanned PDFs — including those old sale deeds Shivangi mentioned, and the "PDF" your local clerk's office mailed you that's actually a 1987 photocopy run through a fax — accuracy depends entirely on the OCR layer in front of the model. Claude's vision capability can read text in images, but on degraded scans the OCR errors compound. You'll see misread dates, swapped letter pairs, and dropped paragraphs. For matters where this is the bulk of your evidence, no general-purpose AI is currently good enough on its own. You need a dedicated OCR pipeline upstream — Tesseract for budget, Adobe or AWS Textract for production — feeding cleaned text to Claude. The legal-specific tools that handle this well, including ours, ship the OCR pipeline as part of the package because asking each firm to build it is unrealistic.
JPEGs of legal documents — handwritten notes, photographs of marked-up redlines, forms scanned at low resolution — are the hardest case. Vision models including Claude can extract content, but in IP and property work where every comma matters, you will have errors, and you must verify. The realistic workflow today is: have the AI produce a transcription, treat it as a draft, have a paralegal verify against the original. This is still faster than typing it from scratch. It is not zero-touch. Anyone who tells you it is, is selling you something.
Aishwarya Belle's 57-vote question is the one I love most because it's the daily life of a transactional lawyer: "As a transactional lawyer, I struggle with tracking which version of the document reflects changes made by multiple parties. Can Claude give a comparison for that?"
Maggie demoed redlining beautifully — track changes generated directly in Word from the triage report — but the multi-party version comparison Aishwarya asked about wasn't shown. The capability exists. You can hand Claude four versions of an MSA and ask "what changed between v2 and v3, and between v3 and v4, and which clauses were touched by which counterparty." Claude will produce a clause-by-clause changelog with the originating version. It is genuinely useful. The reason it wasn't demoed is probably that it requires you to feed the model all four versions and ask the question precisely, and demos prefer one-shot magic.
If your daily life is M&A or large transactional work and you take only one operational practice from this article, take this: build a skill called "version diff" that takes a folder of versioned drafts and produces a clause-level changelog with parties, dates, and rationale where it can infer it. This skill replaces a meaningful chunk of the work a junior associate currently does in tracked-changes view, and it does not require a redesign of how your team works. Mark would call this "amp-fooding" — using the tool on the work that's most repetitive and most painful first. It's the right place to start.
Vernicka Shaw and Melissa Lee both asked the simpler form: how do you do redlining. The Word add-in demo was the answer, and it is the best one currently available outside specialized contract platforms. Open Word, open the Claude side panel, upload a triage report or a playbook, ask for redlines, accept or reject each track change individually. Five minutes from question to working redline. The 13 and 2 votes on these questions reflect that everyone knows redlining matters; nobody was sure Claude could do it well; the demo proved it can.
Orietta Blanco's six-vote question — "Can Claude compare large volumes of documents that come in different formats?" — is genuinely hard. Mixed-format batches (some docx, some PDF, some scanned, some HTML) require a normalization step that most general-purpose tools don't do automatically. The realistic answer today: build (or buy) a pipeline that converts everything to a common format first, then run the comparison. Not glamorous. Required.
§7 — Where lawyers actually work is where AI has to live
Three questions about integrations got 269 votes — which sounds modest until you realize Michael Graham's single question got 84 of them and was probably the most important practical question of the entire session.
"Many firms don't use Gmail or even Outlook — work is stored in a document management or case management system. How can Claude read these files? Does it need a specific integration?"
Mark answered this in his four-pillars slide: MCP connectors for iManage, NetDocuments, CLMs, Drive, Outlook, the Microsoft suite. The architecture is right. The reality is more textured.
The theoretical answer is that any system with an API can be connected via MCP, and that the MCP ecosystem now has hundreds of public connectors and a steady stream of new ones being released. You can wire Claude to anything.
The practical answer for the median firm is that today you have first-class connectors for Microsoft 365, Google Workspace, Slack, Teams, Notion, and a growing list of name-brand SaaS. The legal-specific systems — iManage, NetDocuments, ProLaw, Clio, MyCase, PracticePanther — vary enormously in their MCP readiness. iManage and NetDocuments have been working on this. The smaller case management vendors are mostly at "we have an API, somebody could write a connector" rather than "we ship a connector you install in two clicks."
This is the integration gap. It is the single biggest reason why a small firm using Clio cannot just install Claude and start working today the way Mark's team does. The plumbing isn't there yet. There are two ways to handle this gap: wait for your case management vendor to ship a connector (slow), or use a legal-specific platform that has done the connector work for you (faster, but a tradeoff in vendor count). Both are valid. Neither is great. The market will resolve this in 18-24 months.
Christian Fleischmann asked, with no recorded vote count: "Is the Word plugin leveraging the playbooks created in Cowork?" Yes — and this is one of the genuinely impressive things about the architecture. The same skill installed in Cowork is available in the Word add-in. The playbook you wrote against an iManage matter folder works when you're staring at a docx in Word. This is the "carries context across apps" pillar Mark emphasized, and it's real. It works. It also implies that whatever institutional knowledge you bake into your skills compounds across surfaces, which means that skill creation is the leverage point. Spend an afternoon writing one good skill and you've upgraded your team's experience in three different tools at once.
Gianni Carfi Pavia, 35 votes: "How do you see the Claude Microsoft Word add-in combined with tailored skills changing how legal professionals work with contracts?"
The change is mechanical and measurable. A standard MSA review at a competent transactional shop today takes two to four hours, depending on the playbook. With a tailored skill in the Word add-in, it takes 20 to 30 minutes — Mark said his team is doing redlines in 20 minutes — if the skill has been written well. The 90% reduction in time is not equally distributed across associate work. It collapses the mechanical scan. It does not collapse the judgment calls. The resulting workflow looks like: associate runs the skill, reads the flagged sections, makes judgment calls on the edge cases, produces final markup. The associate spent 30 minutes instead of three hours, and the part of the work that involved actual lawyering grew from 20% of the time to 80% of the time. This is what people mean when they say AI makes the work more interesting — not because the model became creative, but because the routine was extracted.
I will note one practical thing the demo didn't dwell on. The Word add-in requires a paid Microsoft 365 license and the skill's permissions to be set up correctly on first run. If you're at a firm that's still on Office 2019 because IT hasn't approved the migration, this won't work. A surprising number of firms are. Add it to your IT roadmap.
Mark also mentioned in passing what he called the "office agent trilogy" — Word, Excel, PowerPoint — and email as the fourth. The point: most knowledge work for lawyers happens across these four surfaces, and Claude now has first-class presence in all of them. A meeting brief can start as a Word document, become a PowerPoint deck for the client pitch, pull data from an Excel spreadsheet, and end as an email. Each handoff used to require restating the context. Now it doesn't. This is the workflow shape that turns "AI tool" into "AI teammate."
Essayer HAQQ AI gratuitement
Découvrez la rédaction et la recherche juridique par IA
§8 — Cowork, Code, Chat, Word — which surface, when
Seven questions covered the product surface and model question. The collective vote count was 213, distributed across what is essentially one single confusion: which Claude do I use.
Maggie's terminal-vs-IDE analogy was the best framing of the day. Claude Code is the terminal — for engineers. Cowork is the IDE — for everyone else. They use the same engine. They share the same skills. They differ in surface, not in capability.
Tian Luo with 68 votes asked it twice — once for Cowork vs Claude Code, once for Haiku vs Sonnet vs Opus. The first got answered. The second didn't get directly addressed, so let me. Haiku is fastest and cheapest, suitable for high-volume routine work where you'd rather pay $0.001 per call than $0.05 — bulk classification, simple summarization, intake routing. Sonnet is the daily driver for legal work; the price-performance is best for contract review, drafting, redlining, the bulk of what a transactional or in-house team does. Opus is for the hard reasoning — complex multi-document synthesis, novel legal questions, situations where the wrong answer is expensive. The right rule for a firm: default to Sonnet, escalate to Opus when stakes are high, use Haiku for triage steps in your skills. The token cost difference matters in volume; on a single task the few cents are noise.
Ryan Malek, 11 votes: "If you already have Claude Code configured with MCPs, Skills, Plugins, CLAUDE.md etc., is it better to use it for legal work or start over with Cowork?" Don't start over. The skills, MCPs, and CLAUDE.md you wrote for Code work in Cowork because they're plain text files. Move the directory. Open Cowork. Done. The migration is closer to "change your editor" than "change your stack." If you're a paralegal or lawyer who only ever opens Code because an engineer set it up for you and you're tired of the terminal, you can switch to Cowork tomorrow without losing anything.
David Andrews, 20 votes: "We're a small firm on a Team-level plan. Are the same features available to us as Enterprise, at our smaller scale?" Mostly yes; some no. The model itself, skills, plugins, MCPs, Cowork, the Word add-in — all available on Team. The Enterprise-specific features are role-based access control, the compliance API for data loss prevention and eDiscovery, advanced admin controls, and the ability to enforce org-wide connector policies. For a small firm with one office and a clear chain of command, you do not need RBAC; informal trust covers it. For a firm with multiple offices and practice groups that need information barriers, Enterprise is the right tier and worth the upgrade. Don't pay for Enterprise just to pay for Enterprise. Pay for it when the controls solve a problem you actually have.
Romina Villarroel asked the small-firm question that nobody answered: "Are there other plugins you recommend for a small law firm? (We don't have a marketing or accounting team, for example.)" The honest answer is that the plugin ecosystem is early, the legal plugin is the only legal-vertical option from Anthropic today, and the small-firm-specific tooling is mostly going to come from third parties — including legal-AI platforms that ship pre-built skill libraries, billing integrations, and client communication automations as part of the package. If you are a five-person firm, you do not have time to assemble the pieces yourself. The right move is to pick one platform that handles the boring 80% out of the box and then customize the last 20% with your own skills. This is exactly the segment our team works with most, so I have a bias here, and I'm naming it.
§9 — Practice areas: the same architecture, different daily lives
The webinar's demos were all transactional — meeting briefs, NDA triage, contract redlines. That's no accident. Transactional work is the easiest place to demo legal AI because the artifacts are clean, the playbooks are well-defined, and the wins are visible. But Mark spent a few minutes on what his own team's litigation, IP, and regulatory groups are doing, and those examples are worth surfacing because they map onto a much wider audience than the demos suggested.
Transactional
This is the demo's center of gravity. NDA triage, contract redlining, MSA review against a firm playbook, deal point analysis, clause library checks. Two-to-four hour reviews collapse to twenty-to-thirty minutes when the skill is written well. The Word add-in is where most of the actual redlining lives, with Cowork serving as the orchestrator for upstream work (intake, triage, classification) and downstream work (email drafting, follow-up).
Mark's specific examples from his own team: contract reviews, NDA triage, privacy impact assessments. The privacy impact assessment example is interesting and underdiscussed. PIAs are structurally a transactional task — defined input (a product spec or feature description), defined output (a written assessment against a regulatory framework), repeating template. They're also work that takes most legal teams hours to do well. Mark said his team has compressed PIAs to 20-30 minutes by codifying the assessment into a skill. If you're at a tech-adjacent in-house team, this is probably your highest-leverage place to start.
Litigation
Mark mentioned his litigation team using Claude for two things specifically: transcript search and expert prep.
Transcript search in litigation has historically been one of the most expensive billable activities in the practice. A typical large case might generate thousands of pages of deposition transcripts. The associate's job is to read every page, mark the relevant Q-and-A exchanges, and assemble a binder of citations. This is exactly the kind of needle-in-haystack work that AI does well — search the corpus, find every place a witness contradicted themselves, every place an admission was made, every place a defined term was used inconsistently. With a good skill, this work goes from days to hours.
Expert prep is the other example. Litigation teams routinely have to prepare experts for testimony — feed them the relevant case background, the key documents, the expected lines of questioning, the opposing side's likely arguments. Mark's team is using Claude to do the synthesis: read the case file, read the expert's prior depositions on similar topics, read the opposing expert's reports, produce a prep memo that orients the expert to what they need to know. Same shape as a meeting brief, just for a much higher-stakes meeting.
There's a third litigation use case Mark didn't mention but I'll add because it follows directly from the agentic-harness discussion in §5: large-scale discovery review. When you have ten thousand documents to review for privilege and responsiveness, the standard tooling today is keyword-based eDiscovery platforms (Relativity, Everlaw, etc.) that produce noisy results and require armies of contract attorneys for first-pass review. A well-written skill in Cowork can do meaningful first-pass tagging — privilege, responsiveness, document type, key witness, date range — at a fraction of the cost. Not as a replacement for the eDiscovery platform yet, but as a layer on top that prioritizes the human reviewer's queue. Several firms we work with run this pattern in production. It is one of the highest-leverage applications of legal AI in litigation today, and almost nobody is talking about it because it's unsexy compared to demos.
And then there's Andrew the paralegal at the trial. Real-time AI assistance during examination — pulling cross-examination angles in seconds, surfacing prior testimony that contradicts a current answer, generating follow-up questions on the fly. Two years ago this would have been science fiction. Today a paralegal built it on a weekend and helped his team beat an MLaw 200 firm. Trial teams that haven't started experimenting with this are giving up real ground.
Intellectual property
Mark's IP team example was patent prioritization: scanning product briefs and GitHub repositories to surface patentable ideas. That's a perfect AI workflow. The input is technical and unstructured; the output is a structured shortlist of ideas with novelty and patentability flags; the human IP attorney makes the final call. Time saved per idea: hours of engineer-hours plus IP-attorney-hours, compressed to a scheduled overnight job.
For IP work specifically, the Pillar 1 capability (live data via MCP) is doing a lot of the work. The model is reading the actual GitHub commit history, the product spec docs in Drive, the Slack discussions about feature design. It is not summarizing a stale snapshot; it is watching the engineering work happen and surfacing the moments when something patentable was created. This is the kind of workflow that gets impossible without live data access. With it, it's an obvious automation.
Patent prosecution has its own AI-friendly shape too. Drafting claim language, searching prior art, comparing claim sets across versions — all structurally similar to the transactional and litigation patterns above. The IP-specific platforms compete heavily on this; raw Claude with good skills gets you a respectable percentage of the way without a vendor.
Regulatory
Pamela's regulatory tracker, mentioned earlier, is the canonical example. Two hours a day of manual synthesis became a scheduled job. The deliverable improved (more sources covered, more consistent format). And the whole legal team gets to read it instead of just the one regulatory analyst.
The general shape of regulatory work — periodic monitoring of changing rules, mapping rule changes to firm practice, drafting client alerts — is one of the best fits for the schedule-and-publish pattern. If you have a regulatory practice and you don't yet have at least one scheduled Claude-driven artifact, you're missing the easiest productivity win in the entire stack.
In-house counsel
Mark himself is essentially in-house — he's a lawyer at a tech company. His most relatable example, and the one he closed the webinar with, was the Friday newsletter. Every Friday, his team sends a "what we did this week" update to cross-functional stakeholders.
I dread that Friday morning reminder. It's like an hour of busy work of compiling. I manage a team of other product lawyers. I have to compile all of their wins for the week and synthesize it. And I don't like doing work about the work.
His solution: feed Claude past newsletters as the high-bar template, point it at the team's Slack and ticket activity for the week, ask it to produce the draft. "For those of you who remember the movie 'Office Space,' the TPS reports of the world — Claude is very good at helping understand the progress, grounding itself in existing wins that your department has had over the past year." He emphasized: "Don't be sycophantic and just tell me we did your work. Show me what's actually impactful based on what other people are saying."
That's the in-house counsel pattern in miniature. Status synthesis. Cross-functional translation. Finding the signal in a week of Slack noise. It's also the use case that I think is most transferable across practice areas, because every legal team has a "Friday newsletter" of some kind — a status report, a partner update, a client check-in, a board memo. The pattern is the same. Steal it.
§10 — Setup time: from zero to first useful skill in one afternoon
Anonymous, 26 votes: "What's the time commitment and lift to get all of these (add-ins, plugins, Cowork, etc.) set up to operate at the level legal teams require?"
This question got upvoted because everyone has been burned by enterprise software adoption timelines. "Six months and $100K of consulting" is the legal industry's reasonable prior for any new tool, and lawyers were rightly suspicious. The honest answer is that this technology is much closer to "an afternoon" than "six months" if you scope correctly. Here's the realistic breakdown.
Hour 1 — Account + install. Sign up for Claude on a commercial tier (Team or Enterprise — not the free consumer tier). Install Cowork on your laptop. Open Cowork → Customize → Plugins → Anthropic and Partners → install the legal plugin. Total clicks: about twelve. Total time: maybe ten minutes plus the wait for IT to approve the installation.
Hour 2 — Wire one connector. Pick the system where the most of your daily work lives. For most lawyers it's Outlook or Gmail; for some it's iManage or Drive. Authenticate Claude through the connector. Go to the connector's permission grid and review what's set to "always allow" — for any "send", "delete", or "modify" action, set it to "needs approval." Read-only actions can stay on always-allow. Allow yourself five extra minutes to test the connector by asking Claude to summarize a thread or surface a recent doc.
Hour 3 — First skill remix. Open the legal plugin and pick the skill closest to a workflow you actually do. Open it as a markdown file. Read it. It will be roughly 100-300 lines of plain English. Edit it for your firm's voice — add fallback positions, add the clauses you actually negotiate hard on, add the format your team wants the output in. Save. You now have a customized skill specific to your practice.
Hour 4 — Run it on real work. Pick one matter or one document. Run the skill. Read the output. Identify what it got wrong or what it missed. Edit the skill. Run it again. Repeat until the output is what you'd hand a senior partner. This iterative loop is how you turn a starter skill into your skill.
That's the whole zero-to-first-skill arc. Four hours of intentional practice and you have at least one working production-quality automation in your daily life.
The next month is where the gradient gets steep. Once you have one skill working, the marginal cost of the second is a fraction of the first because you've learned the format. By month three, a motivated practitioner has a personal library of ten to twenty skills covering most of their recurring work. By month six, the practitioner's main job has shifted: they're not running individual skills anymore; they're chaining them, scheduling them, and reviewing outputs from automations that ran overnight.
The firm-level rollout is its own conversation. For a firm to get the team version of this productivity gain — not just one early-adopter partner — you need someone curating the org plugin marketplace, training new hires on the plugin library, and updating the skills as feedback comes in. That role doesn't exist at most firms today. It will. The first firms to formalize it are the ones who get the compounding advantage.
If your firm needs the abridged version of this rollout because you don't have spare cycles to build the curation function, the alternative is to use a legal-specific platform that ships the curation pre-built. (Yes, including ours.) The tradeoff is less customization for less work. Most firms below 100 lawyers should make that tradeoff.
§11 — The questions Anthropic ran out of time for
Six questions scored well, didn't get answered live, and deserve answers. Quickly.
Todd Taylor, 79 votes: "I'm interested in building agents in Claude (we have a Team account) for legal work. How would that be different than a skill?" An agent is a long-running, multi-step automation that uses one or more skills and connectors to complete a task end-to-end. A skill is the procedure ("how to triage an NDA"). An agent is the role ("the NDA intake clerk who runs every morning, triages anything new, drafts the redlines, and emails the team"). Maggie demoed exactly this in Cowork without using the word "agent." Same thing.
Sofia Rodriguez, 24 votes, the SOW playbook structuring question: the right structure is a skill with three sections — standard terms (the boilerplate you accept without flagging), playbook positions (your firm's standard fallback positions on common deviations), and escalation rules (when to flag for partner review). Hand Claude five examples of past SOW reviews, ask it to extract these three layers, edit the result. You'll have a working playbook in an afternoon.
Merve Yilmaz, 22 votes: "Any legal research tips? I'm currently replacing external counsel advice on product expansion. What guardrails should I build?" Three guardrails. One: never let the model draft a final memo without citation verification at the paragraph level. Two: require a written source for every legal proposition; if the model can't cite one, flag the assertion as model-only and escalate. Three: keep a running log of where the model was wrong, and feed it back into the skill as anti-patterns. Over six months of use, the skill becomes specific to the kinds of mistakes that matter for your work.
Brint Hiatt, 49 votes: "Would appreciate steps on how to get started from the very beginning. I've never used Claude, only ChatGPT." See §10. The step-by-step is in the four-hour walkthrough above.
Andrew Amoranto, 39 votes: "How do you roll out live artifacts (like dashboards) and other apps you build for yourself to the rest of the legal team?" Pamela's answer from earlier — host the artifact at a stable URL the team can bookmark, schedule the underlying generation to run on a cron, link it from your team Slack or wiki. The pattern is "the artifact is the deliverable; the chat is the workshop." Don't ask people to read your prompts. Hand them the output.
Mary Prager, no recorded vote count: "How do you shift from doing work individually in your own Claude instance to collaborating within the legal team and cross-functionally? Is there a way to do that seamlessly within Claude, or do we still need to move out (to Slack, email, etc.)?" Today the seam still exists — Claude can produce the email or Slack message but the conversation about the work happens in your usual collaboration tools. Anthropic's projects feature partly addresses this; multiple people can work in the same project with shared context. It's not yet a full replacement for Slack. It's not trying to be. The right mental model: Claude is the workshop where you do the work; Slack is where the team coordinates about the work. They're different tools for different layers and the seam is a feature, not a bug.
§12 — What the room was actually telling us
Step back from individual questions. Look at the rank-order of themes by upvote weight.
- Security & Privilege — 4 questions, 1,050 upvotes, 42% share
- Skills & Plugins — 13 questions, 511 upvotes, 21% share
- Integrations — 3 questions, 269 upvotes, 11% share
- Product Surfaces & Models — 7 questions, 213 upvotes, 9% share
- Adoption & Use Cases — 7 questions, 191 upvotes, 8% share
- Document Handling — 6 questions, 175 upvotes, 7% share
- Logistics — 5 questions, 165 upvotes, 7% share
- Accuracy & Verification — 4 questions, 161 upvotes, 7% share
Three signals worth holding.
First, the security cluster doesn't dominate because lawyers are paranoid. It dominates because lawyers are operationally serious. The question shape — privilege, sandboxing, MCP scope, sensitive case files — tells you these are people who already plan to use Claude and who need to build the policy around it. The Heppner ruling concentrated minds. The webinar concentrated them further. Anthropic should consider that the next webinar this audience wants is not "more demos." It's a one-hour deep dive on configuring Claude for privilege, with sample policies, sample client letters, and sample audit configurations. That session would draw 30,000 registrations.
Second, hallucinations falling to fourth place is not because the problem is solved. It's because the profession has internalized that the problem is solvable through workflow design — citation verification, human review, grounded retrieval — and is now asking the next-order questions about how to do that systematically. This is a maturity signal. A year ago the question was "is it safe to use." Now it's "how do I verify at scale." The vendors who answer the second question crisply are the ones who win the next 18 months.
Third, skills and plugins took thirteen questions because the vocabulary is genuinely confusing and the tooling is in early days. Mark's "don't use it out of the box" admission is the most honest framing of where the technology actually is. The legal plugin is a starter kit. The customization is the leverage. The customization is also work, and the firms that win the productivity dividend are the ones who do that work — or who pick a platform that's done the work for them.
A fourth signal worth a beat: nobody asked whether AI would replace lawyers. Not one of the 51 questions. That debate is over inside the profession. The questions are operational. How do I integrate. How do I verify. How do I roll out. How do I configure. How do I avoid the naughty list. The audience for these questions is the audience that has already decided. The market is now selecting between which AI, not whether AI.
A note from someone building in this space
I run HAQQ. We work with around 9,800 firms, mostly in the markets that Big Law webinars don't usually touch. I sat through this webinar twice — once live, once with a transcript open — because the questions are the most useful market research the legal-AI category has produced in 2026. I'm grateful Anthropic made the recording public.
The thing the webinar got most right is the cultural read. Twenty thousand registrations is a number that says the profession has crossed an inflection point. The questions in the chat are not skeptic-camp questions. They're operator-camp questions. How do I do this well. That's a different conversation than the one we were having two years ago.
The thing I think the next round of legal-AI conversation has to get better at is the gap between "what the platform can do in a demo" and "what the median firm can wire up in practice." Mark's team has the resources to write skills, configure connectors, run a pilot, and iterate. Most firms — including most of the firms upvoting on the chat — do not. The platforms that win the small and mid-size legal market over the next two years are the ones that ship the boring 80% turnkey, leave the customization to the firm, and don't make the firm's IT lead build OCR pipelines on the side.
Mark's closing line of the webinar was about that Friday newsletter — the hour of compiling-other-people's-wins he dreaded every week. He said Claude turned that hour into minutes by reading the team's Slack and ticket activity, learning the format from past newsletters, and producing a draft that he then edited. It's a small example. It's also exactly the right example. The point of legal AI in 2026 is not that it does the lawyering. The point is that it does the work about the lawyering — the compiling, the synthesizing, the formatting, the chasing — so the lawyer can spend the hour on actual legal judgment. That's the bargain. It's a good one.
If you're a lawyer reading this and you want to talk about how any of these patterns map to your practice, find me on LinkedIn. I post about this weekly. If you'd like to see how a legal-specific platform handles the privilege layering, citation verification, and DMS plumbing problems I described, HAQQ Legal AI is the easiest place to look — it's free to try, and we publish free legal-AI tools you can use in a browser without committing to anything.
Either way: stop using the consumer tier for real matter work. Get on a commercial plan with privilege controls. Pick one workflow that hurts (NDAs, intake, the Friday newsletter, the weekly regulatory roundup, take your pick) and write your first skill against it this week. Ship the skill to one teammate. Iterate.
The lawyers who run their firms in 2028 will be the ones who started building skills in 2026. The webinar audience knew this — it's why they showed up. The work begins now.
