A Sub-Second Research Agent for Legal, Clinical, and Financial AI

TLDR: A research-grade query in a vertical AI product isn't one lookup — it's a chain. The architecture that closes the McConaughey demo in 1,057 ms runs the chain on legal, clinical, and financial corpora through the same agentic_search=True flag. This is the architecture, three vertical builds, and the SDK call. Three research-agent screens side by side — legal, clinical, financial — each with a hop-by-hop chain and a sub-1.5-second timing pill. A research query in vertical AI isn't retrieve top-K and call it a day. The user asks one question. The system traverses three or four hops over the corpus. Each hop grounds the next. The final answer comes back with citations the partner, clinician, or analyst can verify. The sub-second agentic search post walks through the engine and the 1,057 ms demo timing. This post is how that engine becomes a product in three verticals. The architecture: Four pieces, in a loop the planner controls. A distilled query decomposer turns the question into hop sub-queries. The McConaughey demo runs decomposition in ~200 ms, no LLM in the loop. A compressed vector index keeps the candidate pool in RAM. Single-digit milliseconds per retrieval at 10M+ vectors. See VDBBench at https://results.daseinai.ai/results Per-query α and per-query K run every hop. Fusion weight and cutoff adapt to what the hop needs — a few milliseconds of overhead per hop, not a reranker tax. A reader pulls the cited answer at each hop and grounds the next sub-question in it. Generic sub-second research-agent architecture: user query to decomposer to 4-hop loop, composed of compressed index, per-query α plus K, and reader, then to cite-back UI. The demo budget closes because the four pieces were designed together. Compression keeps the index in pod RAM. Per-query α drops the LLM-in-the-loop reordering. Per-query K caps the reader's input before the reader runs. The distilled planner skips per-hop LLM rates. You can't buy any of those four separately and stitch them up to a one-second four-hop budget. What changes per vertical: the corpus, what filters apply at each hop, what the reader pulls out, and how the cite-back surfaces. Legal — Delaware contracts: Controlling Chancery precedent for clause 14(a) breach claims where force majeure was raised as an affirmative defense, contracts governed by Delaware law. Four hops. First, identify the doctrinal area: commercial contract breach under the DGCL, sophisticated parties, force majeure as defense. Second, pull Delaware Chancery and Delaware Supreme opinions in that area, filtered by court and date. Third, narrow to cases where force majeure was actually raised — a lexical filter. Fourth, find the controlling case by subsequent treatment and Supreme Court affirmance. Corpus: Chancery and Supreme opinions, indexed once. Filters: court level, date range, jurisdiction. The force-majeure hop runs BM25-leaning because force majeure is a phrase BM25 picks up reliably. The doctrinal hop runs semantic because it's about ideas, not strings. Cite-back surfaces the controlling case with parallel citation, the deciding Chancellor or Vice Chancellor, the paragraph where force majeure was discussed, subsequent-treatment count, and the intermediate hops as expandable rows showing what was retrieved and ranked. Partners check every cite before they file. An answer without a traceable cite isn't an answer they'll use. Clinical — apixaban subgroup evidence: Apixaban PK and bleeding outcomes in non-valvular AF patients with CrCl 15–29 mL/min — what's the evidence base? First, resolve the intervention: apixaban or Eliquis, direct factor Xa inhibitor, NVAF indication. Second, pull apixaban trials and PK studies in AF with renal subgroups. Third, narrow to CrCl 15–29 mL/min — a lexical threshold filter. Fourth, return outcome tables with NCT identifiers. Corpus: PubMed abstracts plus ClinicalTrials.gov plus FDA labels. Filters on intervention, indication, and patient population. The drug-name and threshold hops run BM25-leaning. The clinical-condition hop stays semantic. Cite-back is a trial-by-trial table: trial name, NCT identifier, sample size, subgroup size, primary endpoint with 95% CI, safety endpoint. Every number links to the trial result. Clinicians don't use what they can't audit — a confidence interval without a registry anchor doesn't make it into their notes. Financial — goodwill impairment in 10-Ks: S&P 500 industrials with goodwill impairments above $1B in FY 2024 where the impairment disclosure cited macroeconomic conditions. First, the universe: S&P 500 industrials by GICS, fiscal year 2024. Second, 2024 10-K filings reporting goodwill impairments above the threshold. Third, narrow to filings whose impairment language cites macro conditions. Fourth, return company, amount, segment, and the source paragraph. Corpus: SEC EDGAR 10-Ks plus earnings transcripts plus XBRL. Filters on filing type, fiscal year, and GICS classification. The easy version of this query lives in XBRL. us-gaap:GoodwillImpairmentLoss is a tagged field; structured queries against it close in milliseconds. The hard version is when the impairment lives in MD&A narrative with no XBRL tag — a sentence in management's discussion two paragraphs from the word goodwill, with the dollar figure in a different paragraph. The canonical example is Kraft Heinz Q4 2018, where the $15.4 billion brand-and-goodwill writedown was discussed in narrative prose, not structured tags. That's where the reader earns its keep — extracting the dollar figure and the macro-citation language from free text. Cite-back: a ranked table by impairment magnitude — ticker, segment, amount, fiscal quarter, and the specific MD&A or footnote paragraph. Every row links to the filing on EDGAR. Where the figure came out of narrative prose, the cite highlights the source sentence and the paragraph it sat in. An analyst auditing the answer reads what the reader read. Three vertical research agents — legal, clinical, financial — same architecture, different corpora and cite-back. The integration: pip install dasein-ai, then one managed call per query. Python example: from dasein import Client. client = Client(api_key="dsk_..."). de_law = client.create_index("delaware-caselaw", index_type="hybrid", model="bge-large-en-v1.5"). de_law.upsert(legal_docs). response = de_law.query("Controlling Chancery precedent for clause 14(a) breach claims where force majeure was raised as an affirmative defense.", top_k=10, agentic_search=True, mode="hybrid", dynamic_hybrid=True, dynamic_top_k=True, filter={"court_level": {"$in": ["chancery", "supreme"]}, "jurisdiction": "DE"}, include_answer=True, return_hops=True). Print response.final_answer. For each hop, print the hop number, sub-query text, and number of fused IDs. For each result, print its ID, score, and metadata. The clinical and financial agents are the same call shape. The corpus changes. The filter expression changes. The metadata schema changes. The chain loop, the planner, the per-hop α and K prediction, and the per-hop ranking all sit behind agentic_search=True. For a bring-your-own retrieval stack — your own dense plus BM25 pipeline — client.predict_dynamic(text, query_vector=...) returns the per-query α plus K cutoffs as three scalars in one HTTP call. The chain loop and the cite-back assembly live in your application code on top of that. Cite-back UX mockup — legal example showing cited final answer plus expandable hop rows with retrieval rank and α weight. Corpus scaling: The pattern runs from hundreds of thousands of documents up through tens of millions of vectors. At 10M+, per-hop retrieval still lands in the millisecond range per the VDBBench dashboard at https://results.daseinai.ai/results Dasein-Efficient hits 4,081 QPS at recall@10 = 0.87 versus Pinecone p2.x8-1node-v2025.1 at 1,131. Recall at your operating point shifts with corpus density. Tune top_k and the dynamic toggles against your own data, not against a benchmark. What you'd be building: If you build this in-house, the load-bearing pieces are a compression scheme that keeps the index in RAM at your production scale; a per-query α predictor that runs sub-millisecond, no LLM in the loop; a per-query K predictor wired into the index path; a distilled planner that decomposes domain queries reliably without paying LLM rates per hop; and the cross-layer co-design that makes the four compose into the budget. That's the engineering. Six to nine months for a team that has the people. Whether you build or buy depends on your timeline. If you'd rather A/B against a running system, the design partner program is open. Two weeks from intro call to working A/B on your corpus.