HighRoad

HighRoad is an AI deal analysis system for commercial real estate lenders and equity funds. It reads the source materials underwriters spend hours on — offering memos, rent rolls, operating statements, sponsor packages — and turns every deal into a structured record of facts, citations, synthesized metrics, and a draft investment memo.

Speed is just one of the obvious benefits, but not the full point. A firm generates a huge amount of data every time it looks at a deal and captures almost none of it in a reusable form.

Numbers continue to live in PDFs and Excel, get copied into one-off models, and lose their structure the moment the deal is passed on or dropped. HighRoad captures that data where it is created and makes it the firm’s own, turning deal flow that would otherwise evaporate into a queryable record that grows with every deal screened. The goal is to build the firm’s own data flywheel, linking new deal screening with measured success and failure of closed assets.

Our document pipeline has to be customizable and reliable at the same time. Every firm sorts deals into its own categories, every deal type unravels different picklists and metrics, and the documents are sprawling. Most of the engineering below is our solution to capture and reinvent the core analysis workflow so that truly every deal can be compared apples-to-apples.

The backend: a pipeline of agents

The shape. Every step in the backend is a small ETL job whose transform is a language model. It’s set up for automated and user-driven triggers, because a pipeline like this is re-run constantly — on partial failures, on new documents, on user edits.

• Postgres is the only thing that passes between steps, so state moves as rows rather than messages.
• Every step is idempotent and independently re-runnable, so reprocessing one document recomputes only the work downstream of it.

Ingestion. A deal enters the system and its documents are broken out before anything else happens.

• It arrives by forwarding email to a per-tenant address, or by uploading files directly.
• Attachments are split into individual documents.
• Everything after is the work of turning a pile of documents into consistently defined structure.

Two passes. The pipeline runs in two passes. The burst pass creates a better user experience, filling out the core classifications and a high level summary of the deal within 2 minutes to give the analyst something to work with.

• A burst pass runs first on just the first few documents and pages — classify the documents, fill the deal card, assign an analyst, write a provisional memo.
• A backfill pass follows with the slow work: full extraction, deal metrics, verification, the complete memo, and the page fills in as each step lands.

Classification. Before anything is read closely, every document is sorted, because its type decides how it gets handled.

• A classifier gives every document, and every sheet of every spreadsheet, a type from a controlled vocabulary: rent roll, operating statement, debt sizer, appraisal, and more.
• The type decides both how deeply the document is read and which extraction template it draws.
• The deal-level categories a firm files against are per-organization picklists, not a fixed taxonomy, because two funds almost never cut the world the same way, and a system that forces them to gets abandoned for one that doesn’t.
• For data science’s sake, all picklists still map to a canonical list ensuring we can split and join data later.

Extraction. This is the center of the system, and it is controlled and templated, not freeform. It’s the heart of what powers our financial models and deal comparisons, so it has to define terms consistently across new deals. An agent can only write keys a template defines.

• Which template applies is resolved along three axes — the organization, the deal type, and the property type — so a multifamily bridge loan and an office equity deal are read against different rubrics.
• The behavior branches are defined in SQL, so firms can create their own splitting and templating rules without any additional engineering.
• For each document the fields are grouped by category and handed to separate agents running in parallel, each with read and search tools and a schema to fill.
• Every value an agent writes carries a citation back to its source. When clicked later in the app, we can open a sidebar to display the exact PDF page or a cell range in a spreadsheet that produced a metric.

Every extracted number opens to the page it came from.

Synthesis. Once the documents are extracted, the deal is assembled from its parts.

• A synthesis step computes the deal-level metrics like loan-to-value, debt yield, and physical occupancy.
• It leaves untouched any field an analyst has already edited by hand, ensuring we don’t step on our users’ toes.
• A verification step goes back over the deal card, reconciling names, addresses, and sponsors against the extracted evidence and the open web.

Entity resolution. A fund sees the same sponsors and brokers deal after deal, and that network is one of the core drivers of the fund’s proprietary success. Today, most originators keep that knowledge in their head or in a personal spreadsheet.

• Every extracted mention of a sponsor, broker, or building is resolved against a canonical entity. We match via agentic search, then have a structured research pass for multiple potential matches.
• The links between deals and entities form a graph, so asking what else a sponsor has brought in, and how those deals performed, is a simple traversal. Any entity can be the primary object through which you see your deals.
• Sponsors are enriched further from outside sources like SEC filings and litigation records from PACER.
• The canonical entities sit in a layer with no tenant boundary.

Memo generation. The last synthesis step writes a simple summary memo.

• The agent picks a memo template by deal type and drafts section by section against the extracted facts and metrics.

How it runs. Agents are orchestrated via durable lambda functions in AWS and defined DAGs that execute at the document, deal, or entity level.

• Each step is a Lambda, and the graph is plain Python checkpointed by a durable-execution runtime.

The application: an analyst on top of the machine

From the frontend, anything a user can do by hand an agent can do as easily. From creating new deals, updating metrics, adding deals to the firmwide pipeline - all can be done just by asking.

The memo studio. A rich-text editor sits over a generated memo, and the analyst takes it over from there.

• Analysts can create personal, team, and firm-wide templates that contain the sections and tables to be filled out along with detailed prompts that are fed directly to the writing agent.
• Sections stream in as the pipeline produces them, and the analyst edits in place.
• Every AI-written claim shows its source inline, click it and the document opens to the cited page.
• Agents can perform all kinds of tasks on behalf of the analysts - finding property websites, extracting images from OMs, generating custom maps, etc.
• Chat agents can update sections with user approval before overwrites.

A generated memo. Every underlined claim links back to the document it came from.

The map. While it may seem surprising, many firms have no way of seeing their portfolio by geography. Our map is where a firm sees its whole portfolio and pipeline at once, everything closed, in progress, or passed.

• Every deal is plotted by geography, colored by status or property type, and filtered by the numbers that decide a screen, e.g. loan size, LTV, debt yield.
• Concentration is visible on sight. All deals in the same submarket sit next to each other.
• Additional data layers, like storm data and Census economic data, allow for easy multi-dimensional analysis.

The whole book on a map, closed deals, live pipeline, and passes, with the portfolio’s concentration visible at a glance.

The buy box. Each fund has a buy box - quantitative and qualitative criteria that determine if a deal is worth a look. While not always strictly defined, we encode their criteria and rate each deal against it.

• Every incoming deal is scored in or out of the box, metric by metric, with a compliance rate for each.
• The goal is to have deal triage using the right metrics. Today many funds look at the deals they have time for while others sail by.
• It’s the difference between fishing with a rod in a river and deploying a net to see everything swimming by.

Agents and the human in the loop. Agents sit over all surfaces, but for our high value financial context, we built three kinds of action and consent.

• A read is answered straight from the deal’s own documents, only limited to the user’s permissions (say by organization and team).
• A mutation is proposed rather than automatically executed. The agent shows a field-level diff, current against proposed, and waits for approval before it touches anything.
• A longer piece of research runs as a sub-agent the analyst can watch and stop mid-run.
• An agent gets more latitude the more legible its actions are.

The in-app agent, answering from a deal’s own documents and proposing changes the analyst approves before anything is written.

What came of it

Thousands of deals have run through the system, funds with billions under management have paid for it with more lined up to come on.

The transparency layer under the product was always the feature that excited buyers the most. Every fact keeps its provenance and every entity keeps its edges.