Could Your Intake Handoffs Drop Facts? A 30-to-50-Inquiry Trace Test

As of October 2026, a recently reported product demo gives a public description of how an AI assistant passes case facts to another system. It is a demo, not an intake study. The design question underneath it is still one intake operators face: when a record moves from one tool to another, which facts travel, who decides, and how would anyone notice a fact that did not?

This article uses the demo as a pattern, not as proof about intake. Whether any particular firm loses inquiries at its handoffs is a hypothesis that only first-party data can confirm or reject. From public sources we can describe a test worth running.

What was reported

On October 22, 2026, LawNext reported that LexisNexis Protégé is now live inside EvenUp, a platform for personal injury lawyers. The reporter was given a demo by EvenUp's cofounder and chief product officer and a LexisNexis senior director of product management. This is trade reporting of a company-led demo, not independent testing.

As described, a user working in EvenUp's Companion assistant can invoke Protégé, ask a legal question, and receive an answer grounded in Lexis case law and statutes. The answer is informed by facts drawn from the case materials already in EvenUp. The connection runs over the Model Context Protocol (MCP). Before the question goes to Lexis, Companion looks at the structured data EvenUp extracted from the case file and the underlying documents, decides which facts are relevant to the question, and packages them with the prompt.

Four details from the report are, in our reading, the ones most relevant to operators:

• Selection happens before the call. According to the report, the sending system decides which facts are relevant and packages them with the prompt. The report does not say whether a user can see which facts were chosen.
• Provenance comes back. Each statement in the response carries a linked citation, and the cited authorities are listed with their Shepard's signals, so the lawyer can check the grounding without leaving EvenUp.
• Scope is narrow. The integration is limited to legal questions and answers. Drafting is not part of the MCP application yet. The reverse direction, in which a lawyer in Protégé pulls case facts out of EvenUp, is not available, and the companies say it is coming.
• The pitch is about manual effort. LexisNexis described prompts growing in size as lawyers try to share case context, and said document-management connections still leave the lawyer to work out which files to upload.

Use also requires subscriptions to both products. Nothing in the excerpt reports accuracy rates, error rates or outcomes, and we do not infer any.

Why this is an intake question

Intake is a chain of handoffs. A call, form or chat becomes a record in a CRM, which may trigger a conflict check, a scheduling step, a conversation with a lawyer and a follow-up sequence. At each link, someone or something decides which facts move forward. Our inference is that the reported design is a useful reference because it describes that decision in concrete steps: structured extraction, relevance selection, a packaged payload, and cited output. The source does not frame it as an intake pattern.

Our hypothesis, which we cannot source, is that in some intake stacks the same decision happens implicitly. A summarizer may compress a transcript. A field mapper may drop whatever has no destination field. A routing rule may read one tag. If a deadline, a second party, a referral source or an urgency signal did not survive one of those steps, it is possible that nothing would flag it. Test whether your stack behaves this way before assuming it does or does not.

Where leakage could hide: a hypothesis

We are not claiming any firm loses leads this way. The four items below are our own hypotheses about where a discovery exercise could look. None comes from the sources, and each is testable only with the firm's own records:

1. Extraction (hypothesis). Facts stated by the prospect might never become structured fields. Whether that happens is unknown until records are checked.
2. Selection (hypothesis). Facts might exist in the record but not be packaged into the next step's context. This is our extrapolation from the reported selection step, not a finding about intake.
3. Routing (hypothesis). Inquiries might be sent to a queue, owner or sequence that does not match what the prospect actually said.
4. Return path (hypothesis). Outcomes (retained, declined, referred out, no response) might never flow back to the source record, which would make any loss invisible in reporting.

The last one is the one we would check first, as a judgment call. The reported integration is one-directional for now, with the reverse on the companies' roadmap. If your own stack also moves data forward more easily than outcomes move back, that is worth knowing. Only your records can say whether it does.

Three supporting signals, with their limits

Inspectable intermediate state. An arXiv abstract on prompt-to-structure design describes an agent connected to a structural modelling API through an MCP server. According to the authors, the agent creates and modifies a graph of explicit building elements through controlled operations, and the resulting artifacts can be inspected, modified and serialized. The authors call the results preliminary, and the domain is structural engineering, not law. The idea we would borrow is architectural: if an agent acts through explicit operations on a visible data model, a reviewer has something to inspect. That is our inference, not a finding of the paper.

Shared context between agents. A separate arXiv abstract on a shared memory buffer for asynchronous agents proposes a protocol where agents exchange intermediate findings through a shared buffer while each agent's private reasoning stays local. The authors report better accuracy and fewer tokens than multi-agent debate on their benchmarks. Those are author claims on reasoning tasks, not reproduced results, and not intake. The narrower point it supports is the authors' statement that failures often arise from ineffective exchange of critical information between agents. We read that as a reason to test the exchange mechanism on its own, which is our inference.

Vendor framing of intake. A Harvey guide on evaluating AI case management software is vendor guidance, not independent evidence. It lists intake triage and conflict checking among current capabilities, says those capabilities are not uniformly mature, and describes evaluating platforms without being taken in by what a vendor shows in a conference room. We would adopt that last point as method and set aside the vendor's customer statistics.

One more public observation: Artificial Lawyer reported that Womble Bond Dickinson launched an AI Labs group that the firm says will focus primarily on tasks that are structured, repeatable and well-defined. That is the firm's stated scoping, not a result. We think it is a sensible filter for intake pilots, as a judgment: start where the inputs and the definition of a correct output are clear.

A handoff test you can run

This extends a method we described in our earlier piece on testing intake answers against record-level proof. The goal is to measure fact survival at each link, not to score the final answer.

1. Build a seed set. Pull 30 to 50 closed inquiries from your own system, with consent and confidentiality handled under your own policies. Include retained, declined and unanswered ones. For each, write down by hand the facts a lawyer would need: parties, urgency, dates, asset or injury details, referral source, and anything the prospect asked for.
2. Trace each fact. For every inquiry, check whether each fact appears in the CRM record, in the summary shown to the intake owner, in the payload sent to any downstream agent or tool, and in the follow-up message. Mark present, altered or missing at each stage.
3. Separate dropped from never captured. A fact missing from the CRM points to an extraction problem. A fact in the CRM but missing from the downstream payload points to a selection problem. These likely have different owners and different fixes.
4. Check routing against the facts. For each inquiry, ask whether the assigned owner, queue and sequence match what the prospect said. Count mismatches by cause.
5. Require provenance. Any agent summary or recommendation should point back to the source line in the record. If it cannot, treat the output as unverified, much as the reported integration attaches citations to each statement.
6. Close the loop. Confirm that each final status writes back to the originating record. If outcomes live only in a lawyer's inbox, you cannot measure leakage at all, and that is itself a finding.

Record every miss in a log with the stage, the cause and the fix. Rerun the same seed set after each configuration change so improvements and regressions are visible.

Design choices worth borrowing

Everything in this section is our inference and suggestion, drawn from the reported design. None of it is a conclusion the sources prove, and none of it has been tested in an intake setting.

• Structured first. The reported design selects facts from extracted structured data and the underlying documents, rather than asking the lawyer to assemble context by hand. Our inference for intake: capture fields at the point of conversation and keep the transcript attached.
• Label the source. The reported response is clearly marked as coming from Protégé. Our suggestion is that any agent output in your CRM could likewise say which system produced it and from which inputs.
• Keep the scope honest. The companies limited the first release to questions and answers and said so. Our expectation, not a sourced finding, is that an intake agent that may read and flag, but not decline or schedule, would be easier to test than one that does everything.
• Let a human continue the thread. In the demo, a button opens the same conversation in Protégé with the case context that came over from EvenUp. Our suggestion is that a lawyer receiving an intake should similarly be able to open the record the agent worked from.

What not to conclude

The EvenUp and Lexis integration is a personal injury research workflow. It says nothing about intake conversion, lead loss or the quality of the answers it produces, and the LawNext piece does not claim otherwise. The two arXiv items are abstracts reporting author claims from other domains and benchmarks. The Harvey page is vendor guidance. None of it shows that a given firm has a leakage problem.

What the sources do support is a description of a reported architecture: extraction, deliberate selection of facts, provenance on outputs, a defined scope, and a path for context to continue. Our own reading is that these are useful properties to look for in an intake stack. That reading is an inference, not something the sources demonstrate. Whether your current stack has those properties is a question your own records can answer, and a fact-survival trace across 30 to 50 inquiries is a small enough exercise to start with.