Raw capture — raw/ramp-lessons-building-ai-product.md
url: https://www.youtube.com/watch?v=NMs8C2_3M0w date_fetched: 2026-09-22
Speaker A: Foreign.
Speaker B: Today we're going to talk about AI at Ramp and I'm going to give an introduction, quick introduction into what RAMP is really briefly. We're going to walk through the simplest possible expense use case that you guys can all resonate because I see everybody's drinking coffee. And then we're going to talk quickly about a lesson that we learned this year while we were building gazillion agents and sort of the pivot in the paradigm that's happening, especially after February 6th. And then we're going to double click onto how we built one of our most popular agents, the policy agent. And then finally we'll dig in into the infrastructure build that this is requiring to do on our side and in my mind, most importantly, the culture shift that needs to happen on everyone's teams in order to be able to operate in a way that delivers products into the hands of your customers in the fastest and most impactful way. So without further ado, quick intro about ramp. We are number one finance platform for modern businesses with 50,000 plus customers and we're in the business of saving you time and money. We have, I've seen some of the, some of those names on the name tags here. So thank you for being RIM customers. Really exciting, really cool.
Speaker A: Quickly.
Speaker B: So cup coffee takes usually about 15 minutes of your time because you got to do these three simple things which unfortunately take minutes. This compounds through the company and what TRAM does in the simplest possible way, we just condense time and return money back. So a simple story of a transaction, from tapping the cart to writing a memo, to classifying the transaction according to your gl, to sourcing the receipt, attaching the receipt, normalizing the merchant to your inventory of merchants is all done agentically at Ramp. And this was our first foray. Probably by now. You guys still here? Yeah, probably by now. About three years ago, we started doing this one shot things with AI. We normalize merchant, write a memo, and it's been working really, really well. As the models get better, what else is going on at the company? Well, literally every Persona at the company is wasting time on a lot of manual work. So from AP clerks to your finance team, from your purchasing teams, keep going to more finance work, your data teams. At Ramp, we used to have a channel called HelpData where somebody will ask for a CS and a poor person will go and write a SQL query. We replaced it about a year and a half ago. So a lot of time being spent and the complexity has a RAMP shape. It only increases as you go through different Jobs to be done. So if you guys watch superball, you might be familiar with Brian, our agent. So we've been writing a lot of agents literally for every job to be done to cover the entirety in the end state the entirety of what admins, employees and finance teams are doing that is not directly related to making the money. We want you all to be making money and focus on your customers, not on how to close the books. But what's been happening for the past few weeks is that we're living through the most exciting paradigm shift in software and it requires complete rethink and with rethink, simplification of your stack. So what we learned is you don't need to build a thousand agents. We intentionally last year allowed each individual team to go and experiment and we ended up maybe with four different ways of doing the same thing, both for synchronous agents as well as for background agents. But instead you want to drive your framework towards a single agent with a thousand skills. So let's talk about what the software traditionally used to focus on. So every process, especially in the modern AI stack, boils down to having an event. So a tramp, you can receive an invoice and you want to pay it, some prompt instructions of what you want to do with it and some guardrails like a policy, like an expense policy or your payables policy. Context, what is the data that the agent should consider? And then finally tools. These are APIs and actions that you can do. And traditionally software would focus on only 4 and 5. In the new paradigm, software is doing everything. So you want to focus on building an autonomous system of action that can react, reason and act without a human or with very little human supervision. So what does it mean in terms of what we're building? First we decided we go into consolidate the interactions, verbal interactions with the agents to a single conversational ux. Well, literally at the end of last year we had about five different conversational UXs. We now have consolidated it into what we call an omnichat Omni, meaning for omnipresent. It is now being deployed to every surface of the product and it works well with the traditional UX because you still need tables and buttons and you don't always want to be talking to your software. But this is a good example of what OmniChat looks like. Please onboard a new employee. OmniChat can resolve an employee to an employee ID and look up through an HRIS tool their corporate structure. And and it found a workflow, a gentic workflow that we Created previously called the new hire playbook. And the agent is asking would you like me to onboard the person using this playbook? How is this possible? We built a in house lightweight agent framework that provides orchestration with tools that engineers are very quickly building. And most recently we have one product manager, vibe coded about 20 tools so engineers are no longer needed to build those tools. And sometimes your workflows are involved such as employee onboarding consists of four steps so you can just go on ramp and describe what do you want to happen When a new employee joins, Give them a card, make sure they get receipts for every transaction, congratulate them on Slack and check in with them in two weeks. We now are able to compile this into a runnable deterministic workflow and then give it to the agent to execute playbooks, make use of tools and how this all comes together. This is an example which viral is going to double click next is upon swiping the card, there's a real time policy review that's happening directly in the software and Policy Agent enforces your company requirements with regard to spend. Therefore it's very safe to give ramp cards to literally every employee in your company. And there's a handoff happening with an account in code. An agent that classifies this transaction applies the rules of your back office team, of your finance team as an employer. Have no idea how certain transactions should match to our GL and that's what typical traditional products would do. They will expose it to you. So the agent is much better at doing it because it has the full context of your chart of accounts, it understands your ERP and then it can either auto approve or in the worst case scenario it will involve the human in the loop to review materiality or notify that there is an out of policy spend. With that, please welcome Veral who will dive deeper into the Policy Agent.
Speaker A: Thanks Nick.
Speaker C: Awesome. So a lot of finance teams are looking at receipts like this basically every day and maybe they might have hundreds or thousands of these. If you told me to look at this and decide if I should approve or reject this transaction, I'm probably going to make a mistake. So Policy Agent basically reasons on this image and all the transaction data that we have and told me that there were eight guests in the receipt, I could barely see that when I was looking at it. It was below the $80 a person cap that we have internally. They were going for team welcome dinner. And so because the amount was verified as well and the merchant policy agent told me to approve this transaction similarly for this OpenAI transaction, Anand was testing out some ChatGPT features. And so Policy Agent told me this was a valid business expense and told me to approve it. And then this $3 bakery charge was rejected because it wasn't part of an overtime purchase and it didn't happen on the weekend. So really we looked at this as an opportunity to rethink how Ramp was set up. Controllers and finance teams are looking at transactions like these and making these decisions every day. And a Fortune 500 company, that is one of our customers, was coming to us and saying, hey, can you make sure that you approve these types of expenses and reject these types of expenses? And they basically had a list of all the rules that Ramp should follow. And we kind of saw this as an opportunity not to kind of add more incremental, deterministic rules that kind of defined our product. And I worked on some of the first versions of these, but actually kind of take out a page from Andrej Karpathy saying that English is the new programming language and kind of turn the expense policy into the rules themselves. So you can, you can see Ramp's expense policy on the left. And this is a screenshot from our production environment. But we are seeing really great use out of our Policy Agent product. And it kind of needed to start. It kind of needed to start really organically. So we kind of operated like a early stage startup. We're already very incremental and fast at Ramp, but we found some design partners like that Fortune 500 company. We iterated really quickly and we had weekly meetings with all of them to kind of understand exactly what feedback we wanted to hear and what we could improve. I think one of the main important, I guess, things that we realize across Ramp is that we really needed to lean into the fact that AI products cannot be one shotted. You need to start with something simple. And so as long as everyone on your team, PMs, designers, engineers, are aligned, that you're not going to have perfection on day one. I think that was actually one of the main cultural learnings. And so we dogfooded a lot of this work internally and started with an even more constrained problem of trying to decide whether our coffee with a colleague transaction should be approved or rejected. These are single dollar amount transactions that are low risk according to our finance team. And so we started with these transactions. And one of the early learnings, especially as we kind of released this into production, was that a lot of the reason that Policy Agent would be wrong would be less on the models themselves and more about the context that we were giving to LLMs themselves. So we could have sat down and thought about all the context in the beginning, before we even kicked off any engineering work, but realize actually the best thing would be to learn from some of our live internal data. And so, for example, we learned that the role and the title of an employee is super important when looking at expense policy docs. Certain levels, C suite, for example, might have higher limits. Maybe they can fly on first class for certain flights. And so we started extracting more information from receipts, started pulling in information from HRS fields that are already on ramp. And so will is going to kind of talk you through exactly the iterations that we went through to implement policy agent and some of the learnings along the way.
Speaker A: Yeah.
Speaker D: All right, cool. Awesome. So when we first started building the policy agent internally, we dreamed, we went big. We're like, hey, let's automate all the finance, let's automate all reviews. But when it came down to it, we actually had to start small. Is that cup of coffee, you know, in your expense policy? And the reason that we did that was because even though the problem sounds simple to automate, you know, is this a simple question? Is this in policy or not? It was going to grow to be complex, kind of like Vero said. We could have gone down and we could have figured out, what context do we have, how can we add it, how can we put it all together in a way that LM can understand and, you know, put it all together from the get go. But we knew that even if we aimed and got everything right the first time, it was probably going to be wrong once you applied and generalized it and went to another business. So the simpler the system, I think, the easier it is to iterate on top of it. And once you iterate, you know what's going to work, you know what's not, and you can kind of layer complexity on top of that. And I think that's pretty important to keep in mind when you're building a LLM or an agent starter. So for us, we started really simple, very, very kind of the classic. We have an expense come in, retrieve the context around it, we pass it through a series of LLM calls that are very well defined of like, hey, is this in policy? Why is it in policy? How can we show the user that's in policy and then give an output that makes sense and display to the user? Eventually we learned that each expense is kind of different. We can classify an expense based on, is it travel, is it a meal? Is it entertainment? Do conditional prompting and then retrieve context based on that and then pass it to a series LLM calls and give it some tools so that you can also autonomously decide hey, I need flight information actually or I need this employee's level and kind of layer that on top. And a few iterations later we came to a full on agentic workflow. We ended up with complex tools to read across all of our platform and these tools are shared across all of our agents. It's not just for policy agent. We have a company internal toolbox that all of our agents are easily can reach into and use. And we gave it the capability to write as well. So it's now writing decisions, it's writing reasoning, it's writing auto approving expenses on users behalf and it goes in a loop. So now it's more of a black box. And that's kind of the trade off you get as you go from simple to complex systems. Your capability goes up, your autonomy goes up, your agents are able to do more, your AI can do more, your AI seems smarter, but in exchange you're going to be able to. You're losing traceability and explainability. We look at it now, we can kind of look at the reasoning tokens that the LLM gives us. But in the end we have no control over it. It's going to do what it thinks it's right, it's going to make the tool calls, it's going to tell you it's right or wrong. So a smaller black box becomes a bigger black box as the system becomes more complex. So one thing that is really important when doing something like this is from the beginning you need really good auditability. Assume, even if you know how it works, assume that your inputs and outputs are all you know and make sure that it's correct. So if it was a black box system and you only saw the input output, can you verify that it did the right thing? And even if that black box changes, you should be able to reason about whether the output is correct. As with many products that we built at ramp and across, you know, other companies, we thought that the users would be correct. You know, if the user says approve, the agent should approve. If the user says reject, the agent should reject. But turns out the users are actually incorrect. They're wrong. They are. Sometimes they don't know the expense policy, they trust their employees, they're lazy. It's a Sunday, who knows? Turns out we can't always do what the users are doing because sometimes that's where finance teams come back to you and are like, hey, this is wrong. This shouldn't be on the company card. So we have to define our own definition of correctness. And to do that we had a weekly labeling session with across functions that are working on this product. And that had two kind of really good outcomes. One was that we had a ground truth data set that we could always test against and we knew that this was correct. And two was that everyone was on the same page. If our agent got something wrong, everyone knew that it got it wrong. Or our agent is missing context, everyone knew that it's missing that context. So there was less communication. Everyone's on the same page and they could focus on what's really priority and kind of have alignment on that. Initially, getting all those people together in the room every week giving their homework to label 100 data points, it's expensive, you know that everyone, everyone has things to do. Sometimes they don't come back with their homework done. It's just kind of like almost becomes tedious, even though it's so important. So we wanted to make it as simple as possible. And the way we did that was that we looked for third party vendors that could provide us the tools to label data and collect the data. But turns out some tools are too specific to a use case, some tools are too general. And we could have spent weeks trying out different tools, but we decided let's just build our own. So we used clock code using streamlit. We basically one shot it all of this. And the greatest part of it all is that it's low maintenance, low risk. It's in a part of the code base that if it breaks, we can fix it right away. Deploys happen in instant seconds. And non engineers can go and personalize it, they can vive code it, they can clock code. And this was at Opus 4. So now at Opus 4.6 I expect it's even better. And with something like that, it's definitely easier and cheaper sometimes to do something one off like this. And with that with the ground truth data set, we were able to make quick iterations. We were able to find out, hey, we need employee levels. Add that. How does that work? Run it against this data set? Does it actually catch it and now say accept or approve and we're able to make really quick iterations. And that was kind of the key, that was actually kind of a key point in developing this. We had really early confidence that this could actually work. And we were able to actually get a lot of buy in, get a lot of customers onboarded and try it out as a design partner. And as part of doing that iteration with the data set, you had evals and I feel like evals, obviously everyone I think in this room now knows about evals and what they mean, but it's pretty important to have them early on. I wouldn't say that. Don't let perfectionism get in the way. You don't need a full Data set of 1000 data points. So you're testing against every iteration. We started with five and we knew that those five we're not going to fail. We kept adding and adding and adding and make sure it's easy to run. Anyone could go and just run that command and then make sure that the results are really easy to understand. They are able to look at it, get instant output and understand, hey, this is what the model's doing, this is good, this is bad. And if you want it as part of your CI, then everyone now can safely merging code. Because whenever you think you're doing something right for the LLMs or agent, giving more context, giving you tools more likely than that, it's probably going to have some kind of bad consequence that you didn't see happening. Context rot, whether it be the tool instructions are wrong or maybe the docstring was a little confusing and conflicting. So it might have consequences. You just want to make sure you're catching against those and then I'll touch on it briefly. But online evals are also great. So these are offline. You have a data set, it's historical, you're testing it. But if you can, online evos can be a little more confusing and harder to kind of measure. But if you can measure anything that as your users are interacting with the system, definitely as a leading metric, I'll set them up. And for us part of that was hey, how many are rates of decisions. We had an unsure decision, which just meant that the agent didn't have enough information. So we can measure that online. It's much simple eval, but that also gave us a pretty good health check as our system was running. Cool. Another great part about evals is that with evals you can make confident model changes whenever a new model comes out. Opus 4.6 GPT 5.3. You want to make sure that you can leverage those new models because sometimes that could mean the difference between your system getting one part of the problem right to wrong, but it could also mean the opposite. It could actually be not good without any prompt changes or changing how your system works. So having eval really set up and Being at the benchmark really helps make confident model changes. Cool. So now that policy agent, we've been developing this for a while. It's available for everyone on the RAM platform. Some of the things that we learned along the way is that cloud code as engineers is very exciting. We have full control. We get to modify our cloud md, we get to make sure tell it to not leave comments. It won't leave comments, hopefully. Turns out it's not just us. Finance people also really like to have modified their cloud md, which is their expense policy. So if something went wrong with the decision, then we just tell them, hey, go update your policy doc. Which to them it's a little scary concept to begin. Like, this is a document. You don't mess with that. You have to go through a lot of hoops if you want to mess with that. But it turns out if you get really excited about the feedback loop, hey, change that. You'll see it right away. Turns out that we really excited to do this then. Trust builds over time. Some of the earlier customers that we had were some of the Fortune 500s. We actually started with a really big enterprise customers that we had because we thought that they would have the most value. They have the most expenses coming in. They have the most time spent on reviewing coffee expenses. So roll it out to them, let them have the trust. We didn't do any autonomous action. We're just like, hey, we're going to give you a suggestion. That's kind of how he phrased it, suggestions. And eventually they came to us and we're like, okay, you know what? I want to go from suggestions to auto approvals, like anything under $20. You guys are mostly right. I don't care about this. Let me just go auto approve it. So we gave them the autonomy slider. We gave them a way to just turn it on and then they actually could do it themselves. And then last but not least, similar to LLMs, users thrive in product feedback loops. So when you're building an AI product and you have a full way of LLMs can test if its code was right. And so to iterate users are the same way. Give them in product ways to improve their expense policy doc, improve the agent and how it operates, and they're more than excited to kind of take it over themselves and kind of improve it and personalize it for them. So from here I'll pass it on to Ian, who's going to kind of talk about the infrastructure and the culture that we have at Ramp that kind of led us to building the policy agent.
Speaker A: Hey everybody. So you've heard a little bit about how we're kind of getting leverage to all of the different finance teams as we operate on top of their financial infrastructure and really try to get leverage for our customers. But I think a big thing that we also spend a lot of time thinking about is how can we get leverage for Ramp itself. The engineers, our XFN orgs, all the people that we work with every single day. And this slide is, this section is pretty intentionally named AI Infrastructure and Culture because we think that this is both like a really challenging infrastructure problem, but it's also really challenging culture problem. And changing how you work as well is a big part of the story. And so to kind of start on the infrastructure side, the core of how most of applied AI happens at ramp is our applied AI service. And at like a 10,000 foot view, this looks something kind of like an LLM proxy or something like light LLM. But there's really three kind of main extensions that we've invested in to make this a lot more powerful for a lot of our use cases. The first is like structured output and consistent API and SDKs across different model providers. This can be pretty tricky to do, especially with how quickly the APIs are changing, but it's a problem that we don't want downstream product teams to have to think about. So if you have an idea of I want to switch from GPT 5.3 to Opus or I want to try Gemini 3 Pro, you should be able to do that with a config change and really quickly be able to iterate on semantic similarity and trying to do a bunch of different code sandboxing and structured output calls that way. The other thing that we've spent a ton of time thinking about is kind of batch processing and workflow handling. This is really useful for evals or if you're doing for us, bulk document or data analysis. And that's something that we also don't want teams to have to spend a bunch of time on. Of how do you want to batch this and handle it with rate limits? And do we want to do this on an offline or online job with something like anthropic? We just want to handle that for downstream consumers so they can just focus on providing value for downstream customers. Then the last, which is a pretty big deal, is the ability to trace different costs across teams and against products as well. And this allows us to kind of identify the paradox curve of what is the best model performance for cost. How are these evolving over time? What teams are actually not building something that's going to be sustainable long term for different product services. This can be really, really important to just remove all this work from internal teams. Having to think about this, the last thing that's I think funny to think about, we often joke about that our customers are actually using more of a frontier model than they may even know even is out yet is it allows us to stay at the frontier when a new model comes out. It's a one line config change that impacts every single SDK downstream. And so rather than teams having to learn the SDK or go into 12 or dozens of different call sites, they can just change it in one place for their specific team. And they now get the benefit of being on the latest and greatest models that we've kind of vetted and built into the rest of the system. Our product, as you've heard earlier, works on a lot of very sensitive data and very sensitive workflows. I think oftentimes something that I hear from engineers in the space is this concept of hallucination and safety and how are you actually going to be able to produce a lot of these things to have benefits to downstream finance teams? We're pretty big believers that it all comes down to the catalog of tools that teams are building and integrating with on a daily basis. So what you're seeing here is our internal tool catalog. So an example would be like get a policy snippet or per diem rate or recent transactions. And these are built alongside of product teams to really understand a lot of the nuances in the data and the use case. And what's really cool about this is not only can you see where there's gaps in our offering that, oh, we actually don't have a tool for this specific use case. These can be used both in internal repos and our core product. And so if you have an idea of I want to do a cool reimbursement agent idea, here are the different ways to integrate the tools, the different APIs and systems that they integrate with. And now you can prototype that on a totally new product and vibe coded surface area without having to worry about like learning all of these things from scratch or building the tools on your own. We're up to like many hundreds of these tools today and we, as Nick mentioned earlier, thinks that this could be like multiple thousands over time. On the topic of context, another big thing we think about is context for our customers of how do we actually integrate the financial stack and allow them to be a lot more productive, but we noticed like a very similar problem internally on our engineering team. And I think something that's like, not as always obvious is that, you know, even if you're using something like cloud code or Codex, there's all this fragmentation of actually what you do on a daily basis to get work done in your company that that's not integrated to. There's logs in Datadog, there's a production database that has a bunch of things going on, there's different alerting systems, there's incident IO, there's a slack message you have to pull in, there's a notion doc, and then there's a lot of knowledge that those actual specific product teams have of how they actually need to get work done as well. At the end of last year, we decided to start out and try to solve this problem of how can we actually integrate all this context and build our own internal background coding agent, which we've called Ramp Inspect. You may have seen this on LinkedIn or X. We actually have open source, the blueprint of how we've built this. And at the end I can definitely show you guys a link of where to find that. The progress has been pretty phenomenal of actually integrating this into a background agent that can run autonomously as people are in meetings, as bug fixes come up and things like that. Currently this month, Ramp Inspect is responsible for over 50% of PRs that we merged to production. I have some interesting. We're really big nerds with stats and numbers and things like that. So we have this dashboard to create this interesting one. So subtle, healthy competition, but also inspire people that they can actually use this as well. And as you can see, engineering has a huge lead of the amount of sessions. But you also have product, you also have design. There's risk, legal, corporate finance and even marketing and CX teams using Ramp Inspect. And they're doing things like simple copy changes, they're doing logic fixes, they're trying to respond to incidents or bugs. And what's been really cool to see as this has evolved over time is how we've actually designed a couple of these things with some core principles to be really powerful. What you're seeing here is a Ramp Inspect session. I think this is an example of a query that we were trying to fix. This spins up in the background really fast. Modal code sandbox. This allows us to resume, spin up and spin down these containers in an isolated environment, which has the same environment that you would have if you're developing your ramp. There's a series of tasks to Keep it on track and it creates a GitHub branch and integrates with all of the context documents, our datadog, our read replica. So it can actually write queries and different context documents that product teams have put together. What's really, I think, subtle about how we've designed this is we've designed it to be multiplayer first. And that means that as you integrate or you try to pair with a designer or somebody on the PM team, you can actually help them level up their own prompting skills. They can give us feedback of hey, click on this link. This actually failed in a way that I wasn't expecting. That can be a really great source of cross functional collaboration. That was a very subtle design choice that we made that ended up being a really big impact for the company. Then these can be kicked off either via the Kanban ui. We have an API and then also a Slack thread. We can take the full context of the Slack thread when it is actually kicked off so you don't have to re prompt it with a bunch of conversation that happened earlier. What you see here is we also have a full VS code environment. We run VNC inside of a modal sandbox as well. So this allows us to have Chrome dev tools and mcp so we can actually do full stack work, which is pretty cool. And it has access to the 150 plus thousand tests that we have. So it also knows if things are broken, can respond to the CI inside of GitHub and actually patch fixes before it actually pings you that the PR is done. The link for this is builders.ramp.com I think it's like one of the first blog posts that we have or the most recent blog post that we have and we open source like the whole blueprint of how to build this and put this together as well. I think there's also a GitHub repo called Open Inspect which is an open source implementation of this as well. So it's been pretty interesting to see the impact that Ramp Inspect has had where over 50% of PRs that we merge on a weekly basis goes through the system. And so with all this time not spent on thinking about these really low level firefighting tasks or really low level small fixes or tweaks that can be kind of democratized across the company. We're really rethinking how our engineering teams operate and think about their job and how they can actually be really impactful in this new kind of AI native future. And so as a thought experiment, let's pretend we have two different teams. I'm sure everyone in this room has worked with like their handful of extraordinary teams, maybe teams that are finding their footing. And you'll notice that there's like a couple of different qualities that may sound, that may resonate. So we have team A on the left here. And let's say that they really care about impact. They handle ambiguous problems, they understand the product, business and data, they adopt new tools, they can find creative solutions, and they obsess over the user experience. Then Team B may also resonate with some people. They debate libraries, they add process when things start to feel chaotic. They constantly complain about headcount, they bike, shed the details instead of actually focusing on the user experience. Like, hey, should we use functional programming paradigm here? Or what version of different typescript libraries do we want to use? Then they build before understanding the problem, right? They just say, hey, we're going to just five code this, bro, don't worry. Or they focus on performative code quality or nitpicks that may not actually. They may be very much like a subjective kind of matter of fact as well. I've worked on both of these teams and I think the argument that I'm going to make today is that there's going to be a divergence, I think, depending on what side of the aisle you land there. This is a study from Harvard that was out, I think the end of last year. And it was very much geared towards juniors and seniors in terms of what's actually happening with hiring trends in engineering since AI tools have accelerated. And I think what this glosses over is I don't think it's just a years of experience problem. I actually think it's very much all of the different qualities that I said in Team A versus Team B that really make it apparent that coding was never really the hardest part of a lot of jobs for a long time. There's all these other engineering principles that become really important than just raw coding speed. So when you think about a staff or a staff plus engineer, you're really compensating those people more for a lot of the judgment that they bring to the table, the context, the ability to see around corners, all the learning that they have, the actual scar tissue. And so if you ask Opus 4:6 to do something, they'll have the knowledge to actually know if that is not going to work or that's actually a bad idea. And I think one thing that a lot of the narratives that we see in the media get wrong about coding agents is they don't really identify the Fact that you could still build the wrong thing just a lot faster and you can build bigger messes. And I think that having a lot of these skills of a team A and really focusing on like what is the context and reason behind this will only become more important in AI. And so what does that actually look like? We hit on some of these things. Figuring out what to build and understanding users well enough, selling an idea to skeptical stakeholders. This is still something. When we decided to build a background coding agent, this was not something that was obvious that we should be spending time on this, having good decisions with incomplete information and maintaining momentum through the long middle of this project, which can be really gnarly. And I think this last bit, everyone in this room I'm sure is painfully aware of the conversation around SaaS and the stock market and things like that. I think this is a big element that they gloss over, which is that yes, it's easy to vibe code something, but actually going through that middle process is why you need really good engineers to actually get something deployed that has product market fit that people are really excited about. And I think not enough people recognize that. And so where does that leave us? Personally, I think there's a lot of kind of doomerism and scariness around a lot of the AI narratives, but I think it's also a really exciting time to be building. Unlike maybe factory work or farming, software is never done. We have this really kind of like meme internally where we say job's not finished. You've probably seen in the marketing as well, I think software is perpetually not finished. And so with all this extra capacity, with people focusing less on this kind of low level work and more on high leverage engineering tasks, I think four things are going to really happen. I think companies are just going to chase opportunities they couldn't afford to pursue. I don't know if we would be chasing these agentic workflows and really thinking about bigger scale problems in the financial stack. If this technology didn't exist, people are going to enter adjacent markets, they're going to try to stitch together more value for customers. It's not going to be like because everyone's 2x more productive, you need two less or half the people. You're going to rebuild systems that are too expensive to touch. I think building an internal background coding agent for a company that does financial operations software felt like probably a pretty crazy idea. But now that makes a ton of sense and raise the bar for what good enough means. I think being able to kind of build more mind blowing experiences for users provide a lot more value is going to be the narrative of the next decade, and I'm super excited to be able to build some of these things and see what everyone in this room is going to build too. So thank you.