Yijia Liang on Building Office-Compatible Engines for Finance Agents

I spent about three years as a vice president at Coatue focused on late-stage private software investments. A great deal of that work meant late nights in Excel and PowerPoint. I left to build tools for the work I used to do, and today I want to explain how Compound approaches long-running agents in finance.

We see three reasons personal agents have become more useful: background work is more reliable, agents can act proactively, and they can connect to important context such as email, calendars and drives. But the same factors look different inside an institutional finance workflow.

A restaurant reservation is not equivalent to turning a data room into the models, slides and memos for an investment committee. The latter may involve weeks of work and several rounds of review. A managing director may not want an agent acting without input, while the relevant context can include thousands of files and years of firm records.

Our approach has three parts: make the agent a collaborator shared by the deal team, run long tasks in parallel using our own document engines, and manage the breadth and depth of the firm's data. Each addresses a different obstacle to delegating more substantial work.

A deal team is not a single user. Analysts working separately in a chat or plugin still have to pass files through email or Teams and ask colleagues for feedback. We want everyone involved in a workstream to participate in the same thread, so an agent can receive relevant input from the people working on the deal.

At Compound, each agent has an inbox, reflecting how much institutional-finance work happens in Outlook threads. Giving an agent email is more than attaching a mailbox: the system needs to authenticate participants and ensure they have appropriate access, especially when deal information is covered by confidentiality agreements.

We also considered interaction details. If several people write in quick succession, separate acknowledgements can spam the entire thread. Introducing some delay before responding is one design choice intended to make the agent behave more like a teammate in an existing conversation.

Collaboration alone does not solve parallel execution. We evaluated desktop plugins, virtual machines controlling Office applications and existing open-source or commercial engines. In our assessment, they did not meet the combination of fidelity and scale we wanted, so we decided to build our own Office-compatible engines.

I estimate that the build used 1.5 trillion input and output tokens and produced more than eight million lines of code. Our method was to give coding agents a fidelity target, compare their work against Office and repeat the loop. Those figures describe our project; they do not by themselves establish that every Office feature is reproduced.

For the spreadsheet engine, we began with the open-source IronCalc project and tested against files gathered online as well as examples created internally. I describe the result as a highly faithful replica, but compatibility and speed depend on the particular files and functions being tested.

We applied a similar comparison loop to presentations and documents. Rendering is central: a file has to look right in our editor and after a team downloads it into Office. Financial firms need artifacts they can inspect and send, so visual and file compatibility matter alongside the agent's ability to generate content.

I argue that a headless engine can execute work in parallel without tying every agent to a desktop application in a virtual machine. In our testing, we observed a fourfold recalculation speedup for 20 MB spreadsheets. That is a workload-specific company claim, not a general benchmark for every spreadsheet.

Owning the editor also changes collaboration. I created this presentation by asking the agent for a draft and adding comments about formatting. Multiple deal-team members can add their own comments through the shared interface, allowing the agent to incorporate feedback asynchronously.

Our engine gives the agent a write, render, check and fix loop. If a code library can edit spreadsheet cells but cannot render the result, a system has fewer direct ways to inspect formatting. By controlling rendering, we can let the agent inspect its output and iterate before handing it to a person.

The data problem has both breadth and depth. A data room may contain more than 15,000 files, while a single workbook can be tens of megabytes and contain large numbers of formulas. The challenge is not just finding a document, but interpreting the details inside it.

For breadth, we use a lead agent to divide the file space and send work to multiple agents, then iterate on their findings. I favor direct file-reading approaches for this workflow, using search or other methods, while recognizing that a vector database can still be useful for a specific purpose.

We want findings to carry citations to their source documents. A citation gives an analyst a route back to the evidence behind a number or statement; it still needs to be reviewed in context rather than treated as an automatic guarantee of correctness.

For depth, our spreadsheet engine processes the workbook and exposes structured information and tools to the model. I claim this can be faster and cheaper than having an off-the-shelf model repeatedly print and inspect large amounts of workbook context in code. The comparison depends on the task and implementation.

The goal is to spend less time finding files or repeatedly explaining formatting preferences, and more time applying judgment to a deal. The workflow connects sources such as SharePoint and Outlook, grounds findings in citations and incorporates firm-specific knowledge and preferences.

I distinguish tasks that can already be automated with existing tools from longer, more consequential work where people still want to stay involved. Building a detailed investment-committee presentation or a firm-specific model requires careful review and control; our ambition is to expand what can be delegated without discarding that judgment.

The analogy I draw is the shift in coding from accepting individual suggestions to delegating more ambitious tasks when checks are available. For finance, that shift requires reliable tools, evidence and appropriate human oversight. My broader prediction is that firms will experiment with moving some workflows from copilot toward more autonomous operation.