Why We Rebuilt Microsoft Office From Scratch for AI Agents - Yijia Liang, Compound AI

[music] >> I was previously an analyst in a previous life. I was a vice president at Coatue for about 3 years specializing in late stage private software investments. Spent way too much time in Excel, PowerPoint, and late nights doing that type of work and so decided to split and start building tools to replace my old job. Quick show of hands, how many people in here have used Muser Instinct in the last day? All right, I expected more hands, but uh maybe people are too shy to raise them. And how many people know an analyst in finance that fully delegates their work to AI, like fully hands-off running autonomously? All right, one. But a lot fewer. I think if you think about the question, why did personal agents take off within the last 3 months? Internally, we came up with three main answers.

The first, reliable background agents. You can delegate a task, book a restaurant, book a flight, and it'll do it reliably now. Computer use agents have gotten sophisticated. The models themselves have gotten better. The second is proactivity. It'll do things without you asking. It's part of that magical experience when Instinct wakes you up saying it's your wife's anniversary, go buy some flowers, or better yet, I already bought the flowers for you. And finally, integrations. It's connected to the systems of context that matter most for you. Email, drive, calendar. But all the factors that make personal agents work so well doesn't really translate to institutional finance today. If we think about background tasks, something as simple as booking a restaurant reservation, the analog equivalent in buy-side finance might be how do you go from a data room to a fully prepared set of IC models, slides, and memos, taking a process that would normally take 4 weeks, multiple rounds of iteration and review, and compressing that to a few days.

If we think about proactivity, your managing director doesn't really want agent rogue running around doing a bunch of things and burning tokens without them providing and soliciting input. And then finally, if you think about the context that matters, it's not just email, it's not just calendar, it could be a data room with 15,000 files, it could be SharePoint box with petabytes of unstructured data a firm has collected in its 40-year history. So, how do you deal with these problems? So, the purpose of today's talk is to discuss a bit more about how we at Compound have approached the problem of solving long-running agents in finance. On one hand, it's creating a real teammate that collaborates with you and the deal team. So, that's multiplayer embedding that into the app. On the other hand, it's solving for how you can you run long tasks in parallel in the background, reliably execute them. And so, for that, we actually rebuilt Office from scratch. And then finally, it's how do you manage the context of everything, everything we just discussed, petabytes of data in SharePoint and Box. And we'll talk a little bit about how we've designed a solution for that.

So, the first question we have to ask, I think, is why does multiplayer actually matter for finance? If you look at the anatomy on a deal team, right, the type of tasks that matter for long-running type of workflows, for example, going from a data room into all the sorts of materials that make its way in front of an investment committee, it doesn't work for the single-player siloed workflows. Today, for people who have deployed Claude or ChatGPT in their institutions, it's all single player. People working in a plugin, people working in the web app, producing outputs, but invariably, those people need to collaborate with their team. And what does that look like? It means downloading the file, uploading it into email, uploading it to Teams, asking for feedback. I think the right way to approach this, and this is the way we've thought about at Compound, is how do you get every person who matters on a deal onto the same thread? How can they all talk to the same agent so that one agent can share the context of everyone who matters for any particular work stream? When we thought about how do we actually bring multiplayer into a familiar context, we looked again towards personal agents. Why did they work so well? Well, you can easily text one in iMessage or you can text one in WhatsApp.

So for agents at Compound, every single one you create comes with a built-in inbox. Because ultimately at the end of the day for institutional finance, most workflows run through Outlook. You'll have chains of emails 20 or more running. You want an agent to be part of every single one of those conversations. Designing email for agents is actually non-trivial. It's not just as simple as hooking it up with an email inbox. It requires A, authenticating, making sure everyone part of that thread has read and write access to that agent. Ultimately at these financial firms, privacy is incredibly important. You're always under NDA no matter what deal you look at. And so you want to make sure everyone on that thread can actually talk to the agent. But then beyond authentication, you also have to think about how do you design a real human-like experience? Because after all, we're trying to create a real teammate. If multiple people email in the same thread in quick succession, you don't want multiple acknowledgements spamming that group. You actually want to bake in some more latency to make it feel more human. And so there are other design decisions when thinking about how to create real email agents for enterprise finance.

But multiplayer aside, we realized even after you solicit the input of everyone who matters, if you wanted to scale up the number of tasks and run them all in parallel, existing off-the-shelf solutions simply don't cut it. We evaluated a lot. The desktop plugins of Excel, PowerPoint, and Word. We evaluated computer use using virtual machines to try to scale up the number of agents that could work in Excel, PowerPoint, and Word natively. And we also evaluated a ton of off-the-shelf engines, whether those are open-source packages like Open PyExcel or commercial engines that are available for purchase. None of them really cut it for what we were trying to look at. And with coding agents dramatically improving and bring the cost of software down, we decided to just build our own office from scratch. And like a great AI engineer would, we ran agents in many loops, spend 1.5 trillion input-output tokens and over 8 million lines of code to rewrite office from scratch. And I'll walk through a little bit of how we approached it.

But it's as simple as pointing agents at an objective function, which is recreate office in full fidelity, and then letting it run. So, take Excel as an example. We started with an open-source solution called Iron Calc. We decided, "Okay, how can you recreate this perfectly for Excel, use office as an oracle, and just run loops?" Benchmarking it on real files from both real-world corpus that we grabbed online, and also ones that internally we created. And 800,000 lines of Rust later, we had a performant much more performant compared to Excel, one-for-one replica of the product. With this, we're actually able to do that for not only Excel, but also PowerPoint and Word. Right? So, we ran loops across every single one of these products, and we have faithful recreations. You can try it for yourself today at the compound.ai. And it's the same method, loop agents against office as a judge. Using Rust renders to make sure that the rendering of these products was pixel perfect. So, what you see in Compound is what you see when you download to office. We needed one-for-one parity because at the end of the day, these firms only trust what they can download and they what they can send.

Now, let's talk about performance. Why is a headless engine so much better compared to using a VM or using desktop Excel? Well, for one, desktop Excel or PowerPoint or Word is bound to that CPU. With headless engines, you can do tasks in parallel much, much faster. You can build out a complex model in a much shorter amount of time. You can recalculate 20 MB Excels 4x faster. So, every single piece of work of an analyst would expect an agent to do cuz again, their expectation is quality of the human at much lower speed and much lower cost. You have to have a headless engine to do this. If you try to scale this up with Excel and PowerPoint, I think you'd be going down the wrong path. But, it's not just about performance. Owning the editor actually allows you to create a much richer product experience that allows you to work and collaborate with agents asynchronously much better than you can with other products. So, this entire slide deck you're seeing today, I built in Compound just by dropping in comments. I had it create a first draft, and then as you can see here on the UI, I dropped in comments for every single piece of formatting. From my consulting days, from my Coatue days, all the learnings I had on what makes a great slide, I imparted with the agent.

This can also work for multiplayer. You can have multiple people part of the same team using the same multiplayer infrastructure we set up, dropping in comments. So, for a team of five, you can rip through a 100-page deck in an afternoon rather than sitting in a room revising it for multiple weeks. Finally, with respect to building your own engine, it also allows us to run iterative checking loops much more as well. So, if you have a task that, for example, is writing a complex model, it might take a few hours. But, how do you How can we make that faster? How can we make it more accurate? If you're using, for example, an OpenPyXL code library, there's no render you can use to check formatting. You're just guessing and hoping that the model writes the right thing, and maybe you do some parsing to see a cell has a particular color, has a particular font. If you try to use Microsoft's own interface, you're going to be limited by what Microsoft provides you, which is admittedly very little. So, with an own engine, you actually own the write, render, check, and fix loop. So, you can rapidly iterate on the output for the user.

So, the last thing I sort of want to discuss today beyond multiplayer and building our own office is how to deal with the context that these firms have. For firms on the buy side, they deal with situations where cross is both breadth and depth of data. You may have situations where you have a data room of over 15,000 files, and then files in that data room might be well over 20 megabytes. People in finance complain all the time, "Hey, I have an Excel model that's 30 megabytes. It takes 5 minutes to recalculate because we have 2 million formulas and five sensitivity tables that need to recalculate every single time." So, how do you deal with this? Well, for breadth, I think again we take a look at a page out of the coding book and apply agent swarms to the large number of files. No longer do you have to index everything in a vector DB unless it's for it's for a very specific use case. It's actually much preferable to use coding agents to read files either through grep or through some other methodology, and then have a lead agent slice the contents of the file directory, and then have swarms of agents come back to you with insights.

And then you iterate that in a loop until you're satisfied with the output required. Furthermore, through this process you're actually able to ground every single finding inside citations in the source document, so that you know exactly what you show on the screen is linked to some number that the analyst can trust. If we think about the depth of data, right? Take that 30 megabyte workbook. How can you actually process this more accurately? In today's world, if you were to just use ChatGPT or Claude off the shelf to process that 30 megabyte model, it would write code, it would use open-source packages like openpyxl. It would be expensive and slow because it's printing out every single piece of context about that model in code for the model to read. But because we've developed our own engine for Excel, we're actually not only more accurate, but a lot faster and cheaper because the engine processes it and then lays it out in a very easy-to-read and easy-to-process format for the model. This means we can expose a much richer set of APIs and a much richer set of tools for the agent to work over. And that allows us to process these models in a much faster manner.

So, if we sort of take a step back and think about, "Okay, what is all of this context built for?" At the end of the day, what we want to do is prevent people from spending time finding files, from reminding the model this is how to do things. Instead, they should be focused on importing their judgment on the deal process. They should be focused on tailoring, training agents, and deploying them on every part of the deal flow. And so, it goes from the bottom level, connected sources, off-the-shelf, you know, connectors to SharePoint or Outlook, to the cited findings grounded in the sources that matter. And then finally, embedding in the preferences, company knowledge that matters. How do you do it, model? How should it look? Which differs by every single firm. So, that for humans, they spend most of their time imparting judgment. They spend most of their time thinking about is this actually good deal? Not did all the numbers tie? Does the model look right? Will my VP yell at me because it looks different way? So, Oh.

Cursor needs to update. If we take a step back and think about the type of tasks that currently are on autopilot um versus what are on copilot, I would say there's already several finance tasks you can do pretty well with off-the-shelf tools. Spreading comps, as the ChatGPT head of finance mentioned earlier, they have now their own products for this. But I think there are a lot of longer running tasks that are not capable with existing solutions. How do you draft a 50-page IC presentation off the cuff? How do you get agents to build out a model exactly the way you want it for a private equity professional or a hedge fund professional? I think those are tasks that with off-the-shelf tools still exist as co- as sort of within the copilot realm. People want to be embedded deeply in that process without letting go. But with some of the tools we've built today, I think we're able to expand the aperture for which autopilot can take over in finance firms. So, rather than just using tools embedded in Excel as plugins, hand-holding along the way, you can start delegating. You can start becoming more ambitious about what AI is capable of. If I think about where we are today in the world of finance, it very much reminds me of when Opus 4.5 launched last December, where people stopped using code as a simple co-pilot to generate the next file or the next line of code, but they started delegating far more ambitious tasks.

They started realizing, maybe I can just truly vibe it. If I have sufficient checks, if I have sufficient tests, maybe I can just trust all the code it writes. I think with some of the tooling we've built today, along with what we're planning in the future, these are the type of problems you have to solve before you get to that point for finance. How can analysts, how can the entire deal team become more ambitious with AI? How can they just drop in a data room and decide, okay, I'm going to trust every single one of the outputs, and then let's do that tenfold so we can see more deals, so we can expand the aperture of what matters. So, to conclude, enterprise agents are certainly coming to finance. I strongly believe we're at an inflection point in the adoption curve, and that people are slowly becoming more ambitious, and they're moving away from co-pilots to auto-pilots. And so, this was sort of how we've approached it here at Compound. If you work at a firm and you're interested in deploying our agents to drive more of your deal work, please reach out. Or if you're engineer and you're curious about talking about our approach and sharing ideas, please either reach out online or I'll be around if you want to find me. Thanks so much.