Earley AI Podcast - Episode 95: Contract Intelligence, Context Engineering, and Building AI That Scales with Deepak Bapat

Why Making Complex Revenue Simple at Scale Requires More Than Throwing Contracts Into a Chat Interface

Guest: Deepak Bapat, Co-Founder and CTO at Tabs

Host: Seth Earley, CEO at Earley Information Science

Published on: July 30, 2026

Podcast Transcript: Contract Intelligence, Context Engineering, and Building AI That Scales

Transcript introduction

This transcript captures a conversation between Seth Earley and Deepak Bapat about what it takes to build production-grade AI on enterprise contracts. They cover the gap between a general-purpose AI experiment and an enterprise-scale pipeline, the aha moment when generative AI made contract reasoning possible, why context engineering proved more elastic than fine-tuning, what the atomic pipeline approach produces that a single large model call cannot, the provability requirement that financial compliance demands, and what organizations need to sort out internally before any AI system can help them.

Transcript

Seth Earley: Welcome to the Earley AI Podcast. I am your host, Seth Earley, and in each episode, we explore how artificial intelligence and data are reshaping business strategy and operations. Today, we are going to be talking about one of the more technically demanding applications of AI in the enterprise, and that is extracting structured, accountable data from complex legal agreements and contracts at scale. It sounds straightforward, but it really is not. Joining me is Deepak Bapat, co-founder and CTO at Tabs, which is a revenue and accounts receivable management platform built for B2B companies. Deepak brings a deep technical background spanning high-frequency trading infrastructure, hardware-software systems at Latch, and now AI-powered contract intelligence at Tabs. Deepak, welcome to the show.

Deepak Bapat: Thanks for having me, Seth.

Seth Earley: Let's start with misconceptions. What do you run into when you talk to executives about AI, generally and in your particular problem space?

Deepak Bapat: The biggest thing we run into consistently is the idea that difficult problems can just be solved by throwing something into ChatGPT and having the answer come out the other side. In our case, we get a lot of misconceptions around: why can't I just take all my contracts, throw them into a ChatGPT or a Claude, and just get the outputs that you all have? It is a fair question to ask. But one of the things we always come back to - our mission statement at Tabs is to make complex revenue simple at scale - is the at-scale piece. The intelligence tools that make it really easy for users to use, even at the organizational level, are still individualized tools. To do things at scale for an entire enterprise still takes specific tooling, specific thought, and specific expertise compared to just horizontal, generalized modeling.

Seth Earley: It is really critically important to be integrated into the workflows. If you have all these people using a large language model individually, you are doing it at a fragmented level - you are not collecting the enterprise intelligence, not detecting those patterns at scale, not integrating with the other tools and systems. What about the SaaSpocalypse - the claim that software is going to disappear into the chat interface?

Deepak Bapat: I do believe that whereas many years ago you could get by with a system of record with simple intelligence sitting on top, it is really important now that you embed intelligence throughout the entire platform. While I do not believe a chat interface is necessarily the correct way to be interacting with your software, I do understand the allure of being able to do more complex querying, reporting, or bulk aggregated actions more simply than previous systems of record allowed. The more interesting thing we need to go solve for is understanding the actions a user is trying to drive, and then preempting that. But in finance and the domain we are in, provability on screen is actually really important. Being able to visualize an entire history that is both provable and accurate is incredibly important for every one of our stakeholders.

Seth Earley: Give us a grounding in what Tabs is built to do and what the problem looks like for the B2B companies you serve.

Deepak Bapat: Tabs is a revenue, finance, and billing platform. Fundamentally, what we are trying to do is for companies that have complex revenue, make it simple and easy at scale. That means automating everything from closed-won contract through cash in bank and through audit - contract to cash and contract to audit. Those life cycles are what we are built around. Everything reconciled back to the source contract, and then any additional change to that customer relationship monitored, observable, audited within the platform, with all the workflows around that happening automatically.

The problem comes from something Ali, my co-founder and CEO, himself faced when he was operating Latch. As companies scale past a certain point, it becomes very difficult to manually operate. You go from Excel to QuickBooks to NetSuite or Sage, and in those cases you are spending a tremendous amount of time and energy trying to mold those platforms to what your business looks like today. When your business inevitably changes, you have to do it all over again. If we can build an incredibly elastic platform that can handle any sort of business case through both understanding aggregated data and your specific preferences, we can almost automate away a lot of billing and revenue compliance.

Seth Earley: What was intractable about the legacy model that generative AI made solvable?

Deepak Bapat: The complexity and ambiguity of the jargon in the contracts themselves. Our company started out as a billing platform for hardware and software devices, and we came about at the same time ChatGPT launched for the first time. In that moment, there was a very specific aha moment. Before, reading a 400 to 500 page document was incredibly complex using OCR and old-school machine learning tools - humans still needed to manually input all the information. But now you could have an LLM actually reason over the words in the document, understand what they meant, and understand what the output should be given a series of instructions. Our initial product was just a contract processing product. We processed your contract, pulled out key information, and then we realized we could combine this with the billing idea - and we took off.

Seth Earley: Extraction accuracy started around 50 percent. What did you do to compensate while the models were not yet good enough?

Deepak Bapat: We did not rely heavily on GPT in the early days. What we did was break down everything we were trying to extract into a series of atomic jobs. That has carried on throughout the entire lifespan of what we have done. At the time it might be: first, chunk the contracts, then label the types of information we find in each chunk, then do the next step. We broke it down tremendously, but at the end we still had a human in the loop early on.

Where we are today, by the end of this year, we expect to have removed the human from the loop almost entirely for standard contracts. The atomic job approach turned out to have benefits that carried forward even as model capability improved.

Seth Earley: You moved from 50 percent to the 90s. Walk us through why context engineering won over fine-tuning.

Deepak Bapat: The models improved so quickly in that year and a half where we were experimenting that we quickly realized fine-tuning is great because it optimizes on the data that you have, but a lot of what we are trying to do is be manipulatable and elastic for data that does not yet exist. When we have a new merchant that brings new contracts, or an existing merchant that has a new pricing model, being able to just use an existing, generalized, really good model and engineer the context around it is a much faster avenue to the same outcome.

Context engineering is, in my opinion, a more mature form of prompt engineering. It is not just the prompt you write - it is allowing the model, as part of its input, to understand the context under which some variable data is being provided. The new models are very good at taking all of that context and understanding how it applies to your actual input. At the merchant level, preferences matter so much that it is very difficult to fine-tune across many different merchants simultaneously. If you are going to fine-tune, it has to be merchant by merchant, which becomes almost cost-prohibitive. So you provide the context of that merchant: here are my procedures, here are my guidelines, here are my preferences, here are my contract terms. Now make decisions in that context.

Seth Earley: Something interesting you said is that newer and bigger models are not always better for your specialized tasks.

Deepak Bapat: We have a bunch of eval sets that we run, and we have found that models from six months ago actually perform better on certain jobs than newer versions of those same models. I think part of it is that when you think about what these models are being trained on and what people want them used for, there is an overfitting on coding that some of these models are undergoing. They are getting bigger but actually getting less efficient at non-coding-related tasks. The other thing is that a newer model may use more tokens to solve the same problem. You put the same problem into Claude Opus 4.5 and 4.8, and 4.8 might use more tokens and therefore be more expensive. Sometimes it is actually more cost-efficient to use smaller models at a more atomic level.

Seth Earley: Walk us through the pipeline - validating a contract against prior ones, classifying, then extracting.

Deepak Bapat: There are different types of jobs through the pipeline. There are classification jobs, discovery jobs where you read through the contract and annotate it, and jobs around amendments - first, what is being amended, and then, once you have decided that, how is it being amended. Each specific job is handled separately. There will come a point where a model is good enough that you can pass it the entire schema and say, deliver everything provably, but we are just not there yet. In fact, just because you have a million tokens that can fit into a context window does not mean you want to use all million tokens as part of your input. There is a peak in terms of context window percentage where performance peaks - and it changes per model.

Seth Earley: Provability seems to be the non-negotiable requirement in your domain. Talk about what that means.

Deepak Bapat: What we are actually trying to do is not just say the model produces the JSON and it is correct. What we are trying to say is: I can prove that this is correct. Half of what we are building is a system that allows our merchants to prove that invoices and revenue are as expected, based on rules of engagement they have defined - ASC 606 compliance for revenue, all of the data necessary to inform provability of our outcomes. The system is also built to handle amendments, renewals, and versioning over the life of the customer relationship, which is a much more difficult problem. If you take an amendment and pop it into an engine you have built and then someone comes along and amends something completely differently, it does not work. Complex financial compliance requires that you can prove correctness, not just achieve it.

Seth Earley: What about organizations that say their accounting package already handles contracts and revenue recognition?

Deepak Bapat: A lot of those are still built around structured data. You must have structured data - they have written specific code for your current use case that allows them to say, yes, of course this is provable, because here is the code that was written. But you have an exception, you want to change that, now you have to do the whole process over again. The whole idea behind Tabs is that if you assume a lot of revenue rules and customer relationships are in natural language and unstructured, and you must move from unstructured data to provable and correct structured data - that is what Tabs is built around, and that is what most of these other systems cannot handle.

Seth Earley: What about the person who says, I will just use Claude Code and build it myself?

Deepak Bapat: If you have simple contracts and not that many of them, and you do not plan on changing your contracts, a semi-technical person can absolutely go build this. But once you get into complex finance and financial compliance, it starts to get difficult. And beyond the initial build, we handle amendments, renewals, and versioning over the life of the customer relationship. Once you get past a standard set of contracts, where you know someone will go fill those fields out correctly every time, you are going to find what we have seen with almost every one of our customers - that is just not the case. The larger the enterprise, the more complexity and variability there will be, and it very quickly becomes something that is not sustainable to maintain yourself.

Seth Earley: For a finance or data leader who wants trustworthy AI running on their contracts, where do they start and what foundational work cannot be skipped?

Deepak Bapat: Understand what you want your outcomes to be and be able to reasonably articulate them. One of the things we find is that as part of our implementation process, as we are starting to pull in contracts and run calibration, we realize the other side needs to clean up how they think about contracts. They need to coordinate amongst themselves on what outcome they are trying to drive. We work with companies today where if you ask two different people on the same team the same question about the same contract, you will get two different answers. Part of the job is just internally standardizing on what you want. As companies scale, half of our job is making sure you are thinking about it from a systems perspective - not just throwing it into an LLM and going and doing something with whatever output it gives you.

Seth Earley: Deepak, thank you so much for spending your time with us. I really appreciate your insights and thank you very much for being on the podcast.

Deepak Bapat: Thanks, Seth.

Seth Earley: And thank you to all of our listeners for tuning in to the Earley AI Podcast. Make sure to subscribe for more conversations on how AI is shaping the future of business.