The Exception Queue

Decision-trace infrastructure and the ultimate prize for Vertical AI

The most valuable data in vertical AI gets captured every day with little fanfare. Someone overturns a denied prior authorization, corrects a freight dispute, or swaps an equipment order, and the reasoning evaporates the second they move on to the next case. As most work gets done, the judgment behind it is lost forever.

We believe that judgment will prove to be the real prize in Vertical AI, separating great products from great companies. Agents can already follow rules, pull the right data, and generate useful documents. What they can’t do is handle exceptions: the case that doesn’t fit the template, where a human has to intervene based on market, customer, and counterparty-specific context. Those calls don’t live in an ERP, CRM, WMS, etc. They pile up in the exception queue, and they vanish as fast as humans clear them. Longer term, enterprise value in Vertical AI accrues to whoever captures the reasoning behind that human judgment.

We’re already seeing this pattern in the early vertical AI breakouts. Tennr owns referrals. EvenUp owns demand packages. Abridge owns clinical documentation. On the surface, the products look different. Underneath, they all do some version of the same thing: they sit inside a repeated, high-consequence workflow that leaves behind a reusable decision trace with every resolution. This is the exception queue, and we believe it’s the most valuable asset for each Vertical AI startup to capture.

Why Wedges Work

In evaluating wedges, we often think of a two-part test: on one axis, exception density; on the other, the cost of failure (or delay). The former, as you might expect, considers the frequency of workflow exceptions requiring remediation. The latter considers what happens when exceptions aren’t caught swiftly or handled properly.

A workflow with high exception density but low consequences may drive usage — and even near-term revenue growth — but usage is not a proxy for urgency or durability. It becomes a productivity tool, and productivity tools are fragile in a world where the frontier of intelligence is rapidly commoditized. A workflow with high consequence but low frequency can matter, but it often behaves more like a consulting project than software.

When the cost of failure or delay is high, the buyer has urgency. “Cost” can show up as unrealized revenue, idle labor, margin leakage, compliance exposure, or cash flow getting stuck. That is why delay matters as much as failure. A prior authorization that technically clears but arrives too late has still failed the workflow. A recoverable denial that is not appealed within the window still results in leaked revenue. A freight dispute that closed after the invoice ages out can still damage cash conversion.

When the cost of failure or delay is high, the buyer has urgency. “Cost” can show up as unrealized revenue, idle labor, margin leakage, compliance exposure, or cash flow getting stuck. That is why delay matters as much as failure. A prior authorization that technically clears but arrives too late has still failed the workflow. A recoverable denial that is not appealed within the window still results in leaked revenue. A freight dispute that closed after the invoice ages out can still damage cash conversion.

What the test points you toward is the exception queue: a steady stream of non-standard cases that humans already triage, escalate, document, resolve, and audit. Take prior authorization. In Medicare Advantage alone, a recent KFF study found nearly 53 million prior authorization requests submitted in 2024, and 4.1 million were denied. Only 11.5% of those denials were appealed, and 80.7% of the appeals won. The constraint? Physician capacity. A recent AMA survey shows that physicians complete an average of 39 prior authorizations per week, which consumes roughly 13 hours. The system is designed to drain provider resources and capacity. Of the denials anyone bothered to fight, more than four in five were reversed.

Logistics has the same patterns. A shipment can technically arrive after a missed appointment or a disputed accessorial charge, but the delay still burns money. For 3PLs, for example, up to 35% of invoices are disputed. Errors, missed charges, and improper billing not only hurt profitability and increase average DSOs, but they also lead to customer churn.

Another useful indicator: glue functions. Care coordination, claims processing, freight audit, permit coordination, and procurement exceptions often live across spreadsheets, email threads, phone calls, portals, and people’s heads. The context is fragmented across multiple systems and people, and the resolution depends on judgment.

That’s what a great wedge looks like: judgment calls someone is already paid to clear, high cost to the constraint or delays, and a recurring queue.

Where the Best Enter the Queue

The best vertical AI companies don’t all look like “exception queue” companies on the surface. Some start at the queue itself: referrals, denials, permits, and billing disputes. Others start one step upstream, at the authoring event that feeds the queue. But the question that determines long-term value is the same: does the product sit where decision traces are a natural byproduct of usage?

We see two viable entry points.

1. At the exception itself.
   Tennr starts where the referral is already broken. EvenUp starts where the claim is already disputed. The exception happens often, failure or delay is expensive, and resolution requires context. Every resolved case produces a decision trace, the thing the customer trusts, forwards, reviews, audits, and acts on. It is also what lets the product learn. When resolution *is* the product, the trace comes free with every case cleared.

2. At the authoring event upstream.
   Abridge is a strong example. The clinical encounter is not always an “exception” in the operational sense, but it is always a high-context moment that must be documented. The exception queue emerges downstream when that clinical detail flows into medical coding, risk adjustment, and revenue protection. The decision trace comes initially from what’s documented, then deepens as the documentation moves through the workflow. Once you own the context, you begin to see the exceptions downstream.

Both paths work because both end up in the same place: sitting inside a high-consequence workflow, generating decision traces with every resolution. The difference is the entry point. The risk of starting at the queue is that you’re in the messiest, most integration-heavy part of the workflow. The risk of starting upstream is that you might generate context without ever reaching the queue, where it compounds. Abridge works because clinical documentation *necessarily* flows into coding and billing. An authoring tool that produces a useful document with no downstream workflow destination is just a productivity tool.

Broader platforms, Harvey, Legora, or TrunkTools, face the same question at each workflow they touch. They can be very large without looking like a single exception-queue wedge. But the defensibility question remains: does usage compound into proprietary workflow memory? Does the product learn the firm’s playbook, the client’s preferences, or category-specific nuance? Or does it remain a better interface to general-purpose intelligence? These companies need to identify queue depth *somewhere* within their breadth.

Owning the Decision Trace

As many investors in both private and public markets worry about the long-term health of the software industry, we believe the exception queue offers a compelling case for the defensibility of Vertical AI (and some Vertical Software incumbents). By executing work agentically rather than serving as a system of record, Vertical AI businesses aggregate proprietary knowledge of industry workflows. This knowledge, accumulated from customers using the platform over time, is arguably more important than simple information access: (1) it doesn’t exist in any structured format today (it mainly lives in domain experts’ heads) and (2) it is truly first-party, generated by product usage itself, mitigating any challenges around IP or ownership.

Aman Gour, CEO of FurtherAI, a startup automating insurance workflows, shares an instructive observation about the defensibility of the exception queue:

Over time, every escalation becomes a signal, every exception is feedback and every human correction shows where the runbook was incomplete. Over time, the workflow stops being a script and starts becoming the [insurance] carrier’s operating memory. This is the part the labs will find hard to reach. They will keep shipping better models and better general agents, and they should. But they do not sit inside a carrier’s production workflows long enough to learn why one account was escalated, why one risk was declined, or why an underwriter overrode the appetite guide and was right to do so.

That understanding only comes from running the workflow, in production, many thousands of times. The workflow you ship on day one is not the moat. The loop that production usage creates over time is.

Every resolved exception leaves behind a decision trace: which policy was applied, which precedent was relevant, who approved the override, what the customer accepted, how long it took, and what occurred afterward. Collect enough of these traces across cases and years, and you begin to build proprietary workflow memory, a growing record of how high-stakes decisions are made within a specific vertical and customer. Over time, workflow loops improve the product and move it closer to a true System of Intelligence.

The sequence looks like this:

The authored object is the bridge. It is the container for workflow-specific judgment. It records what evidence mattered, which rule applied, what exception was granted, what changed, and whether the resolution worked. In our Emerging Playbooks in Vertical AI essay, we described the ideal wedge as a product that creates what a human would otherwise have to create — documentation, a referral packet, a demand letter, an appeal — and hands it off to another system, as a human would. The exception queue sharpens that idea. The best wedge not only creates the authored object but also captures the decision trace—the reasoning behind it. Each trace adds to the company’s workflow memory, which is what makes the next case easier.

Two workflow loops stack from there. An across-customer loop, where patterns grow as you encounter more variants of the same problem within a vertical. And a within-customer loop, where the product learns the reasoning behind a specific customer’s decisions — the unspoken exceptions, the firm’s own decision logic that emerges only through direct interaction with the system.

As we argued in our essay on Vertical AI moats, the software vendor earns additional customer trust over time, enabling multi-product expansion. The core products continue to accrue defensibility through workflow loops, while each new product benefits from growing platform lock-in. The expansion path should follow the workflow and the decision trace.

Startup examples make this more tangible. Tennr can build referral-specific workflow memory: which providers send incomplete packets, which specialties create the most back-and-forth, which payers slow down which paths, and which missing fields predict leakage. EvenUp can build firm and case-specific workflow memory: which records change settlement posture, which injury patterns matter, which insurers respond to which arguments, and how long different case types take to resolve. For Abridge, the workflow memory surrounding the clinical notes can include specialty-specific documentation patterns, billing and coding support, care-team handoffs, and the institutional memory of how clinical cases are handled.

This is the missing middle between the authored object and the System of Intelligence, and where the moat begins to deepen. Not because the company “has data” in the abstract, but because the company builds a growing record of how high-stakes decisions are resolved within the workflow. A product that only reads data may still deliver insight. A product that resolves exceptions and captures decision traces can serve as the foundation for a System of Intelligence.

The Exception Queue Playbook

The queue is your wedge. Once you find it, the rest of the company-building question becomes more concrete. What does delay cost? What work product resolves the case? What reasoning should survive the resolution? And what does every cleared case teach the system that makes the next one easier?

The goal is not just to clear the queue faster. The goal is to turn each resolution into durable workflow memory: what evidence mattered, which rule applied, who accepted the answer, and what happened afterward. That memory is what produces the workflow loops for long-term defensibility. It is what lets the product improve, expand, and eventually become the System of Intelligence.

Here is the playbook as we see it:

1. Find the queue. The queue is usually visible before the software exists. It shows up as inboxes, spreadsheets, faxes, tickets, review comments, phone calls, aging reports, unanswered requests, and entire teams whose job is to chase the same class of exception every day. If no one owns the exception today, selling may be difficult. If an overworked team owns it with email, tribal knowledge, and manual judgment, pay attention.

2. Price the exception cost. The cost of failure or delay is how much the customer loses when the exception is handled incorrectly, late, or not handled at all. High cost is often the cleanest signal of urgency. Delay can be outright failure for certain queues. A prior auth approved too late can still fail the patient. An RFI answered too late can result in losing the bid.

3. Choose your entry point. You can start at the exception itself, where resolution is the product, or at the authoring event upstream, where you capture the context the queue needs—both work. What matters is that decision traces are a natural byproduct of usage, not a reporting afterthought.

4. Identify the authored object. The product should create something the customer already recognizes as work product: a referral packet, appeal, demand package, RFI response, permit submission, audit workpaper, coding recommendation, freight dispute file, or clinical note. This is where adoption starts, because the product does the work a human would otherwise have to do.

5. Capture the decision trace. Every resolution should preserve the reasoning: what evidence mattered, which policy applied, what precedent was relevant, who approved it, what changed, how long it took, and what happened afterward. This is cheap to design early and painful to retrofit later. If the product clears the queue but loses the judgment, it has automated labor without building memory.

6. Build the workflow loops. Every new case should make the next case easier. Not because the company has more raw data, but because the workflow memory becomes denser with useful relationships: payer behavior, reviewer preferences, jurisdiction quirks, customer policies, approval patterns, escalation paths, and outcomes. The question is whether each resolution adds to what the system knows.

7. Expand from the queue. The next product should be adjacent to the workflow memory already earned. Tennr can move from referrals into adjacent patient-access workflows. EvenUp can move from demand packages across the claim lifecycle. Abridge can move from clinical notes into coding and revenue cycle management. The expansion path follows the workflow and the decision trace.

Of course, no queue is the same, and false positives abound. High-volume, low-consequence workflows create usage without urgency. High-consequence, low-frequency workflows create consulting projects. Read-only workflows can produce insight, but often struggle to create compounding workflow memory. Broader platforms can grow large, but they still need queue depth somewhere within their breadth.

The best wedges sit where repeated resolution creates proprietary workflow memory. The best Vertical AI businesses will power a high-consequence workflow long enough to institutionalize that memory and turn it into a product that’s harder to leave every time it’s used. In the vertical application layer, selling intelligence is an ephemeral game — the real winners will own judgment.

---

Thanks for reading The Verticalist!

Euclid is an inception-stage VC built for Vertical AI founders. If anyone in your network is considering building in Vertical AI, we’d love to help. Just drop us a line via the comments below or on LinkedIn.