Notes From Production AI

Every company we talk to has the same three problems, phrased differently: manual review takes too long, critical signals are easy to miss, and scaling operations with more people becomes expensive fast. These aren't technology problems at first — they're workflow problems. The technology question only matters once you've mapped the workflow honestly.

Our approach is deliberately simple. First, map the workflow: where does information enter, who touches it, where does judgment actually get applied, and where do errors get expensive? Second, design the AI pipeline around those judgment points — not around whatever model is trending this quarter. Third, deploy a usable system, which means monitoring, guardrails, and a human escape hatch, not a notebook that worked once.

A concrete example: measuring road construction progress from satellite imagery. The manual version was someone comparing images by eye and updating a spreadsheet. The AI version detects completed, in-progress, and planned segments and produces a progress score — 78% complete, up 32% since January — automatically, every time new imagery lands. Same workflow, same decision, radically different speed and consistency.

If your workflow is visual, repetitive, document-heavy, or hard to scale, it's probably a candidate. The outcome you should demand from any AI project is the same one we hold ourselves to: better speed, higher consistency, and actionable operational insight. Anything less is a demo.

A demo answers the question "can this work?" A production system answers a harder question: "does this keep working when the inputs are ugly, the volume is real, and nobody from the vendor is in the room?" Most AI projects die in the gap between those two questions.

The gap looks like this. A demo classifies clean sample images; production means a multi-camera grading station on a warehouse floor processing used laptops all day, where lighting drifts and throughput matters. A demo transcribes a recorded call; production means live telephony with barge-in handling, where the system has to know the right moment to interject and what the next best action is. A demo extracts fields from one invoice; production means 128 legal invoices in a cycle, duplicate detection across vendors, and $41,280 in flagged charges someone has to trust enough to act on.

Building for production changes your engineering decisions from day one. You design for the worst input, not the best. You instrument everything, because "the model seems off" is not a bug report. You plan the human handoff, because the goal isn't replacing judgment — it's spending human judgment only where it's actually needed.

Our rule: if the system doesn't solve a real operational bottleneck under real conditions, it doesn't count as done. That's a higher bar, and it's the only one worth paying for.

Ask a company where its data lives and they'll point at a database. But watch how the business actually runs and you'll find the important signals somewhere else entirely: in photos taken on a warehouse floor, in phone calls with customers, in email threads where tone matters as much as content, in satellite and street-view imagery, and in PDFs nobody has time to read carefully.

This is the data that used to be inaccessible to software — and it's exactly where modern AI earns its keep. Vision models turn a photo of a baseball card into player, year, brand, condition, and an estimated market value. Document intelligence turns a stack of legal invoices into structured line items with duplicate charges flagged. Voice AI turns a live call into intent, sentiment, and a recommended next action. Geospatial models turn imagery into "this roof needs repair" and "this road is 78% complete."

The pattern across all of these is the same: unstructured input, structured decision. The AI's job is to convert the messy real-world signal into something your operations can grade, monitor, and act on.

The practical takeaway: don't start your AI roadmap by asking what's in your database. Start by asking which decisions your team makes by looking at something — an image, a document, a map, a call. Those are the workflows where important signals are getting buried today, and where an AI system pays for itself fastest.

Trademark search is a perfect example of a problem that text search structurally cannot solve. Two logos can share zero words and still be confusingly similar — and that visual similarity is exactly what the legal question turns on. For years the answer was manual: page through registries and squint.

The modern answer is embeddings. We built Trademark Lab to compute image embeddings with a vision transformer, so every mark becomes a point in a high-dimensional space where visual similarity is literally distance. Drop in a query logo, run a vector search across USPTO and EUIPO datasets, and get back the closest marks ranked by similarity score — 92%, 89%, 87% — each with its registration details attached.

Two lessons from shipping this generalize well beyond trademarks. First, the embedding model matters more than the search infrastructure: vector databases are commodity now, but whether "similar" means what your users mean by similar depends entirely on the model and how you tune it. Second, scores need anchoring: an 87% similarity score is meaningless until users learn what an 87 looks like, so the UI has to show the evidence, not just the number.

If your team searches for anything by describing it in words when what they really mean is "find me things that look like this" — products, parts, defects, designs — embedding search is the upgrade they don't know they can ask for.

Most AI projects live entirely in software. Some of the highest-value ones don't. When we built the used-laptop grading station — a multi-camera rig for AI-assisted cosmetic inspection — the model was maybe a third of the project. The rest was physics, and the physics is where these projects are won or lost.

Fix the capture, and the model's job gets easy. A grading model that has to cope with random angles, mixed lighting, and inconsistent framing needs to be far smarter than one that sees every laptop from the same fixed cameras under the same lights. We spent our effort making the input boring: rigid camera mounts, controlled lighting, a repeatable placement guide. Consistent capture converts a hard vision problem into a manageable one.

Design for throughput, not for the demo. A station that grades one laptop beautifully but takes three minutes per unit is a science project. The workflow — place, capture, grade, route — has to keep pace with a real intake line, which shapes everything from camera trigger timing to how results get written back to the operations system.

Consistency is the product. The pitch was never "the AI is smarter than your graders." It's that the AI gives the same answer at 9 a.m. and 4 p.m., on Monday and Friday, for the hundredth unit and the ten-thousandth. In grading workflows, that repeatability is what eliminates disputes and expensive errors.

If your operation touches physical objects — grading, inspection, counting, sorting — don't let anyone tell you it's just a model problem. It's a capture problem, a throughput problem, and a consistency problem. The model comes after.

Everyone evaluating voice AI asks about transcription accuracy. Almost nobody asks the question that actually determines whether callers tolerate the system: how does it handle interruption?

Barge-in — a caller speaking over the system — is where telephony AI gets hard. The system has to detect the interruption fast, stop talking, understand what the caller actually said, and decide what to do next, all in real time on a live call. Get it wrong in one direction and the system talks over people, which callers experience as disrespect. Get it wrong in the other and every background noise derails the flow.

In the Asterix telephony work, we treated barge-in as a first-class signal rather than an error condition. The live analysis tracks intent and sentiment continuously, so when a barge-in is detected — say, 47 seconds into the call — the system already has context for what the caller is trying to do, and can update the next best action instead of restarting a script. The workflow becomes: call start, barge-in, AI process, action taken. The interruption is the data.

The broader lesson applies to any real-time AI: the awkward edge case that everyone deprioritizes is usually the thing users judge the whole system on. Handle the interruption well and the system feels intelligent. Handle it badly and no transcription accuracy number will save you.

Before Simple Intelligence, our founder spent 2012 to 2017 as a software development engineer on Microsoft Bing, building document-processing infrastructure — including a DOM tree parser for the Bing Document Understanding Platform that ran roughly 10% faster than its predecessor. That sounds far from today's document AI. It isn't. It's the foundation of it.

Web-scale document understanding teaches you three things that transfer directly to every invoice, contract, and architectural plan we process today. First, structure is everything: a document isn't a bag of words, it's a tree — sections, tables, line items, annotations — and extraction that ignores the structure produces confident nonsense. Second, performance compounds: a 10% faster parser sounds incremental until you multiply it across billions of documents; the same math applies when a client's invoice pipeline runs nightly against thousands of PDFs. Third, the ugly documents are the job: at web scale there is no clean input, so you build for malformed markup, scanned artifacts, and inconsistent layouts from the start.

Modern language models have made document extraction dramatically more capable, but they haven't changed those fundamentals. Our legal bill audit system works because it respects invoice structure — vendors, line items, PO references — not because a model reads the PDF like prose. The lesson from Bing still holds: document AI is an engineering discipline wearing a machine-learning costume.

Most workplace AI reviews things after the fact: post-call analytics, quarterly audits, retrospective dashboards. Useful — but the highest-leverage moment is usually before the action, not after it.

Corporate email is a case study. A conflict-heavy email — urgent tone, blame-adjacent phrasing, a hard "ASAP" — does its damage the moment it's sent. So we built an email intelligence assistant that works in the compose window: it corrects grammar and clarity, detects conflict-heavy wording and urgency, scores the message tone, and suggests more collaborative phrasing while the draft is still a draft. The send button comes with an AI check, not an AI apology.

The same "intervene before, not after" pattern shows up across our work. In telephony, barge-in detection means the system acts during the call, when the next best action can still change the outcome. In legal billing, duplicate detection runs when the invoice arrives, before it's paid — which is how 23 duplicate charges worth $41,280 get caught instead of written off.

When you evaluate an AI opportunity, ask where in the timeline it sits. Analysis after the fact is worth something. A system that catches the error while it's still cheap to fix is worth far more.