Ambient scribes beyond healthcare: Building for veterinary and legal

Ambient AI scribes got their start in the exam room, and that's still where most of the writing about them lives. Doctor talks to patient, software listens, structured note comes out, physician stops typing at 9pm. It's a good story and it turned into a real category fast.

But the pattern underneath — passive capture of a professional conversation, turned into the structured record that conversation is legally or operationally required to produce — is not a healthcare pattern. It's a pattern that applies anywhere a licensed professional has to document what was said, and where the documentation is currently done by the professional, by hand, after hours.

Two of those places have almost no tooling built for them specifically: veterinary practice and legal practice. Both have the documentation burden. Both have practitioners who bill by the hour and lose those hours to writing. And both have acoustic and structural properties that are genuinely different from a clinical exam room, which is why lifting a medical scribe wholesale into either one produces something that mostly works and fails in interesting ways.

This post is about those differences. What transfers, what doesn't, and what you actually have to build.

What is an ambient AI scribe?

An ambient AI scribe is software that listens passively to a professional conversation and produces the structured documentation that conversation requires — without anyone dictating to it, pressing record on each section, or filling in a form.

The word doing the work is ambient. Dictation software transcribes what you say to it. An ambient scribe transcribes what you say to someone else, and then figures out which parts of a natural, meandering, interrupted human conversation belong in which fields of a formal record. The hard part was never the transcription. The hard part is that professional conversations don't happen in the order the record wants them in.

Architecturally, every ambient scribe is the same three things:

1. Capture and transcription. Multi-speaker audio from a real room, transcribed accurately enough that downstream extraction can trust it.
2. Speaker attribution. Knowing who said what, because the professional's words and the client's words play completely different roles in the record.
3. Structured extraction. Turning the conversation into the fields the record requires, with the judgment to know what belongs and what doesn't.

What changes between verticals is the accuracy bar on each of those three, and which one is load-bearing. That turns out to matter more than it sounds.

Veterinary: The three-way conversation with a silent patient

A vet consultation looks superficially like a medical one and behaves differently in almost every way that matters to your software.

The patient doesn't talk

This sounds like a simplification. It's the opposite. In a human consultation, the patient is the primary source — they describe the symptom, the onset, the severity. In a vet consultation, all of that information arrives secondhand, through an owner who is interpreting behavior they may have observed incorrectly, reporting it in non-clinical language, and often speculating.

"He's been off his food since Thursday, maybe Wednesday, and he did that thing where he stretches his front legs out and puts his head down."

Your extraction layer has to hold a distinction the medical equivalents don't: what the owner observed, what the owner concluded, and what the vet found. Flatten those into one field and you've produced a record that attributes the owner's guess to the clinician. In a discipline where the record follows the animal across practices and specialists, that's a real problem, not a cosmetic one.

Three parties, one of whom is a dog

The audio is genuinely hard. A vet consultation frequently has the vet, the owner, and a nurse or tech, plus an animal that is barking, whining, scrabbling on a steel table, or being actively restrained. There's equipment noise. People talk over each other constantly, because someone is holding a frightened animal and coordinating out loud while the conversation continues.

Two capabilities carry most of the weight here:

• Diarization that survives overlap and short turns. Much of a vet consultation is rapid three-way exchange with turns two or three words long. Diarization approaches that cluster after the fact tend to smear these. Universal-3.5 Pro produces the transcript and the speaker changes jointly rather than in separate passes, which is specifically what makes short turns and overlapped speech survive — and it's optimized for cpWER, which measures transcript accuracy with speaker attribution rather than treating them as separate scores.
• Animal vocalization that doesn't become text. A barking dog is non-speech audio, and non-speech audio is where a lot of models get creative. This is worth testing explicitly on your own recordings before you build anything on top.

Species and drug vocabulary

Veterinary terminology overlaps human medicine heavily and diverges in exactly the places that matter — same drug, different name; same name, wildly different dose; conditions that don't exist in humans at all. Breed names are a long tail of proper nouns that no general model has strong priors for.

This is what contextual prompting is for. Priming the model with the practice's drug formulary, common breed names, and the species being seen shifts recognition toward the right vocabulary for the appointment. Keyterm prompting handles the specific-term case. One caution: scope the term list to the appointment rather than loading every term the practice has ever used, and read when keyterm prompting backfires before you build a five-hundred-term list — an over-broad list can push the model toward a term you supplied and away from the one that was actually said.

The record follows the animal

One structural note. Veterinary records are more portable than most human medical records — they move between general practice, specialists, and emergency clinics routinely, often as documents rather than through an interchange standard. That makes the output format less constrained than a clinical note and the completeness of the narrative more important, because the next reader may have no other context.

Legal: two products wearing the same name

"Legal ambient scribe" describes two things with almost opposite requirements, and conflating them is the most common design error in this space.

Depositions: verbatim is the product

A deposition transcript is evidence. Every "um," every false start, every self-correction is potentially meaningful, because how a witness answered is as contestable as what they answered. The cleanup that makes a meeting summary readable is, here, evidence tampering.

So the requirements invert:

• Disfluencies are content, not noise. You want them preserved and timestamped, not smoothed away. Test this explicitly — many transcription defaults remove them, and "our model produces clean readable text" is a liability in this context rather than a feature.
• Speaker attribution is a correctness requirement, not a convenience. Attributing an answer to the wrong party isn't a formatting glitch; it changes the meaning of the record. Sustained attribution across a multi-hour proceeding with counsel, witness, opposing counsel, and a court reporter is the hard technical problem in this vertical.
• Timestamps must be reliable at the word level. Video depositions get synchronized to transcript for playback at trial. Drift that would be invisible in a meeting summary is disqualifying here.
• The output is not a summary. A deposition scribe's job is an accurate, attributed, timestamped record plus navigation — exhibit references, objections, topic indexing. Summarization is a separate, optional layer on top, and it never replaces the record.

Worth saying plainly: an ambient scribe does not replace a certified court reporter, and any product in this space needs to be clear about which parts of the workflow it's augmenting. The realistic near-term product is preparation, review, and searchability around the official record, not the official record itself.

Client meetings: structured extraction is the product

A client intake or matter meeting is almost the opposite. Here you want what the medical scribes do — pull the facts, the dates, the parties, the deadlines, the instructions, and the action items out of a discursive hour-long conversation and put them into the matter file. Verbatim is unnecessary; structure is everything.

The interesting extraction problems are specific:

• Dates and deadlines in relative form. "We filed about three weeks after the incident" needs anchoring against known dates to become useful, and getting it wrong in a limitations context is consequential.
• Parties and entities. Names, corporate entities, case citations, court names — proper nouns at high density, which is the classic contextual prompting use case.
• Instruction versus discussion. Lawyers spend a lot of a client meeting exploring options out loud. Only some of that is a decision. An extraction layer that can't tell "we could argue X" from "we're going to argue X" produces a matter file that's actively misleading.

Privilege is a design constraint

Attorney-client privileged conversation is being recorded, transcribed, and processed. That's a constraint on architecture, not a paragraph in your terms of service. Practical implications: know and be able to state where audio is processed and stored, offer data residency where clients require it — AssemblyAI provides EU residency through api.eu.assemblyai.com at the same price as US — and be precise in your documentation about retention. Firms will ask, and "we're working on it" loses the deal.

Legal technology is a mature buying category with real incumbents; conversation intelligence platforms serving law firms already set the expectation that a vendor can answer these questions crisply.

The shared architecture

Despite the differences, the build is more portable than it looks. Here's how the three layers vary across the two verticals:

That bottom row is the design insight. All three products use the same pipeline and put the pressure in a different place. Building one well doesn't automatically get you the others, but it does get you most of the infrastructure — which is why teams that started in one of these verticals tend to expand into the adjacent one rather than rebuilding.

For the extraction layer itself, you don't need a separate provider. The LLM Gateway gives you one API into models from OpenAI, Anthropic, and Google, so you can run structured extraction against the transcript without adding a second vendor relationship, a second bill, and a second set of logs to the stack.

Where the accuracy bar actually sits

A question worth answering honestly, because it differs more between these verticals than people expect.

Veterinary can tolerate imperfection with review. The vet reads and signs the record. A missed word in a narrative field is caught and corrected in seconds. What's not tolerable is a wrong drug or a wrong dose surviving into a signed record, which argues for a design where high-risk fields are explicitly surfaced for confirmation rather than buried in prose the reviewer skims.

Depositions have a much higher bar and a much better safety net. Attribution errors are serious, but the entire legal process is built around review — transcripts get read, corrected, and certified. The product risk isn't that an error is unrecoverable; it's that enough errors make review more expensive than the tool saves, and the product silently stops being used.

Client meetings are the riskiest of the three, because nobody reviews them carefully. A matter file entry gets skimmed and accepted. An extracted deadline that's wrong by a week may not be noticed until it matters. High-stakes extracted fields should carry provenance — a link back to the moment in the audio where the claim came from — so verification is one click rather than a re-listen. This is the single most valuable design decision in the whole category and the one most often skipped.

What's actually in the way

Not the models. The transcription and extraction layers for both of these verticals are available today, and the accuracy is there for the audio conditions involved.

What's in the way is that both are conservative, relationship-driven professions where the record has legal weight and the buyers are small practices rather than enterprise IT. Adoption comes from practitioners who try it on one consultation or one meeting and find it saved them an hour, not from a procurement cycle. Which means time-to-first-useful-output matters more than feature completeness, and a product that needs configuration before it produces anything will lose to one that produces something imperfect immediately.

The medical scribe category proved the pattern works and normalized the idea of recording a professional conversation — a real barrier that someone else already paid to remove. The verticals next door are wide open, and they're wide open for the least interesting reason: everyone building in this space went to the biggest market first.

Frequently asked questions

What is ambient AI?

Ambient AI describes software that listens to or observes an activity passively in the background and produces useful output from it, without anyone directing it turn by turn. In a documentation context, an ambient AI scribe captures a natural professional conversation and generates the structured record that conversation requires, rather than transcribing dictation aimed at the software. The defining property is that the human's behavior doesn't change — they have the conversation they were going to have anyway.

How do I build an ambient scribe for veterinary consultations?

Start with transcription that holds up on noisy multi-speaker room audio with animal vocalization and heavy overlap, then add speaker diarization so the clinician's findings stay separate from the owner's reported observations, then a structured extraction layer over the diarized transcript. Use contextual and keyterm prompting to prime the model with the practice's drug formulary and common breed names, scoped per appointment rather than as one exhaustive list. The distinctive design requirement is preserving the difference between what the owner observed, what the owner concluded, and what the vet found — flattening those produces a record that misattributes the owner's guess to the clinician.

How is a legal ambient scribe different from a medical one?

Two ways, depending on which legal product you mean. A deposition scribe inverts the usual requirements — disfluencies and false starts are evidence and must be preserved rather than cleaned up, speaker attribution is a correctness requirement rather than a convenience, and word-level timestamps have to be reliable enough for video synchronization. A client-meeting scribe is closer to a medical scribe but centers on extracting dates, parties, deadlines, and instructions, and it has to distinguish a lawyer exploring an option out loud from a lawyer stating a decision.

Can an AI scribe replace a court reporter?

No, and products in this space should be explicit about that. A certified court reporter produces the official record, with legal standing that transcription software does not have. The realistic near-term product is augmentation around that record — preparation, review, searchability, exhibit and objection indexing, and rapid rough transcripts — rather than replacement of it.

What speech-to-text accuracy do I need for an ambient scribe?

It depends on which layer is load-bearing for your vertical and on how carefully the output gets reviewed. Veterinary records are read and signed by the clinician, so narrative imperfection is cheap while a wrong drug or dose is not — surface high-risk fields for explicit confirmation. Client-meeting notes are the riskiest case because nobody reviews them closely, which is why extracted deadlines and commitments should carry provenance back to the moment in the audio.

What's the best speech-to-text API for building an ambient scribe?

The criteria that matter most are diarization quality on overlapping short turns, robustness to real-room noise, support for contextual and keyterm prompting to handle domain vocabulary, and a path to structured extraction without adding a second vendor. Universal-3.5 Pro produces the transcript and speaker changes jointly rather than in separate passes, which is what preserves short turns in three-way conversations, and the LLM Gateway provides the extraction layer through the same platform. Pricing is $0.21/hr pay-as-you-go with no minimums, and EU data residency is available at the same price for practices with residency requirements.