His Rule From High-Frequency Trading for AI Agents | Deepak Bapat, CTO@Tabs

Early on, we made a bet that we didn't want to build a chat interface. Actually, finance people don't really want that. Just go in and click 3 buttons and fix it. If Customer A has an AP portal and Merchant X has signed Customer A and then Merchant Y goes and signs Customer A, we can start to drive insights on how the invoices should look such that they pass the AP portal. Those are the sorts of insights that we can generate. You can't get a standard horizontal AI product. I actually don't think it's just a model problem. I actually do think there is a context problem here. There are some earlier models that actually do a better job job of being able to process contracts with the right context object than newer models with that same context object. There will be a company that grows to $100 million in ARR with one person running finance across all of these various tools. One of our CFO design partners told us, look, the whole reason they've hired me is to blame someone when things go wrong. The other day I was playing around with some new libraries. I actually decided I'm going to go write the code myself, and it was surprising how quickly the skills deteriorated. There was a minute where I was just staring at a blank page being like, okay, where do I start?

Today I'm talking with Deepak Bapat. He spent years building high-frequency trading systems where one mistake could cost millions of dollars, and now he's CTO and co-founder of Tabs, building AI for finance. Welcome, Deepak.

Thank you for having me.

Yeah, of course. Do you have a version of yourself that's not on LinkedIn that you can share with us?

Yeah, yeah, absolutely. So I graduated with a computer science degree back in 2011 and joined— and I've been in— I've basically been in New York ever since. After graduating, I joined, uh, an HFT company here for about, I think it was about 2, 3 and a half years, um, and then quickly pivoted into startups earlier and earlier stage. So the first startup I went to was a company called Yext, which was out of New York, and That's really where I fell in love with it. I mean, the culture there was incredible, uh, the, the talent was incredible. Every— just like with HF, what was cool is like, you know, back then it wasn't always the case that you would walk into a standard software development shop. And the reason I, I joined, um, a trading company first is because the talent was just so astronomically incredible. And then when I got to Yext, I actually felt the same thing. And that's kind of what made me fall in love with it, is I could build systems for large cohorts of people and work with individuals who were just way better at the thing that I wanted to get good at than I was. And so spent a few years there and then kind of took on the opportunity to be really early stage at a company called Latch in New York City. And we were a vertically integrated hardware-software company. I ended up running, um, a significant amount of the software engineering team, distributed systems, doing security, cryptography, talking to hardware devices. And so what's been cool is, is going between a, a series of different, um, domains and becoming an expert in a series of different domains. And I've, and I've now ended up at Tabs where I'm the CTO and co-founder with Ali, who's my, uh, CEO, and Rebecca, who's our other co-founder and leads strategy and implementation. And so it's been an incredible ride, all kind of— I, I have a big New York City bias, so it's, it's been incredible to build here.

Speaking of Tabs, right? Can you explain what Tabs does at, let's say, 3 levels? One to elementary schooler and one to maybe a finance manager still using spreadsheets. Like another one to like CFOs deciding whether to trust AI with their revenue.

Yeah. So for the elementary schooler, the way I kind of present it is, look, when, when one company is selling to another company, you basically need to keep track of of money, right? How much does your customer owe you? Did you get paid? And, and Tabs is built for that so that you can worry about building the best product for that company. That's how I would explain it to, you know, an elementary schooler. And for the finance manager still in spreadsheets, the way I think about it is everything is built off of your contract and a single contract is the start of a relationship that you have with a customer. And there are then additional not just written down amendments, but additional amendments across the relationship that continue to compound that financial relationship between you and your customer. And Tabs starts out by reading your contract to understand the basis of the relationship and then builds on top of that such that there are two basically tracks of work that we are focused on. One is making sure that invoicing, billing, and payment is incredibly efficient for you, minimizing revenue leakage. Across that, that track. And the other one is making sure that you are able to achieve a completely positive revenue audit the next time you go get audited. For the CFO specifically, the way I would kind of describe it is we are leveraging LLMs, classic machine learning, and determinism specifically so that you can run on these two tracks, minimize revenue leakage, and like a positive audit opinion while minimizing human capital expenditure as your company scales. So you should be scaling sublinearly from a human capital and resourcing perspective while your company scales exponentially.

Who on the finance team should use Tabs?

Yeah, so it's a comp— it, it depends on the type of company. So there are some companies that we engage with who already have really established finance teams and, and look, historically speaking, as companies have scaled, you kind of scale your finance team in a, like, a correlated way. So there are companies where we come in at a point where the team is already quite large and we have controllers using the system, managers using the system, outsourced accountants using the system, and the CFO using the system. So that's one cohort. The other cohort is the company that has maybe one operator or one person in finance that is now hitting sort of growth trajectory where they're thinking about bringing on the first or second real finance person. And in those situations, our goal is to be the most useful we can be for them and for whatever outsourced teams that they're using. Because most people— our, our ICP is generally SaaS and professional services, and in both of these verticals, there's a lot of offshoring used that we want to try to help minimize or Augment. What we're finding is, you know, there is an accounting— first off, there's an accountant shortage, right? So there are not— if you, if you read the literature and the news, like, there are not enough CPAs and accountants graduating every single year. So that's really part of the reason that we started Tabs. But then the other thing we've realized is like, look, if you can take money and resources and spend it on the product, spend it on the places that help your business grow, like That is the best use of that capital, and we wanna help you achieve that.

Let's say if you're doing it the first time, is there a moment that they will go from skeptical to like, oh, I actually need this? Is there a wow moment? And what, what does that look like?

Yeah, it's, it's a good question. I think it depends on the team. Look, I think when people, most of the people are engaging with us, they actually kind of get it from the start. I mean, contractual relationships and trying to historically trying to handle billing and revenue off of a contract has been the most tedious part of the finance stack and, and the revenue stack in general. It is the most complex and it is, it is oftentimes the work that is in some ways it's, it's uncelebrated. And so most of the people that we are, are talking to and working with, like they understand that coming in where they, I think they get that aha moment is is that first time you drop the, you drop a contract into the platform, it pulls it out, it's providing, you know, anomaly detection, it's providing the invoices pre-generated, and then being able to kind of see the path to reducing time spent on the, these rote jobs of following up on emails, right? Because once they start to see that in the platform, I think they, it just kind of clicks because they know it's a pain. Everyone is coming to us knowing that this is the pain. I mean, early on, right? Like you're probably using a QuickBooks or a Xero. Like general ledger that is this simple, but requires a ton of manual work. And that works until, let's say you have 50 customers and you have to keep track of collections and aging, and you have to start doing revenue recognition across usage. And especially today, you're seeing a lot more startups getting into the usage game, right? They're doing upfront prepaid commitments, complex tiered usage, and, and that's where it actually starts to all break down. 'Cause now you're building bespoke spreadsheets for every customer. Whereas with Tabs, it's, it's kind of a one-size-fits-all. Our, our AI will figure out what the right structure of the, um, of the data should look like so that you get the right invoices and revenue out of the platform.

And I read about a month ago, uh, Dell's CFO announced that, you know, he's using AI agents for reconciliations and journal entries. Sounds like they could be your customer.

So that's That's kind of what's cool about that is like, I think the reconciliation, journal entries, month-end close is, is the piece that is, um, most exciting to, uh, to your CFOs and your controllers because, um, every year they have to go through it. They have to go through this audit, right? And especially as you go IPO or you're a public company, that audit becomes so much more complex. What's kind of, um, Hidden behind the surface though are things which I, I, I like to think about a lot, which is like the collections piece, the billing piece, like how many people are you bringing on to just follow up to make sure you have cash in the bank? And then what does the abstraction look like before the journal entries and the close such that when you look at it, you know it's correct and you don't have to worry about the downstream implications of that month-end close. Because it's all been taken care of via abstractions. And, and that's kind of what Tabs is built around, right? Like Tabs is, at the end of the day, an invoice is an abstraction on top of a journal entry and, and Tabs wants to automate the generation and the management of those abstractions. Mm-hmm.

Also, it's a people manage thing too, cuz you're sending out this invoice and then you're sending to a real human.

Yes.

At least at this point it's still a people management component.

Yeah. But with, Yeah, the way we talk about it is that billing, invoicing, and payments is a customer relationship problem as much as it is, as it is a just work and doing the actual rote, like clicking of buttons problem. And this is where I think understanding context, understanding who you are sending the invoice to becomes so, so powerful.

But for a company like Dell, right, you may consider building in-house. At what stage should a company consider investing in a product like Tabs?

So when I was at Yext, I, I helped on the, on the billing and subscriptions platform. And I will tell you that, which is what I tell most people, is if you're working on a system that is not part of the core product, like the number of incredibly talented and top-tier engineers that were working on this that should have been focused on the actual product was, was a substantial suboptimal resource allocation. At the time, there was nothing you could do. That was the only thing you could do. This was 12 years ago, but today with tabs, my take would generally be it is not your core area of expertise. If, if the goal is to build the best product and Dell ships a ton of great products, but like if you're, if the core is to go do that, then go focus on that and spend those resources on that and let us handle the rest of it. I think that has to be the way, like even internally, right? Like when we think about build versus buy, we're not We don't use our, our company doesn't need to necessarily use like servers in sitting in, in an actual data center, right? We've abstracted it away using, uh, AWS and GCP and, and whatnot. And we don't, you know, when we think about deployment, we're not, we're not running that on like bare metal. Always be thinking about that build, license, buy model no matter what. So that's one. The second piece that I like to talk about is this idea that most CFOs, most people that are working at billing, most controllers, let's say you're changing a job every 2 to 3 years, right? You're probably gonna see somewhere between 8 to 10 companies in your prime, um, where you'll be able to pattern match by that 10th company across. But what we are able to do is just within, just by gathering enough merchants with enough customers, we are now seeing lifetime's worth of data and insights that we can leverage in order to better equip our, our customers. And I think that that is, that's really what this whole vertical AI Agentic play is about. It's, we have so much enterprise, rich enterprise data that the, that almost those, like the horizontal labs don't get access to because everyone has signed an enterprise term, term agreement with with the, with the Frontier Labs such that we can actually use that and learn and build a context graph around it.

Can you unpack that a little? What exactly do you know from, from your database that other people still know?

Yeah, so I, I think a really simple one is let's say we have Customer A and there's something in, in, in finance called AP portals, right? So these are accounts payable portals. You're submitting invoices, you have to submit with various information, really, you know, when you think about the Fortune 100, Fortune 500 enterprise companies, their AP portals oftentimes are so incredibly complex. It's almost, it can take years to just get an invoice paid because you have to submit something and, oh, the description on the invoice wasn't exactly what was expected. So, you know, you have to try again and every time you try again, you're basically resetting the amount of time they have to go pay. Well, what we can start to capture is in this process, we can start to understand if Customer A has an AP portal and Merchant X has signed Customer A, and then Merchant Y goes and signs Customer A, we can start to drive insights on how the invoices should look such that they pass the AP portal on Customer A. And those are the sorts of— that's like a really simple example, but those are the sorts of insights that we can generate. And it starts all the way from the point of processing the contract, understanding how your contracts align in terms of if, if you're a, a usage and commitment-based model and you're, um, and you have a, you have a customer and we know that that customer pays late, maybe we're gonna suggest on your renewal that you should throw in a commitment upfront. Like there's a lot of things that we can now do with this rich data that you can't get from like a standard horizontal AI product. Hmm.

Is there any privacy concerns for leveraging industry-level knowledge?

It's a really great question, right? And the thing that I say is like, the thing that we, we do is when it comes to anonymization and aggregation, we anonymize and aggregate data in such a way that your information will not leak. So the one thing I will call out is like, we do use the Frontier Labs for most of our LLM handling. And so we don't, we don't train our own models, we don't build our own models. And so what is nice about that is you don't have to worry about your data leaking because none of your data is actually being trained on for LLM models. For the classic ML pattern recognition matching, we're doing a lot of anonymization and aggregation such that we are, we are working to minimize amount of, uh, yeah, the amount of like leakage that can happen. But the nice thing about Putting in data and getting a number is, in like a classic ML case, is it's, it's a very different type of output than you would get from, from one of these large language models. And so, and so there is some, how do I describe this? There's a little bit of buffer that we have there because we're not training our own large language models, but we are very thoughtful about companies that have signed that said you can't do X, you can't do Y. We are very thoughtful about separating out that data.

But your commercial graph is accumulating industry level or merchant business-level knowledge, which is, which is without Tabs, I would have to, you know, you know, basically hit my head on the wall at least several times to pass the, let's say, the AP portal. But by using Tabs, it almost feels like, you know what, I have a shortcut now because you already know how it works with a specific, you know, business or company.

Yeah, those are the sorts of things that we want to provide to our merchants. And, and part of you joining Tabs is knowing that, look, we are not exposing who else is, who else is selling to this customer or anything like that within the platform. That is not the point, right? But the, but the point is that we can leverage how a cus— how a customer's thinking about paying, what language works well in an email, just generally speaking, when you are escalated beyond 90 days, and we can aggregate that across all, all the customers. Like, we don't have to focus on one specific customer. We can also do it at a much higher level. Those sorts of insights you're, you're just not going to get within one lifetime of, of, of understanding.

Um, I mean, if I think about, uh, for instance, the Dell case, right? They— I, I also heard that they cut a lot of employees, like 10% headcounts over the year or so, right? And in the meantime, they're announcing that they're deploying these AI agents. Yeah, but of course, not all those people are, you know, getting, you know, laid off or— finance. But in your opinion, how good are these agents or AI agents in general compared with human team members for—

yeah, finance team? So I think finance is a special case because there's a ton of liability that plays into anyone that works on a finance team. So I think when you think about, there are other roles at a company where leveraging agents on completely unsupervised or leveraging agents and replacing humans with agents is, is probably okay. And I haven't spent enough time thinking about what those roles are, but I'm sure they exist. Specifically in finance though, Part of the role of the finance team is to be able to sign your name on a dotted line and say, hey, I stand by some set of assertions that is being made with this report that's going to a CPA or to the board or to whatever. It is going to be vi— like, in my opinion, our system becomes augmentation that allows for less, uh, less headcount growth in the future, but our goal is not to just start having you shed employees today. Like, part of this is how do you become a more savvy operator today versus, versus yesterday? And that is really where we want to spend our time. And so I think with finance, it's just a slightly different problem because, because the, like I said, the, the liability, um, expectation on your CFO, your controller, is substantially higher.

What's the hardest thing a finance team does today?

So, if we're talking about finance kind of as a monolith, but I think there's different groups within the finance team and I think they all have difficult problems to solve. So obviously your CFOs is like, their hardest job is setting top-level corporate-wide strategy. Like that is not an easy thing. There is so much context that you need to be able to provide or have in order to be able to make those decisions that like, I think the idea that you're gonna go and just replace a CFO with an agent is, is going to be incredibly difficult. I actually do think that. For controllers, I think the hardest thing is actually the part of like setting up the system and then making sure that everything follows that system, even as the business is trying to change. So, a good example of this is revenue recognition. See, so what happens with revenue recognition is, and it's, it's a, it's a process in which You are basically asserting that your revenue follows a set of rules and policies that have been set out, and you are minimizing exceptions. And at the end of every year, you need to audit all of your past revenue in order to, um, to validate that assumption. Very similar to like a SOC 2 compliance. Revenue compliance is, is a thing. This is why CPAs do all of these compliance, like it's the same style of audit. For them, the problem becomes As businesses are changing pricing models, business models, etc., how are you handling things that go from an anomaly or an exception to a, uh, a fact of business, or now standard operating procedure, and now having to, to make sure that these new, um, concepts are being aligned to correctly? And then, you know, I was, I was on a panel yesterday and, and someone mentioned that especially going into a, into an IPO sort of environment where you may be looking to go public or raise at a late stage. Every day that you do, you do things in a quick, dirty, don't think about the repercussions, you're just trying to get something done way, it is 3 days on the other side that you have to go spend and fix it. So I think their biggest issue is just making sure that everything is compliant. And that is also what Tabs is meant to do. Our job is to help them make sure that revenue, which is the largest part of the audit, remains a compliant process for them.

It just feels like the level of complexity for different roles and different teams with finance is just, is just really high. And it's a hard problem to solve. Are you building for the lowest-hanging fruits of all these complexities?

Yes, it's a great question. So I think early on we did, but we're actually now in the— so Taking a step back, I think the first thing is you have to build the primitives and you have to build that trust layer underneath the primitives. So auditability, compliance are, are part of your primitive set that you're building. I think early on we were building for the lowest hanging fruit, and the nice thing has been as we've scaled the engineering team is we've brought on a series of engineers who really have helped us now build for for the more broad use cases. So we really follow this Pareto 80/20. We can now support basically 80 to 90% of use cases, and that last 10%, we can figure out a way to make it work. As part of this, I think, I think what's, what's become very interesting is like, when you think about the lowest hanging fruit, right? A lot of that can be solved with like a classic LLM wrapper. Right? So a low-hanging fruit would be like responding to an email of someone who has an escalation, right? Doing that at the shallow level by just passing that into an OpenAI or Anthropic API and saying, hey, give me an email response to this is, in my opinion, solving, solving in a, in a way that gets you quick and dirty, but doesn't solve for the, for the real value prop. And so building the con— like the commercial graph or this knowledge graph that underlays our platform. Building the primitives and then building agents that are meant to be orchestrated across long periods of time. That's really what we're building for.

I'm wondering, is that last 10% replacing the CFO? And if you can, you can complete the first 90%, are, are you gonna be able to replace the whole finance team and you only need a CFO?

Yeah, it's, it's, it is a, it is a great question. I mean, look, I think. By, in the next couple of years, there will be a company running on Tabs that we are gonna be part of a back office suite. So it's very similar to how, how when you think about Char, you've got the Riplings and the Gustos and the Justworks of the world, and you've got for expense and, and AP, you've got Ramp, Navant, Brex, ZipHQ, all these great companies. We are gonna be one part of the stack. And the ideal situation is that in a couple years there will be a company that grows to $100 million in ARR with, with one person running finance across all of these various tools. And all these various tools will be talking to each other, there'll be agents talking to each other amongst them, but one person will be able to guide all of finance. That's not going to be every company though, depending on the complexity of the company. I do think that, you know, You're gonna need, you're still gonna need some controller because at the end of the day, it still comes down to liability. I remember when we first started, one of the, one of our CFO design partners told us, look, the whole reason they've hired me is to blame someone when things go wrong. And it's the same thing of the accountant. And so you still need that level of someone exists at the company to handle this and is managing all these various agents, just like You know, we're not gonna get rid of software engineers. I truly don't believe we're just gonna get rid of software engineers. There's just gonna, like, the job just changes. And I think that's what you're gonna see in the stack as well.

It's your vision for, for a company having a very lean finance team. You know, where does Tab sit in this tool landscape?

Yeah, I think we sit as a, as a partner to all of those. And I think what it ends up being is these systems are talking to each other either through something like an Agent MCP interface or something similar. And the humans are talking, there's always the command console that you can go to and view everything. But for the most part, you're doing everything through a, through a, uh, an interface where you are just talking to a bunch of agents that are all collaborating across various systems. And I think opening up these systems in a way that allows you to, to do that, I, I think that is gonna be a huge value prop. The thing that I, I don't want to expose necessarily are the insights directly, but I am okay exposing them via the agent. So the agent can tell you what it's doing and why it's choosing to do it. But the underlying knowledge graph that I have is, is mine here at Tabs, and our agent can execute based on that knowledge graph the same way these other systems will. And these agents will be talking to it is, is how I see it playing out.

Do you think Tabs will, uh, will be the manager for, for managing these conversations between agents and This is an interesting question and it's something I've been thinking about a lot.

Like in DevOps and in the SRE world, there's concept of orchestration and then there's concept of choreography, right? I, my general take is that there will, at least in the interim, there will still be a human that is the orchestration layer of a series of agents that are able to communicate with each other and is orchestrating that conversation. But there will be times where there, it is much more choreographed than it is orchestrated. And so these agents will be making decisions by cross-pollinating across these systems and then will escalate any decision that needs validation to the human such that that human can say yes, no, change XYZ, and then they go back to it. And I think it's gonna be a little bit of a combination of both of these, but I don't wanna say Tabs is gonna be the overall orchestrator. It remains to be seen how this plays out, but I believe it is gonna be more choreographed than it is gonna be orchestrated. I think when you think about choreography, it is by its nature decentralized. You have services reacting to events, right? Amongst each other. But there is, but then you still need a, a shallow layer of orchestration on top to make sure nothing is, um, messing up. But you kind of like, these systems will get good enough in the next few years. Tabs will be good enough where you can just kind of let it run. And only— it's only gonna escalate 10% of the, of anything to you. And if you're running a $100 million ARR business, that is a huge unlock for you to be able to go do other things. And if, if you have a couple of systems that are all doing that, that opens up a significant amount of time for you to go focus on more strategic activities.

I wanna ask about how, how Tabs builds these AI agents reliably. Yeah. But instead of just asking you directly, I wanna take a flip the table. Let me try and build one of your features from scratch, and then you tell me what I'm missing.

All right, let's do it.

Okay, which feature is your killer feature?

Yes, we can talk about contract processing.

So, so I'm assuming that a contract gets signed, you know, in the, in the client interface or portal like Salesforce, and then deal moves to maybe close the one. So the contract is ready, and I can take that PDF, I'll feed it to Claude or use Claude API, right? And ask to extract all the information I need, like pricing, payment terms, renewal, and then Claude can definitely output a structured JSON file and put that in the database. I can even build a cron job that just checks the database every day and then I can plug in the Stripe for payment processing or email for collections, things like that, possibly doable.

Yeah.

Is my, it's my setup, but, but what, what's not enough?

Can you share? Yeah. So. So, the first thing you have to think about is not every contract is, is, uh, born the same, right? So, you have contracts with amendments, contracts with commitments. You have people who are papering documents. So, if we sell to a Fortune 500 company, most of the time we're not gonna be able to use our paper. We're gonna have to use their paper, right? You have new pricing of business models that are constantly coming up, and what you're gonna find is that Look, if, if you are a simple customer with a one-page order form with a flat price that you're charging annually upfront, yes, you can feed it to Claude. But as it gets more complicated, you're gonna see that these, uh, these Frontier Labs, they're the generic models without the right context, are gonna start to degrade in performance down into the mid-80s, mid-80% accuracy. And we, we run accuracy based on like a, weighted equation across all the fields that we're trying to, to calculate against. And so that's the first thing. So the first thing you actually have to do is understand what type of document is this? Is it an amendment? Does it have commitments? Does it have complex usage? What are the categories that this contract underlines? So that's like part of the pipeline, right? Let's say it's a, it's a, it's a base level contract with, with commitments, with, uh, you know, tiered usage, et cetera. What we have done as part of the implementation process— so, so actually taking a step back, so you're gonna notice that that first piece of figuring out what type of document it is is a combination of taking the embeddings and figuring out against, uh, a set of samples like which it's closest to. So it's like a, a comparison problem, cosine similarity problem, and then also using an LLM to to validate that the decision is around. So you're kind of running a couple of different algorithms in that pipeline, right?

Why do you need to do the similarity match? Like, what am I comparing with?

So you're comparing with other amendments. It's a classification problem, so you're comparing it amongst a larger corpus of embeddings of other types of documents, whether they are specifically amendments, whether they're order forms, whether they're MSAs, whether they're churn notices, whether they're renewal noti— like whatever they might be, that's like the first layer. I do it that way because it is much simpler and less costly than actually going to the LLM and trying to feed it to an LLM. So if we have enough data, we can, we can actually do that ourselves. And then understanding what's in the, the contract, like what are the complexities of the contract, you can leverage, again, you can leverage an LLM with the, with the right context being passed in, which is part of our, as part of our implementation training loop. Like we generate these context objects during your implementation process with feeding in all of your contracts, comparing them against other contracts we have. And, and though, like, there's a lot that goes on there. So you have this context object. Now, as you, you know, what we have found as well, basic performance degrades. If you're using the right context, your, um, you know, contract extraction can stay well into the high 90s on accuracy, which to be fair is actually like very good compared to most humans. So even when most humans we found are processing contracts, of the same company over and over and over again, their ability to be correct consistently also degrades, right? Like they're, they're oftentimes missing things or the nice thing about, uh, LLMs is they're reading a lot of the context simultaneously, whereas like we are only scanning certain parts of the page. We might miss net terms that are hidden somewhere, et cetera. So that's the first part of the pipeline. We're using structured outputs to take the unstructured data and turn it into structured data. Then there's a deterministic piece of this, which is you have to run generating a series of invoices with the events and whatnot. Like there are algorithms that you have to run in order to make that work, right? And so it's, we've moved away from classic ML and LLMs to now deterministic workflows to generate the invoices, generate your performance obligations, et cetera. Once those invoices are generated, we're gonna send a message out to our our merchant over Slack saying, hey, this is ready, please go check it. Or you can just go ahead and auto-approve it here. There are some merchants that just go ahead and auto-approve, but most people are going in and checking. As they are going in and making adjustments, what we are doing is we actually, we just released this, but we are auto-calibrating your context objects based on changes that you've made in our platform so that the next time around we are able to capture any new behavioral changes that you want to make against contracts. As part of that. There's a separate flow in all of this, which is our anomaly detection, which also uses embeddings and tries to use, um, basically uses principal component analysis to try and understand the variety of different buckets of contracts that exist. And when a new contract comes in that doesn't fit any of those buckets, we need to flag it, have you, have you fix it, like put it, have your, a closer eye on it, fix it. And then we can actually add that to our training set automatically as part of this. So it's like, there are, yes, you can for a very basic contract, just get it uploaded, get the data stored in a database and like, you know, if it's the right structure output, generate the invoices and that part is fine. But this whole like self-correcting piece of the system and the, all of the different parts that go into it were things that we had to understand, learn, and build over time.

Is this a model problem or is this a context problem? What if Claude just get just so much better and you don't even need to do the classification step? My— you have this, uh, classification step which I think increase your accuracy because if I just throw the contract to the LLM and then let it, you know, be burdened of figuring out what contract this is and then the like, the likelihood of making a mistake is higher, then you know, you get a classification problem.

Yes. Yeah, yeah, I think that's true, but I think, I think there's a couple thoughts here. So one is, there is, there are other deterministic workflows that, that happen down the line where, look, if you just threw this at Claude and it was an amendment, it needs, still does need the context from the previous contract in order to understand what is amended, right? So there, there, there are context pieces to this. But I actually don't think it's just a model problem. I actually do think there is a context problem here. I think there's, you know, there's been plenty of literature around, I think there was something that came out. Maybe it was in February about how GPT-5.2, uh, the article was like GPT-5.2, uh, can't count to 5. It was, it was a paper that got published. Being able to understand the un— like being able to give AI the right set of tools that are deterministic to be able to actually generate good output is, is one problem. When we talk about the context problem, I do think that what we have found in fact is that there are some earlier models. That actually do a better job of being able to process contracts with the right context object than newer models with that same context object. Maybe it is, maybe it is an overthinking problem internally. There could be some, there could be some element of like a lot of the newer models are, are somewhat fit to coding problems and, and, and very specific types of problems. I, I just, I just generally feel that if you can figure out how to make, how to use an, a more simple model and use context to drive outcomes that are actually satisfactory, what you are doing is you're doing the best thing for your customer, which is you are reducing cost. You're actually reducing costs for them while also being able to maintain a level of efficacy. And I, I, I think that that gets overlooked. I can think there's some NVIDIA exec that came out recently that was like, actually in some cases it's actually cheaper to just hire people than to spend money on compute, uh, with these LLMs. And we are going to start to see that as these models continue to, to grow. It's like the models themselves are going to get expensive. And so we must be able to pin ourselves to simpler, the haikus, not the, not the opuses of the world and get those working with our problems. So I think it is a context engineering problem at the end of the day that we need to solve for if we want to be good fiduciaries and good stewards of our customers.

More reasons to believe that Claude improve— improving their models itself is not going to solve this vertical AI problem in finance.

Yes, that's exactly right.

Right. Is hallucination a problem?

Hallucinations can be a problem, and we have found— so this is an interesting question, right? Because I think you need, in some ways, you need enough reps for the hallucination to actually be to be, to show up as a problem. So for instance, if a model makes a mistake 1 every 10,000 contracts that come in, right, there is some element of most merchants don't have 10,000 contracts. And so most merchants are not going to actually hit this, uh, hit this threshold where they are gonna, they're gonna see an error. But that being said, we always build with the assumption that hallucinations or errors are going to be a problem from the models themselves. When we launch new features, we require that there be a human in the loop on the merchant side that is approving and clicking a button for all intents and purposes that says, yes, I'm good with this. And so all of our systems, until the merchant feels really comfortable, we intentionally toggle on human in the loop. And that's how we've gotten away with it. And at the end of the day, we do tell every one of our merchants the models are only gonna be so good. They will be better than a human processing your contracts, but they will not be, you know, 100%. Here's like, we actually provide that level of accuracy in the platform itself so they can see how it's doing.

I'm assuming the finance team using Tabs can still prompt the system directly, right?

There's, there, the way that we have allowed for that is actually through an FCP server. So early on, we made a bet that we didn't want to build a chat interface in the platform. The reason for that is because we found that the background agent model worked better for what our finance teams want. So that bet has kind of paid off because with MCP and with Claude, the Claude harness being as good as it is and the Claude code harness being as good as it is, it is a much better system in which to interact with tabs where you need some level of, uh, you need some level of, uh, stochasticity. And so we have, we've kind of put all of our eggs into that basket rather than trying to build an internal chat interface, which we have found to be kind of a nice gimmick, but actually finance people don't really want that. Like if we process a contract wrong, there's a way, and, and we're coming out with this shortly, there's a way in which once they make changes, we will learn from that, right? We're gonna learn from that and we're gonna improve the next time around, but they don't wanna go in and like prompt the changes, just go in and click 3 buttons and fix it. Like that's the right thing to do because now imagine that prompt, like when you prompt it, it gets it wrong. Now you are already starting to degrade real trust. This is why I think the UI experience is still incredibly important and we do focus on it.

That you're saying you don't have a chat interface and then the way to communicate is through actions.

That's right. And we have focused on if you wanna If you wanna communicate with tabs through a chat experience, use an MCP. And most of what we are doing is actually through what we call background agents. Ambient agents is the LangChain term that they used, but we found that that is way more ROI generating than them having to send a request to do something.

Human communicating with agents actually creates another layer of potential hallucination. You have suggestions for finance team how to use TabSplit?

Yeah, it's, it's a really good question. The way we say is like, trust that we are building pipelines with the right level of determinism. So even when you go in and you want to retrigger, let's say we've, we've retrained the context object, and so you want to retrigger extraction on a given contract. We don't let you put in a prompt, and that is specifically for this reason, because we have found that when people try to prompt on top of the context object, they oftentimes cause more issues because now you're giving differentiated advice from what the context object has. And so these systems get confused and you can actually generate more hallucinations. And so we've actually made it a very clear point that you cannot do that. The place you can prompt in the system is when you are generating new emails to send out, um, as part of dotting and escalations on invoices, you can prompt and say, hey, here's a little bit of information about context around XYZ, please, please add that. And that will go into the prompt because you're gonna go in and modify that email anyways before you send it. End of day, it goes back to those two things. When you close one, a contract, you're minimizing revenue leakage and you're getting that, you're passing your revenue audit while minimizing additional human capital.

I'm curious, how big is your engineering team?

Yeah, so our engineering team, our core engineering team, including our AI team, is about 30. We have an additional 10 FDEs, and then we have, you know, sales engineers and other people. The core, when I, when I think about our engineering team, I would say it's, it's around 40 to 45 people that we have doing some sort of engineering at the company to drive the product.

Has AI changed how you think about how many people you need? And who do you hire?

Yeah, it's, this is a really interesting question and something we debate internally a lot. What's, what's, and, and I'm sure you have seen this too. It's like, just because we have AI doesn't mean people leave earlier. People are still like at the, at the office for as, as late as they were before, but the expectation of what they can ship is much higher. And so the way we see it is if we were, the one thing I, I have started to now do is is look at token usage and token costs. Like we are seeing some like spikes there and we need to figure out how we manage that against a population of, uh, of engineers, right? Across the spectrum of new to incredibly experienced. But from a pure engineering capacity standpoint, if we have resourced for Axie, I'm just gonna say we're gonna go build more. Like we're not gonna, we're not, we are less, it's almost less limitation on what we can do as a product team. The other thing it has unlocked for us is actually As you added more people, there was a tax on, um, there used to be a tax on communication and that has dramatically decreased because now I can have my product managers look at the code base directly. I can pull in Notion, Claude, uh, Claude to Notion to, to Linear to everything and understand where everyone's at. And so I think in, in fact, what it allows you to do is it allows you to do more with more, do more with less or, or do the same with less. Like I think being able to do more with more is, is substantially better.

I do feel there's a type of engineer that, that's becoming more valuable since AI.

Yes.

And that just become less valuable.

The one thing I, I will caution people is the other day, actually, I was playing around with some, some new libraries and I, in those situations, I actually decided I'm gonna go write the code myself. And it was surprising how quickly the skills deteriorated. And I had to like, I mean, it came back, but like there was a minute where I was just staring at a blank page being like, okay. Where do I start? Whereas like, if this was a few years ago, I would've just started, I would've known exactly what to do. And so the one thing I do caution is, especially earlier on in your career, I think it's okay to take some time. What I tell some of the more junior engineers is like, write the TRDs yourself, write some of the code yourself. You don't want to just outsource all of your thinking because you will never be able to get it back. 'Cause you won't have built it in the first place.

That's such a dilemma. You know?

Yes. Yes. Because they wanna ship fast and we want them to ship fast. But yeah.

Bar is higher. Everybody's doing more. And if you're slow trying to figure something out.

Yeah.

Do you think there's room allowing for that on your team? Like junior engineers?

It's really difficult, but I'm trying to give them the room and the space because it's only gonna make them better if I'm able to allow them to do that. Right. Giving them the space now, 3 months from now, if they can just crank, like if they just become incredible because they have now a base, like that's, that's important. Otherwise they're just, they're never gonna get the ability to go beyond where they are, which is actually worse for us. It's that classic like investment problem. When do you invest in that?

It's very rare to hear startups willing to invest in junior team members.

Yeah.

It's rare.

I was a junior person at one point and people invested in me, right? So like, The idea that I'm not, I don't know, as much as I wanna move fast, I wanna break things, do all that stuff, I also do believe that at this point in my career, my coaching tree and like the people that are gonna go off and do interesting things that have trained under me or whatever is important. And the more people that get to go do that and have incredible careers, I think that's important to me.

How are you giving your junior engineers the room for growth?

Yeah, again, this is really difficult. So the first layer is we need to make sure we have exceptional management. Like, the role— and I get it, like, being an incredibly flat company with a lot of agency is important— but I actually do think that everyone has blind spots, and you need someone who has been there to be able to tell you that things are, you know, where you are. So I think having a really good is still important. I think the other thing I do is I I really, really, really push them. So every day I do 20 minutes with some engineer on the team and the goal is to do blockers and, and whatnot. But I'm also, as part of that, auditing their TRDs, their work, their GitHub pull requests. And I, I'm talking to them about it. Like there are, there are certain, uh, CEOs and CTOs, exceptional ones that have done this where they're just like, they get really nitty gritty. And so I haven't. To be completely honest, I haven't found the perfect model in this day and age to grow junior engineers, but what I am trying to do is just be more hands-on with them, give them really good management, and really have them dive in. Like, if you can't explain a PR, then you should, you need to go back to the drawing board and at least do the bare minimum there. I'm like pushing them to do that.

Yeah. Are you interviewing engineers differently today?

What's funny, it's actually funny. We switched around from doing a, we stopped doing a coding exercise. One of our coding exercises became a code review exercise because we actually think that that is almost the more important thing that engineers are able to do today. And so, that has replaced one of our, uh, our, our on, on-sites. But, but we still do, do a coding exercise. We still do a system design cuz I actually do think that those are important. Like, Even for mid-level engineers or junior engineers, like you may not understand how to do system design, but if we start to prompt you in the right way, can you start to think, can you adapt? Like adaptability has become so important that being able to adapt mid-interview as you're like getting prompted about different things becomes to me a really important concept to own.

What AI do you use on a daily basis and then what do you use AI for, for yourself?

Yes. Yeah. So, um, I've built. So one thing I've done is, um, obviously Claude with MC Claude Desktop and Claude Code is— Claude Code is my preferred model, though we allow people to use cursor or Claude here, Claude Code, whichever they prefer. It's probably 50/50. Um, I've also started to build out my own LangChain agents. It's been kind of fun. Like, I have an EA now that, like, listens to my, uh— I am by nature not a person to write down to-do lists, and so this thing manages that for me and prompts me whenever I need it. And, and then the next one I'm, I'm, I'm starting to build out is this, it's a tool that helps me think more strategically, first principles, you know, all of the different mental models and being able to like come up with the way to answer more tedious questions. So obviously in the day-to-day life with a consumer product, I use ChatGPT and Claude on my phone all the time. But like, that is the thing that I am actively building where I'm, I'm trying to learn, trying to grow, trying to get better. And it's been great. I actually have like 6 to-dos that I need to finish by the end of today, which is always the case.

Yeah, a lot of pressure. I built an MCP server for the founder brains, all the founders who I talked to.

Oh, that's interesting.

Yeah, I can share. Once I make it public, I can share with you as well. I find it very, very interesting. Like, I asked a very— a question that I never asked anybody. Things like, you know, if I want to hire this person, and what should I let this person do? And that's a question I describe the context, and then they give me a lot of good feedback from founders who I talk to.

Oh, that's interesting.

I find it so tremendously helpful, so I will share it once it's ready.

That's a really cool use of the context that you have with all these transcripts and videos.

If you could recommend a book, you know, to maybe one of those fresh graduates who are struggling with building their career, or maybe yourself today, what would that be?

My favorite book of all time that I've read is called The Age of Wonder by Richard Holmes. So it was, it came out probably like 10, 15 years ago, but I read it in like, I must have read it in like 2015 or something for the first time. And it's about the Romantic era and these great scientists and explorers of the Romantic era. And it's so interesting because they're all, how do I describe this? They are they're not necessarily polymaths. So the book is about William Herschel, who was like an astronomer, and his sister, Joseph Banks, who like ran the national, uh, like the Royal Society for 40 years or whatever, talking about how they mixed art and science and like pursued learning and knowledge because they just loved it so much. And it was just so fascinating to them. And when you think back at that time, like, The idea of like a comet, right, was like a new concept, or like exploring Africa or understanding, like, this is the same era of Darwin and all these people. And it's like seeing how they, and a lot of them were also artists, poets, those sorts of things, and seeing how they merged all of these like interconnected, like they were so interdisciplinary. And it's, it's something that I strive to be. I don't think I have, I I don't think I will ever achieve like multidisciplinary success in that way, but just something to strive for. And it's, I don't know, it was just like an incredible book. Like wonder is exactly the term I'd use to describe it.

That's so inspiring. I feel the same way. I think if you're enjoying what you're trying out, then it's, you are the wonder you're trying to make yourself into.

Exactly.

Amazing, right? Yeah, thank you so much, Deepak. Thanks so much for spending the time and being so generous with your thinking.

No, thank you.