# Transcript

Okay, let's dive in. We've largely been talking about code. Let's talk about data. Quick recap of what Vivek had also shared in his pre-read, and I'll summarize this—you may have read it of course, or your agents may have read it.

<SLIDE>

## Recap from pre-read

1. Dashboards are for humans. **Data is for agents**.
2. **Question** determines aggregation. Not data _type_.
3. **Unstructured** judgment is a valuable asset.
4. What if they're wrong? **Provenance** is critical.

</SLIDE>

**Dashboards are for people. Increasingly, data is increasingly more for agents.** Which means the things we've learned about how do we design data, we need to rethink a little bit. If the agent is going to consume it, what does it mean?

Second, earlier we took data and we said we'll build our aggregates, we'll create the joins this way, making certain kinds of things simple. Now an agent can do it by itself. And if that is the case, we don't need to pre-create a lot of it. **We can tell the agent: structure it how you need to answer that question.** And therefore, for every question, it can on the fly create whatever aggregation structure it needs. And we will see some of this; you will see some of this; you will do some of this.

Third, unstructured data is becoming more processable. Therefore, the value that it's starting to unlock—because we've never really looked at it at that scale—becomes higher. And that means that all of the conversations that you're having internally, all of the code review discussions, all of the meeting minutes, these become a certain kind of an asset that we can potentially productize, but at least leverage.

And fourthly, because we are dealing with data and we make decisions with data, if we get it right, it's a problem. Earlier we were using computers which failed in known ways; AI is failing in newer ways and we need to be able to trace these. Which is a crude summary of what Vivek had shared in his email, and that's what we are going to dive in.

But before we do that, I'll invite you to please fill out three short questions. QR code, just use your phone or type in the link. It's fairly small. And the questions that this asks are—I'm just waiting for the question to still load back. There, the QR code is still on the top right. But supposing you face this—somebody has come to you with this request: how long will this take? The request is: the client says, "I have three customer masters, and each of these lists of customers have their own IDs, they have their own column names, they have their own spellings." The QR code is in the top right in case you need it. And you have to convert this into one clean queryable dataset. How many days will it take you to do this? And let's assume that the dataset has, what, few tens of thousands of rows, max less than 100,000 rows, let's say, each of these. How long might your team say? Put in your number of days. So let's say if the team says they'll take a month to do it, 30 days. They say they'll take a year to do it, 365 days. They'll do it in a day or two then, whatever.

And second question: just roughly your guess on what percentage of the company's data today can be used actually by agents? Just your guess. Maybe you say, "Look, the way our data's structured right now, none of it can be used by agents," that's perfectly fine. Or, "All of the data is well-structured enough that agents can start using it right away, we're there," perfectly fine. Or anything in between. What's your guess on this?

And thirdly, what are the top things that are blocking you from deploying agents on real workflows on top of data? That is, you give your team, your clients access to an agent which sits on top of some data that you have—your data—and say, "Go ahead, run with it." Now, you may say, "Hold on, we've already done this," and that's perfectly fine. That part is where it's already worked. There are parts where it's not working, you haven't gotten around to it. Maybe because you just haven't had enough time, it doesn't have enough value, we don't know how to do it, the data's not good enough, the use case is not strong enough or clear enough, the stakeholder is not available, whatever. Where it has not gotten deployed and you're aware of those, what are the top three things that are blocking you?

Let's give this a shot. I'll wait till—okay, so for the first question, we have seven responses so far. I'll just wait till the number of responses climbs up to maybe at least, now, two-thirds of the room because this is something that we will be looking at at the end of the session and just doing a quick revisit. The QR code is in case you need it on the top right, and you can click and open. Okay, for the first question, we have 9 responses, 10 responses, good. I'll just wait till maybe we have about a baker's dozen, 13, and we'll continue. But just yeah, 11, couple more responses and we'll go ahead. And yeah, to fill out the rest as well, please, just whatever is your guess on each one of these. Okay, I'm stuck at 11. Okay, 12, one more response and I'll just move on to the next part. And maybe just wait—ah, 13, great! Thank you, 13th person.

Let's now dive in to see what actually can be done when we are creating data for agents or what needs to be done, maybe. So the sequence has been that earlier data was for programs—of course, humans at first—now increasingly it's for agents. But we have some basic problems. First is my data's not clean and therefore we need to build a data lake to organize it, we need to fix the data quality as well. Data quality becomes a pretty critical challenge.

Let's take the same problem that we spoke of a short while ago, which is: supposing we have to reconcile three customer masters. I'm just curious, how many people said less than a day? How many people said less than a week? How many people said less than a month? How many people said less than a year? Fine. So a week to a month seems to be the median effort. **Let's see if we can do it in minutes.**

[Dataset](https://files.s-anand.net/pages/customer-masters-data/)

And here is a dataset. There are three CSV files. One is an origination file. So the loan origination team has come up with, "Here are all the customers that we've been dealing with." Let's say it's not even a complete list; it's, "Here's a snapshot of a bunch of people from our origination database." They've given a dump. And their dump has a customer ID, the customer name, so Mr. Amit Kumar Gupta, who was born in 1998 on 14th of March, with a certain PAN and email and phone number, etc., is the data that we have.

There's another team that has the collections data and their customer records look like this, which is, again, Mr. Amit Kumar Gupta—the "Amit Gupta" will appear multiple times, I've consciously put Amit Gupta on top for other reasons—with a certain phone number, has 45 days past due and has a certain amount outstanding. Now, by now you know why there won't be an overlap, partly because there may not be a collections outstanding for a certain number of people. But we still want to standardize because "Amit K. Gupta" is "Amit K. Gupta" the same as the "Amit Kumar Gupta" that we had in the origination data? Probably. But let's look at the phone number. Okay, ends with 2210. Out here ends with 2210. Yeah, very good chance that it is the same Amit K. Gupta who is Amit Kumar Gupta because the phone number is matching, PAN also I can probably do a match and see.

Now this is something that we would do, reconcile manually otherwise. And now there is an AK Gupta with the same WhatsApp number which is coming from the CRM, which is useful. But there's also an A. Gupta. Now A. Gupta could also be Amit Gupta, and that's a little confusing. So we'd have to be a little careful about these kinds of deduplications. For someone to do this, understandably, if they do a reasonable amount of automation, a week to a month sounds reasonable.

What I will do and request all of you to do is go to this page. The link to this page is here. Please open this and I will tell you what you can do on your mobiles. We'll see how far we get. This will open the same link that I just showed you. Okay, I see most of—okay, one, two phones still up. I'll give you a few seconds. Okay, one phone still up. Great.

On this page, you can download the whole thing either as an Excel sheet or as a zip file. It contains the same data that I just walked you through. There is one sheet that I didn't walk you through, which is a university master that has the list of universities that have been listed against these individuals. And there are some problems in that also; it is not perfectly deduplicated.

So I had tried a prompt earlier this morning and it isn't a particularly intelligent prompt. I'm going to try that along with you, which is the following. First, I'm going to go to ChatGPT—and I'll invite you to open ChatGPT or Claude or whatever—and you could copy this prompt and paste it there. I'm just going to first upload the same file... customer master data, yeah. I'm going to upload the Excel sheet—you could have uploaded the zip file, it doesn't matter.

And let's talk to it, which is what I did this morning, which is: **"These three CSVs come from three systems: loan origination, collection, and CRM, plus a university master. They share no common key, names are inconsistent, and IDs changed across systems. Reconcile them into a single customer master. For each match, give a confidence score, the fields you matched on, and a one-line reason. Tell me if anything has a score of less than 0.8 so that I can review as a human. Don't merge records that only share a similar name. Also, reconcile the university codes against the master and tell me which codes are the same institution under two different IDs. Give the reconciliation table plus a list of any exceptions and suggested fixes to the master data."**

[ChatGPT conversation](./reconciliation-chatgpt.md)

Not an unreasonable prompt, and this is the kind of thing that somebody would be telling their team member to do. I find it so much easier to just talk to it because that way I can also think while I'm speaking. If I ramble, it does a good job of picking stuff. This is what I'm requesting you do. You don't necessarily need to speak to it, though you're welcome, just upload this dataset, upload this prompt, and run it. Let's take half a minute. Just give it a shot. You can use Claude, you can use ChatGPT; Gemini might work, not sure—whatever is the coding agent of your choice. And then once you're done, we'll ask that you share the URL. Let's just see which AI agents have done what and so on. We'll come to that in a short while.

But what I'll do is take you through—sorry, does anyone need a link to this again? No? Okay. Let's see what it did. It generated across 6 minutes and 23 seconds—and this is just ChatGPT, no sophisticated agent. I'm using a $20 version, something that every single employee is able to. It has, as you might have expected, done a reasonable job of generating a spreadsheet that has the...

[Reconciliation report](https://view.officeapps.live.com/op/embed.aspx?src=https://files.s-anand.net/pages/customer-masters-data/reconciliation.xlsx)

First, it generated a summary of what it did, which is: there is a master customer ID for each of the customers that it could identify. That's a longish list linking to where it got the person from. So here is the CRM contact ID. There is no collections equivalent for this person. There is no origination equivalent for this person and so on. And the collection account numbers... effectively we have a shot at what is the master dataset.

And it also says, "Here are matches that I'm clearly accepting. This match is working because on the right side, origination is matching, collections is matching." So Amit Kumar Gupta, Amit K. Gupta, etc., all of these six on the left and the right, **I identify as the same person and have given them the master customer ID of 21. It is reasonably confident in that in that it's saying 99% sure because the phone number is matching, the masked PAN is matching, and the email is matching.** In this case, two of them are matching. It effectively has its own—based on just this prompt—has identified how to match, what weightage is to give to each one of these. It has a reasonable intelligence based on reading literally everything that one can in the world.

And no human review is required for this, but there are reviews required for humans for some of these. So Sneha Iyer, for instance: is Sneha Iyer the same as S. Iyer? Maybe. Is Arjun Rao the same as AD Rao? Maybe. The fields that are matching... so what it's saying is the phone number, for instance, for Arjun is a match and the name evidence is in conflict. Just maybe double-check on the PAN number. It'd say, "Look, if two people have the same phone number and one is an Arjun R. and the other is an AD Rao, probably..." But okay, just a quick guess. **If you were reconciling this and two people have the same number, one is an Arjun R., the other is an AD Rao, would you pass it?** If yes, please raise your hands. Would you not pass it and say these are different people? Interesting. I'm not an SME. I would have happily passed this, but I'm learning something today, thank you, that you would not just directly pass it, you'd probably do a second round of review. And the confidence score that it assigns in this particular case is a 0.7, probably is a more reasonable threshold and it should go through a human review.

Now it did this because we asked for it. Again, we aren't doing anything very sophisticated here. But apart from this, it also did the university reconciliation going through these and saying, "Here are a bunch of university duplicates." I'm not going to go through the details because yours will show this. And therefore, how you can go about fixing the individual masters and what is the methodology that it used to do all of this. **6 minutes 32 seconds. That is, at least for this iteration, considerably less than the week to a month effort.** But on the other hand, obviously we are not going to just take this as the final one, we are going to do some amount of work on top of it.

It acts as an accelerator. But what I'm finding is that **the power is not in the acceleration; it is in the enablement of stuff that people would otherwise have not tried.** Sometimes somebody says, "Look, I just need to know if this person is the same across all three. One-person check. How would I do it?" I would set up a project where somebody has to clean the entire data lake because it is not practical to do just one-off checks like this. Instead, we can do one-off checks. If I wanted to do a data quality audit—I just wanted to know as a percentage how clean is my origination dataset versus my CRM versus whatever—one shot, it becomes easy. Again, something that was not practical earlier. Lends itself to multiple uses, which starts making it powerful.

And as a result, what we're finding is that the ROI tends to be both—in some way, there are two kinds of ROIs that we're seeing. The first is where it replaces an existing task. One of my colleagues, Thanoj, he had to do this in one of our clients and I'm quoting verbatim. He said, "See, for the last four days, Anand, I've been using it so extensively. **The reconciliation would have taken me three to four weeks of work—fairly consistent with what you're saying would have been the median time—and now it's been crunched to two or three days."**

That was one example of a data point. Now, how did he do it? He was in the client organization, in their environment. We told him, "Why don't you play around with Codex?" "Sorry, Codex is not allowed." "Okay, Claude code is not allowed. Co-pilot, Co-pilot is not allowed." "Okay, what is allowed?" "**Cortex in Snowflake is allowed.**" "**Okay, use Cortex. Just ask it the same questions.**" And he did, and it works. It worked beautifully because it had access to all of the data.

Now this is a scenario where it was able to compress an existing use case, but the power was also that it was able to create a whole bunch of use cases. The way that happened was the second part of this: building semantic layers in between. One of the other challenges that we face is data may be now reasonably clean or we can take subsets of data or we can use the AI to identify what is unclean and maybe even clean up the data. The problem that we have now is I need to build an aggregation layer on top of it. I have to figure out what are all the joins to make. I have to figure out what are the ways in which we need to get the structure out of the unstructured data and so on. How do we go about doing that? Let's see with agents how that starts becoming possible.

Before that, I'm going to make a small change to the list of questions that we have and invite you to fill out a couple of additional questions. Same link, at the bottom—and if you have it open, great, if not it's on the screen on the right-hand side—two questions have been added right at the bottom. I am going to have to enter my authenticator code... yeah. The QR code is on the top right.

The questions that have been added: firstly, if your agent has completed it, please just click on the share button. The share button would probably be on the top right of your ChatGPT or Claude or whatever, somewhere out here, and just put that in here. I am curious to see if your agents come up with very different results. The primary thing is you'll get to see live a reconciliation getting done, and the number of reconciliations you and your teams have to do is fairly large. Okay, we're starting to see the results. I'm really excited to play this back to the audience and we'll do that in a few minutes.

Second, let's talk about: **supposing you have 10,000 documents and there are some three questions that need to be answered out of these documents.** Doesn't matter what kind of document—assume any document that you have that's realistic. Supposing one person says, "I want to find documents very similar to this particular document." Let's say you have RFPs, "I want to find another RFP very similar to this RFP." I have a loan application, "I want to find a loan application very similar to this." I have a patient record, something very similar to this. And another person says, "Look, I want to find out across all of these documents—maybe they're project reports, maybe they're marketing proposals. What is the correlation between some value and another value—say, is marketing really leading to an improvement in spend?" Third, somebody is saying, "I want to trace the investor lineage." What he means by that is: I want to figure out if this company has invested in that company, that company has invested in another company. Effectively, what that means is the data structure that is required is now very different; you need to have some kind of a chain, a knowledge graph.

Now, each of these require a very different aggregation structure. This one will require some—tracing the lineage will require some kind of a knowledge graph sort of structure, some graph structure. Correlation will require some kind of a tabular structure. Similarity will require some form of vector embeddings, and then you start finding out what is the similarity between two documents. Very disparate.

What's your guess? Should we handle these by putting in one store—simple, but may not be efficient—or a different store per question, different data structures for every question, in which case we may need to anticipate? Not sure. Something else? Whatever, just curious to see what your responses are on this. Okay, we have a couple of responses to where you've shared your customer masters, but please do—I'll give it a minute or two for you to add any more. And I'll also in the meantime just pause for any comments or questions so far from what we talked about, with the key takeaway being: **sometimes you can just upload your data into an agent or give an agent access to your data, and it will solve half the problems, and if it doesn't, you're no worse off.**

Any.questions?

**Vivek**: Just a quick question—but full disclosure, right, I didn't know about Anand's presentation. And and but this so happens to be close to two of our companies with similar topics. Maybe A___ or R_____, do you feel this is similarities or anything that you want to share?

**Audience**: So I think very interesting—so I think very interesting use case and, of course, this is also something that we are also trying and, you know, whatever you are leveraging, I think we are also leveraging that. I'm using Claude Code to do most of this, but at the same time, I think my approach is slightly different there. I'm not really uploading the data as such, but I'm just sharing the metadata of my own data structure. And just using just the metadata information to do this reconciliation of sorts, given that, you know, it's a regulated industry, so I'm not very sure if I should be uploading the data to any of these LLM models. But yeah, I think—I think this is something that we are already trying and of course, you know, the speed to do this has like—it's very significantly higher. So yeah, I'm looking forward to what else, you know, we can do there.

Let's take that itself. So supposing I can't send the data. Now if I send the metadata, I have a slight slowdown, which is then it'll give me a program, I'll have to run the program, and then I'll have to tell it, "Look, you missed 20 things." **I want that loop to be automatic, and MCPs [Model Context Protocol] can come in pretty handy in such a scenario.** One of the ways in which we can do that—and let me see if I can set up a quick MCP server and let's give it a shot.

The form server may go down for a few seconds and it should be back up now. But what I've done is run an MCP server on my—think of it as a server, but it's really my laptop. And we can go to ChatGPT or Claude or whatever, now connected to this system. And this has access to do a couple of things. It can write and run scripts on my system. It can access metadata; it cannot access the actual data. How? Because I told the MCP server that way.

And therefore, we can now start running it in a loop. So I will tell it the following: "There's a folder whose location is below. What I want you to do is go through all the CSV files in that particular folder and create a reconciliation report. Specifically, I want you to match the customer IDs across all of these and create a full master. Now here's the thing: I don't want you to access the actual records. I want you to write programs that will execute on the local MCP, and you can write the programs in a way that will give you whatever metrics you need to figure out if the results are right, wrong, what is the level of accuracy, etc., and iterate as required so that you can get to a better result. This is part A."

"I want you to do this in two different ways and evaluate the effectiveness of the two approaches and settle on which of these is the better approach so that I can be informed and do this in the future. Thirdly, write this as a script that I can rerun so that tomorrow if I get new records in these CSV files, I don't have to again use the agent capabilities—just running the program ideally should solve the problem."

Now let's run this. The only other thing that I need to do is tell it where in my machine this is located and make sure I've given it access... okay, I have not given it access, bear with me. Files... okay. The files are at [Anand typing file path] tilde R2 files... sorry, I just need to locate the server pages customer masters data, okay. And run it.

**Because the local MCP server is doing the hard restriction, I don't have to worry about data leakage.** On the other hand, I can very comfortably make sure that the analysis that it is doing is both verifiable, because ultimately it's going to give me a program that is deterministic, and it's going to give me an error report which I can cross-check. So now it's running the commands on my machine, which could be any server, and getting the job done.

There are a couple of things that we tried here. One is: how do we not expose data, only the metadata, but also short-circuit the loop? Any agent we ought to be able to do this, therefore preserving privacy while at the same time getting the benefit of acceleration. The second thing was: we asked it to do it in two different ways. I know it's probably... okay, I should change the appearance to light mode so you can see this better. Yeah, this is definitely better.

"I want you to do this in two different ways and evaluate the effectiveness." Because it's cheap—not in the token sense, but in the human versus machine sense, significantly cheaper and faster—asking for multiple options generally makes sense. But multiple options is not just in terms of output, but in terms of approach as well. A good way is to tell it, "Take a sample. You don't need the full data. Try half a dozen different models. See which model works and get the job done."

**It is not just the coder who is getting replaced; it is the data scientist who is also getting replaced.** And from a skill perspective, what that means is the same kinds of strategies we've been applying for the software development life cycle are equally applicable to the data development and model development life cycles as well. And that has some pretty strong implications, meaning like we can do vibe coding—anyone randomly creates an application which has benefits and creates its own series of problems—**people can now do "vibe data analysis." The business user can just randomly take a data set and start playing around with it, and that is powerful.**

Which is actually what—okay, this thing is still going ahead, we'll see the result in a short while. And this is the kind of thing that... [Anand debating which slide to show]... yeah. So this is something that we tried in Straive.

[HR Analysis](./hr-analysis.html)

There is a shared Google Drive that has a lot of HR data. Let's see what that Google Drive roughly looks like. [Anand typing] bizops people. This is the people folder, and somewhere inside it, it has a huge number of documents—47,000 documents across all kinds of things.

I have no idea what's sitting in these documents. So my ask was: can we, just by talking to it, find something that the HR team doesn't know? Prompt number one: I said, "Look, use this tool which can connect to Google Drive"—think of it as roughly an MCP for Google Drive; it's actually just a command line application that can connect to my Google Drive. So, step one: give it access to the data. Don't clean the data, don't format the data; I'm not saying you shouldn't, but I'm saying I didn't.

And then I said: "Explore the data sets that are accessible to me." The good part is we already have systems where access controls are well-established, so what I have access to, I have access to; no additional layer of governance is required. And "write a repeatable script that updates incrementally all the new or modified files and store the output as datasets.json." In other words, I'm saying, "You get all the files from that HR folder, put it here. Tomorrow if there are new files, I want to make sure that you don't have to download the whole thing, just get it to my machine." Why not let it run on the server? I have more tools on my machine, so if we had those same tools available on Google Drive, then great. But Google Drive only offers a simple search; I have better search and converters on my machine, so I said, "Bring it over here."

Now what it did was, firstly, just extracted all of these—this is an example of one file that it downloaded. Second prompt was: "Now tell me what is relevant. Look at what is recent. Look at the size—more data means more information. Is it transactional or static? What is the richness of the project? And based on this, tell me how I should prioritize data sets and tell me what are the most important data sets I might analyze."

It automatically decided on the weights. Now, if I were a subject matter expert, someone in HR, I might have a point of view on this. I might say, "No, no, see, the project richness may be more important, recency is less important, data density and all is okay, but what really matters is we are doing more hiring, therefore place hiring higher, next is learning." Those sorts of things it would have commented and if I were an HR professional running this, I would review it at this stage.

But I didn't because I'm not. And it shared a relevance score and said, "Look, for instance, here is an employee plus exit master sheet, and you can build an offer joining funnel from this which will—you can also figure out how attrition happens." Create the series of things. Notice two things. A: **ETL is a solved problem, that you know. Discovery is also becoming a solved problem.**

And I find that the discovery part of it is something that not many teams are recognizing—meaning you as an audience are probably well aware of this, but are the people that you are interacting with as aware of this and leveraging it? Maybe not. And this is one of those things that's worth socializing, and very easy to socialize because all you have to do is point it at some reasonably large catalog and say: "Find interesting stuff. Find problems that I can solve."

It scanned all of this and built the structure by itself. What I mean by "built the structure by itself" is if I had been asked, "How do you want to catalog all of the HR data?" I might have picked one single table. The trouble with picking one single table is that we lose the stages that, for instance, a CV goes through; it doesn't necessarily go through a linear cycle, a CV goes through multiple stages and possibly with cycles. I might have picked a time series. But the entity or the key unit is not time; it probably is the "state" of an employee, with the employee being the primary unit that we should analyze on. Which is what it did. The data structure that it built looks roughly like this: against each employee, it mapped them against the state, it mapped them against which company they came from, which location they came from—**effectively implicitly creating a knowledge graph on the fly.**

Not a difficult point. But here is the thing. **Normally, I have been used to thinking of software as the primary product.** That is, we use AI coding agents to build software, and software is important, needs to be maintained, and the software by the way generates an output which happens to be a data set, it happens to be a report, etc. **That seems to be shifting.** The output is coming through directly; I have not read the code. In fact, I don't even know where the code is.

In some of these cases, it is writing code on the fly, meaning it writes an inline Python script, it doesn't save it anywhere because it doesn't need to—it's testing out a bunch of things—and then finally because I asked for it, it produces an output. Which means that **"ephemeral software" is now becoming a part of the reality as part of the entire data science lifecycle.** We get the answers; software is there, by the way.

Which has led us to a thought: maybe there's a market for this. Clients often come back and say, "Oh, my niece uses Claude Code to do this, why should I pay you?" Okay, that may just be a negotiating conversation, but it does negotiate the price down. I'm fighting for a depreciating asset: software. Why bother when the power of what we can do with an AI coding agent is so high and where the output is valuable? Why should I fight for the software? Software is getting built on the fly, I may as well price the output and tell you, "I will get you insights instead." Who cares about the software?

And insights we did get. For instance, we found that hiring—in the hiring process, the problem isn't recruiting, it is the paperwork after the offer. See what happened was two teams were keeping the same hiring list—duplicates—and a lot of the delay was happening in the setup: you decide to hire, okay, now let's make sure that the laptop is allocated, the IDs are set up, and so on. And just two projects were driving the bulk of this. That is where a significant chunk of the bottleneck happened. And so on.

KYC is not the problem for payroll; there is one particular dashboard which is actually stale that people are not using, and no, the finance team is not aware that the process that was updating this particular file was broken—it had been broken for a few weeks now. And things like this. Actually actionable stuff. Total duration: about two and a half hours. My attention span: two and a half minutes.

This is something that works across multiple scenarios. Let me share what happened with Thanoj, whom I spoke about earlier. What he did was, again, no Co-pilot, no Claude, no Codex—sorry, he has Cortex inside Snowflake. And he said, "Let me do a data discovery." On top of that, "Let me also see if there are interesting use cases that I can find." Same set of prompts: "Do a relevance of these data sets, tell me what kind of use cases it can solve."

[And Cortex produced this](https://files.s-anand.net/pages/ai-use-cases-commercial-data/).

This is an anonymized version of the actual report that it produced. It said, "Look, there is a fair bit of opportunity here and here are 15 use cases. These 15 use cases can be solved... here's a prioritization: you can do a revenue analysis, revenue forecasting, pricing anomaly detection—those are your top three priorities. Standardize the addresses, do entity resolution, etc. What is the value that you are likely to get? What is the timeline that it might take? And who is the audience that would be interested?" And it gave a list of individual names whom Tanuj should take this to.

He went to their head of data analytics, and said, "Here's something that we've been exploring." He said, "About in November, we hired a consultant. That consultant did a two-and-a-half-month strategy exercise. 12 out of these 15 are what they had recommended." Okay, good. **It's not just the SDLC [Software Development Life Cycle] that we can augment, it's not just the data scientist that we can augment, it is the strategy consultant that we can augment.** Very happy, good.

Of course, keep in mind that you know this. The people you're talking to might not strike that. And therefore, part of what we need to look at is if the cost of a consulting exercise has fallen from a few hundred thousand dollars to a few hundred dollars—which is the token cost—send it. What is the harm? Do a few consulting exercises, ten of them go into the trash can, big deal; one of them clicks, good enough. One in a thousand clicks, that's ROI. Huge ROI.

And it's not, therefore, yeah, not just discovery, but use case identification also. And keep in mind, this is a data scientist who knows not too much about the business, and the agent—which is as smart as smart professors—is using its knowledge of the business to figure this out. And then he said, "Anand, let's pitch for all these cases." I said, "Yeah, what will happen if you pitch for these?" "Well, we'll be able to build the applications that will deliver it." "Why pitch, then build? Build, then pitch. How long is it going to take you?"

Thought for a while. And two weeks later, he comes back with all 15 of these completed simply by just prompting. Let's stop at customer churn. So, did the standard exercise, analyzed the process, and finally each one of these has one email. The email is directed at the stakeholder that says: "2,217 customers have either left or about to leave. That's a $117 million impact, and you can act on about $37.5 million of this. Real moves."

And here are anonymized customer names, but this is the kind of revenue—this customer is probably already gone, but here are the customers who are slipping now, and if you start working on this, you can do some stuff. And by the way, you don't have an early warning system; one to create an early warning system for you might be worthwhile. Who are the customers you probably want to keep a slightly closer watch on and all of that? This went as an email to that stakeholder. Maybe this is not relevant, maybe this is not priority, but certainly was inexpensive.

What that leads to is: something that would have taken 4 times 17 weeks—as per its identification—got crunched to 3 person-weeks. Identification plus execution—that is elapsed time, Tanuj had other stuff to do, he was doing it on the fly. But the entire data cycle... if I look at this as a takeaway, is: **agents are able to let anyone find data sets—that's the discovery part—clean the data sets, organize the data sets automatically—you don't need to sit and figure out what is the schema—analyze it—that we know it can do—but the important thing is that when it does it in a loop, even if you just give it metadata with the ability to execute code, it is able to do it without human intervention—that's pretty powerful—verified—I know we haven't really talked about verification, but when we get to Q&A or whatever, let's explore that—and present the data.**

And what I mean by "present the data" is it does not have to be a dashboard. **What is a person going to do with the dashboard? They're going to think and figure out what actions they need to take. Tell them the actions.** An email telling them, "Do this, here is the benefit, and here is the evidence," is all we need. And arguably, this is what "forward deployed engineers" are meant to be doing. We don't need forward deployed engineers only with clients; we can deploy forward deployed engineers internally as well. Just somebody saying, "I have data, let's solve problems with it," is a forward deployed engineer—I don't know, maybe call them "internally deployed engineers," whatever.

But what that therefore leads us to is: the cost is low, maybe we'll try it—what is the harm? Toss data sets at models or toss agents at data sets and see where it goes. Ask a few people, "Look, this sort of a thing seems possible. You want to try it internally?" With—and I've been running a few of these sessions, getting a dozen people in. Out of those dozen, two show interest, one actually converts. That's one more than zero, and then things start spreading. So that way the risk is relatively low, the effort is relatively low, and the benefit can be high. No harm.

With that, let me ask you a couple of last questions in the light of what we discussed. [Anand typing] https://forms.s-anand.net/datastack/. The last couple of questions are the same question as the first one: **now if your team comes back and says, "I want to reconcile a bunch of data sets," how many days would you suggest for them?** How many days would you tell them this ought to take? Same problem. Arguably you have the answer on your phone, literally quantifiable, but I'm just curious—in practice, what are you going to tell them? And is there an easy, no-risk move that you might be able to start this week? What comes to mind?

---

As you think about these, please share answers. I'll open for questions in just one minute, but the key thing that I want you to take away is: **agents can solve the data life cycle problem as well as it can solve the coding life cycle problem.** And that is a different cycle, different dynamics; it's slightly behind the curve compared to SDLC—most of us haven't explored it—might be worth exploring. Thank you.

[Applause]

Questions? Yes, please.

**Audience**: Thanks for the session, very helpful. We tried a similar thing in our company, but we were not as lucky as you. I'm just joking, I just wanted to take your mind share on one of the key things—like a similar thing I tried and out of multiple documents converted that into one CSV file with the data source, everything. But the results, when we showed it to business—the similar kind of PPT—and then they said, "These are not matching." And at that time it became low, because whatever best our team could have done, we did. Business team said that, "No, it's not matching and we're not interested."

No, which is a very fair point. The word you used there, "lucky," I think is very apt. Sometimes these work, sometimes these don't. And I look at this from three perspectives. **It's a portfolio approach. If you commit and don't deliver, it's a problem. Don't commit, deliver, and ask, "What mistakes am I making?"** Position it very non-threateningly.

There are many reasons why the person at the other end doesn't want this done, or doesn't believe this is right, or doesn't believe it's even possible. It's a discovery exercise in that as well, which is what will fly, what will not fly. But since the cost is low, I spread this across twenty different areas, share this with twenty people; two of them say, "I like it," I don't even bother with the ones where it's gone wrong or it's not accepted. Which is not necessarily the best solution in the long run, but it's a good starting point.

The next thing is post-mortems. I take that feedback, pass it to the agent. I run a small innovation team. One of my team, Pavan, his role—I've designated it as "**Human as an Interface**." His job is to listen to a bunch of people—Ankor, Straive's CEO is one such person; Ritesh, who's on the customer-facing side, is another such person. For instance, when Ritesh says something on a call, Pavan records it.

My instructions to him are: "Do not apply your brain. You do not know sales. You do not know the clients. You actually don't know much—you're literally fresh out of college; actually, in some cases, you're not even out of college. Transcribe that—Gemini does a good job. Put it into Claude—you have the connectors that I've given you access to. Take its output, give it back to Ritesh."

A week later Ritesh says, "Anand, this guy is so good, where did you find him?" In many ways, the feedback loop is powerful because he is very comfortable saying "yes" to everything; he has no idea what is possible, what is not possible. Claude is smart enough to infer from what Ritesh is saying and give it back. The turnaround time is dramatic. And as far as Ritesh is concerned, he has gotten an intelligence as smart as a professor that he can relate to. Now, asking Ritesh to work with Claude won't happen, but this solves the second problem: **Human as an Interface being a layer.**

Third thing is, when it fails, I just make a note—I maintain a small "impossibility list" saying: "Okay, on this particular day I tried X and this failed with this particular prompt." Periodically, I revisit. There are two ways in which I revisit. The first is a post-mortem: have an agent go through the logs and say, "What are the ways in which you went wrong? Why did you go wrong?" including with the feedback. That sometimes helps, and where it goes wrong in the same way multiple times, I convert that to a skill. The second is just to take a look at it three months later: does it still fail? Because the models and agent harnesses are constantly improving.

**Audience**: I just want to share two examples that we have succeeded in. One, finance team came back and asked, "Are there employees who are also vendors?" Right? So, we used these models and very quickly—he thought we would develop things, it would take a month or so—within three days we gave the data back: "These are the employees who have similar phone numbers, similar email IDs, etc." and very quickly they were caught.

**Audience**: The other example—recently we had a policy that if you have a relative, a close relative who is staying with you, you need to declare it. So, again we deployed the model to see, for example, if the ZIP code is same—obviously they may not declare there is no wife or somebody—so through those addresses, ZIP code, we traced that quickly and then gave back the information. This was quite useful for us.

Fascinating, right? **What people often don't explore is cross-domain stuff.** And vendor—okay, that's procurement; employees—that's HR. Once you start connecting across, it becomes fantastic. Again, somebody who has access will be able to pull together a whole bunch of more things.

If you have any questions we can take those, but otherwise I'm going to do one last thing, which is: we've got a bunch of responses that we have looked at. I'm going to take those responses and feed it back to Claude. And not even going to give it much context other than to say, "Here are the questions and here are the answers."

[Speaking to microphone] I was running this session on using agents with data and asked a few questions to the audience. Here are the responses to those questions. What I'd like you to do is use the data analysis skill and identify the most insightful responses that I can share.

[Claude survey analysys](./survey-analysis-claude.md)

Now, this data analysis skill is simply a longish prompt where I've told it how I want it to do data analysis, and it has in the past proven reasonably effective. But you'll notice something about this as a pattern: the survey responses are data. We are analyzing it live. I'm not preparing the data. I'm just telling it, "Get the job done."

This might get it done in time—maybe in the next three or four minutes—which means that as a cycle time, you can run this in a meeting. Take the transcripts—Google Meet or Zoom or whatever, they all give transcripts—you can literally copy-paste, take that, put it against a connector, have it run, get the results, feed it in.

Imagine doing this in a board meeting—even a far less important meeting, for that matter. Which means that **the agent actually is being brought to the table.** When people say, "Let's bring agents onto the table," a lot of them assume that the agent has to speak or we have to interact with it by typing. Not necessarily. Human as an Interface works quite well. Just one person sitting in there, even if it is somebody who knows nothing, can simply take the whole thing, transcribe, and get the results.

Interestingly, what you—on the first question—you're not really disagreeing. You're not just disagreeing, you're disagreeing on the order of magnitude. Before the demo, we estimated that reconciling the three masters could be one to sixty days—a sixty-X spread. And the median was six days—okay, interesting—about a week to get that done. Mean dragged up to ten by two outliers—and so on.

Great. And that spread is inside, but the reconciliation isn't being estimated like an engineering task; it's the "vibe." Half the room is quoting a sprint, the other half is quoting a quarter. Nobody is flinching that someone is ten-X off. Okay. So I'm supposed to say fifteen of you, your estimates ranged sixty-fold. Now obviously I could have just told it, "Give me what to say." Actually, let's do that.

[Speaking to microphone] I'm standing live in front of this audience. Give me the most punchy lines that I can read out.

Let it run. I will obviously share all of this with this group, but let's see what we can learn from each other. Yeah, no, this is worth reading out. Oh no, this is not... how often has it happened that Claude gives you stuff that—when you tell it to read out and it totally messes up?

**Audience**: All the time.

Yeah, no, that's just what happened to me. Okay, let's see. Data... okay, I had a contradiction. People guessed 40% on median is the usable data, but what's blocking—ah, this is the insight. Fine. **Broken data, data quality, unstructured data, siloed institutional knowledge, access issues, missing SOPs, and data security. No one said the agents aren't good enough.**

So, we all believe that 40% of our data is ready—fair enough—and what's stopping us is that the data is broken, locked, or unstructured. These two beliefs can't both be relaxed. And SS, your suggestion is 100% usable, but data security is a blocker, which is fair.

My thesis is maybe, after you've taken a look at this, that percentage may not be as high as you think. Just worth thinking about. I'm not going to add another question to see how much your perspective has shifted. But do explore if that perspective has in fact shifted.

Since we started a little behind, I don't want to take extra time in this session. I will repeat and end with that same takeaway: **agents are able to let anyone find, clean, organize—and the discovery part is important—clean, organize, whatever, and get all the way to a verifiable result. No harm if it doesn't work. Try it out in parallel with SDLC.** Give it a shot, please.

[Applause]