The Pre-ReadThe instruction in Vivek's pre-read had been four short lines, and Anand began by reading them back to a room that — he gently noted — may or may not have done the homework themselves. "You may have read it, of course," he said, "or your agents may have read it." The joke landed because it was already half true. The whole hour would turn on that small inversion: the audience was no longer the only reader in the room.
The four lines were deceptively quiet:
Dashboards are for humans
Data, increasingly, is for agents. Everything we learned about designing data for people may need a rethink.
The question sets the shape
The question determines the aggregation — not the data type. So stop pre-building joins the agent can assemble on the fly.
Unstructured is an asset
Code reviews, meeting minutes, chat logs — newly processable at scale, and newly valuable.
Provenance is critical
Old computers failed in known ways. AI fails in new ones. If we decide with data, we need to trace it.
It is worth pausing on the second line, because it quietly demolishes a decade of received wisdom. We used to take raw data and lovingly pre-build aggregates, joins, and star schemas — making certain questions cheap to ask and most others impossible. The bet was on anticipation. But if an agent can construct whatever shape it needs for whatever question arrives, the bet changes.
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.
— Anand, on why pre-built schemas are becoming optional
Section 01 · The WagerHow long does a week-long job take?
Before any demo, before any argument, Anand did something a salesman would never do: he asked the room to commit to a number, in writing, on their phones. A QR codeA live poll built on Anand's own form tool. The form — forms.s-anand.net/datastack — was switched off after the session, so the numbers below are the only record of what the room actually believed. went up. Three questions appeared.
The first was a trap dressed as a project-scoping exercise. A client hands you three customer masters. Each list has its own IDs, its own column names, its own spellings of the same people. Turn it into one clean, queryable dataset. A few tens of thousands of rows each — under 100,000. How many days?
The second: what percentage of your company's data could your agents actually use today? The third, open-ended: what's blocking you from putting agents on real workflows on top of your data?
He waited, narrating the trickle like a cricket scorer — "nine responses, ten… I'll just wait till we have a baker's dozen… ah, thirteen, great! Thank you, thirteenth person." Then he asked for a show of hands. Less than a day? Less than a week? Less than a month? Less than a year?
A week to a month seems to be the median effort. Let's see if we can do it in minutes.
— Anand, setting the over/under
What the phones recorded was sharper than any show of hands. Fifteen people answered. Their estimates ranged from 1 day to 60 days — a sixty-fold spreadFrom the live poll: estimates were 1, 1, 1, 2, 3, 4, 5, 6, 7, 10, 10, 10, 14, 20, 60 days. Median 6; mean dragged to ~10 by two outliers.. The median was six days. And that, as we will see at the very end of the hour, was the real story — not the height of the estimates but their scatter.
(1 day → 60 days)
Section 02 · The DemoThree systems, no common key, one prompt
The dataset was deliberately, lovingly messy — the kind of thing every bank in the room recognised instantly. Three CSVs from three teams, plus a fourth file to trip people up. You can download all of it yourself; the room did, live, on their phones.
Origination
Loan applicants. Full names, DOB, masked PAN, email, phone, loan amount, a university code. "Amit Kumar Gupta," born 1998-03-14.
Collections
"Amit K. Gupta," 45 days past due, ₹412,000 outstanding, phone ending 2210. Same person? The phone says yes.
CRM
"A.K. Gupta," same WhatsApp number — and, lurking nearby, an "A. Gupta" who might be someone else entirely.
University master
The hidden fourth file. "University of Texas at Austin" and "Univ. of Texas Austin" under two different codes. Not deduplicated.
This is the work. It is unglamorous, it is endless, and it is exactly the work a team would scope at "a week to a month, if they automate reasonably." Anand's twist was to do it badly on purpose — with a prompt he admitted "isn't a particularly intelligent prompt," typed into a $20 ChatGPTNo enterprise agent, no fine-tuning, no orchestration framework. "Something that every single employee is able to" run. The whole point: this is the floor, not the ceiling. account that "every single employee is able to" use.
These three CSVs come from three systems — loan origination, collections, 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 I can review as a human. Don't merge records that only share a similar name. Also reconcile the university codes… Give the reconciliation table plus a list of any exceptions and suggested fixes.
— The entire "engineering spec," spoken aloud into ChatGPT
Notice what's hidden in that ramble. There's a human-review threshold (0.8). There's a safety rule (no name-only merges). There's a request for provenance (matched fields + a reason). It reads less like a query and more like the instructions you'd give a careful junior analyst — which is precisely Anand's point about why he prefers to talk to the model:
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.
— Anand, on dictation as a thinking tool
Six minutes and thirty-two seconds later, ChatGPT was done. It had turned 500 source records into 201 reconciled customer entities, with 691 accepted record-pair matches and 82 candidates flagged below the 0.8 line for a human to review. It did exactly what the prompt asked — and, crucially, it showed its work.
I identify [these six records] as the same person and have given them the master customer ID of 21. It is reasonably confident — 99% sure — because the phone number is matching, the masked PAN is matching, and the email is matching.
— ChatGPT, narrating its own evidence for Amit Kumar Gupta
Then came the moment the room actually taught Anand something. On the screen sat a borderline case: an "Arjun R" and an "A.D. Rao" sharing a single phone number. The names conflicted; the phone agreed. ChatGPT had scored it 0.7 and kicked it to human review. Anand turned it into a vote.
If two people have the same number, one is an Arjun R. and the other is an A.D. Rao — would you pass it? … Interesting. I'm not an SME. I would have happily passed this — but I'm learning something today: you'd want a second round of review.
— Anand, discovering the model's 0.7 was wiser than his gut
That is the quiet inversion again. The machine was more conservative than the human expert's instinct — and it was conservative because the prompt told it to be. The intelligence wasn't in a clever algorithm. It was in a model that had "read literally everything one can in the world" and then been handed a sensible rule about when to stop trusting itself.
The university file got the same treatment: "University of Texas at Austin" and "Univ. of Texas Austin" collapsed into one, "National University of Singapore" and "NUS" into another, IIT Madras, IISc, Stanford — five duplicate-code groups caught and a canonical ID suggested for each. And, tellingly, the report ended not with an answer but with a process: store irreversible hashes of identifiers, make at least one stable ID mandatory per source, keep blocking name-only merges. It had quietly written the room a better data-governance policy as a free side effect.
Everyone expected acceleration. What Anand insisted on was something subtler:
The power is not in the acceleration; it is in the enablement of stuff that people would otherwise have not tried.
A one-person "is this the same customer across all three systems?" check used to be impractical — you'd have to fund a whole data-lake clean-up to justify it. A "what percentage of my CRM is actually clean?" audit was never worth a project. Now both are one prompt. The cost of a question fell low enough that questions nobody bothered to ask become routine.
Section 03 · The Two ROIs"Cortex is allowed"
The first kind of return is the obvious one: a task that existed gets compressed. Anand quoted his colleague Thanoj verbatim — a man four days deep into using agents inside a client's environment:
The reconciliation would have taken me three to four weeks of work — and now it's been crunched to two or three days.
— Thanoj, almost exactly matching the room's median guess
But the how is the best small comedy of the talk. Thanoj was inside a regulated client. The conversation went like a customs interrogation:
"Why don't you play around with Codex?" — "Sorry, Codex is not allowed." — "Okay, Claude Code?" — "Not allowed." — "Copilot?" — "Not allowed." — "Okay, what is allowed?" — "Cortex in Snowflake is allowed." — "Okay. Use Cortex. Just ask it the same questions."
— Anand, on finding the one unlocked door
And it worked beautifully — precisely because Cortex already lived next to the data. No exfiltration, no approvals, no new vendor. The lesson isn't "use Snowflake." It's that the agent only has to be wherever the data already is allowed to be. Which leads directly into the objection that a sharp audience member raised next.
Section 04 · The Objection"I can't send the data"
An audience member from a regulated industry raised the obvious hand. He was already doing this with Claude Code — but cleverly: "I'm not really uploading the data… I'm just sharing the metadata of my own data structure." Smart, safe, and slow. Because metadata-only means the model writes you a program, you run it, you find it missed twenty things, you go back, you re-run. The loop has a human stuck in the middle of it.
I want that loop to be automatic. And MCPs — Model Context Protocol can come in pretty handy in such a scenario.
— Anand, reaching for his laptop
Then he did the thing that makes a demo memorable: he built the fix, live. A small MCP serverAn open protocol (originally from Anthropic, now widely adopted) that lets an AI agent call tools and read resources on a system through a controlled interface. The agent gets capabilities, not raw access. running on his own laptop, connected to ChatGPT. It could do two things, and — critically — only two: write and run scripts locally, and read metadata. It could never see the actual records. Why? "Because I told the MCP server that way."
Because the local MCP server is doing the hard restriction, I don't have to worry about data leakage. On the other hand, the analysis is verifiable, because ultimately it gives me a program that is deterministic — and an error report I can cross-check.
— Anand, on privacy and verifiability as the same move
The instruction he gave it was a small masterclass in delegation. Reconcile the masters by writing programs that run locally. Do it two different ways and tell me which is better, so I'm informed for next time. And write it as a rerunnable script, so tomorrow's new records need no agent at all — "just running the program ideally should solve the problem." Privacy preserved, acceleration kept, and a deterministic artifact at the end.
Why ask for two approaches? Because the economics have flipped:
It's cheap — not in the token sense, but in the human-versus-machine sense. So asking for multiple options generally makes sense. Take a sample, try half a dozen different models, see which works, and get the job done.
— Anand, on portfolio thinking at the prompt level
It is not just the coder who is getting replaced; it is the data scientist who is also getting replaced.
And from there, the sentence the room would remember. If software people can "vibe code," then —
People can now do "vibe data analysis." The business user can just randomly take a dataset and start playing around with it — and that is powerful.
— Anand, naming the next wave
Section 05 · The 47,000 DocumentsDiscovery is now a solved problem
The reconciliation showed agents cleaning data. The next story showed something stranger: an agent discovering what's even there. Straive has a shared Google Drive of HR data — a "people" folder containing, by the agent's own count, 47,000 documents. Anand's honest starting position:
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?
— Anand, on auditing his own ignorance
He pointed a command-line tool (think "MCP for Google Drive") at the folder and gave it three deliberately lazy prompts. Explore the datasets I can access. Write a repeatable script that incrementally pulls new or modified files. Then tell me what's relevant — by recency, by size, by whether it's transactional or static, by richness — and prioritise. No cleaning. No schema. No subject-matter expert.
The crucial point he kept returning to: access governance was already solved. "What I have access to, I have access to; no additional layer of governance is required." The agent simply inherits the permissions its human already has.
ETL is a solved problem — that you know. Discovery is also becoming a solved problem. And the discovery part is something not many teams are recognising.
— Anand, on the part everyone skips
Left to choose its own structure, the agent didn't pick a single flat table or a time series. It realised the natural unit was the state of an employee over time — and mapped each person against their state, their previous company, their location, building what was, in effect, a knowledge graph nobody asked for.
It effectively, implicitly, created a knowledge graph on the fly.
— Anand, watching the schema design itself
And it found things. Real, awkward, useful things — the sort that no dashboard would ever have surfaced because no one knew to build it:
The bottleneck isn't hiring
It's the paperwork after the offer — laptop allocation, ID setup. Two teams kept duplicate hiring lists, and just two projects drove the bulk of the delay.
A dead dashboard
KYC wasn't the payroll problem. One dashboard had quietly gone stale — the updating process had been broken for weeks. Finance didn't know.
Total duration: about two and a half hours. My attention span: two and a half minutes.
— Anand, on the new ratio of machine work to human attention
Section 06 · Ephemeral SoftwareWhy fight for a depreciating asset?
Here Anand made his most quietly radical observation. We're used to software as the product — built carefully, maintained, and incidentally producing a report or a dataset. That order, he argued, is flipping. In these runs he never saw the code. He often doesn't know where it is.
It writes an inline Python script, doesn't save it anywhere because it doesn't need to — it's testing things — and then produces an output. "Ephemeral software" is now part of the reality of the data-science lifecycle. We get the answers; software is there, by the way.
— Anand, on code as exhaust
Which led to an uncomfortable but liberating business conclusion. Clients increasingly say, "my niece uses Claude Code, why should I pay you?" The honest answer:
I'm fighting for a depreciating asset: software. Why bother? Software is getting built on the fly — I may as well price the output and tell you: I'll get you insights instead. Who cares about the software?
— Anand, on what's actually worth selling
Section 07 · The Consultant in the Machine15 use cases, and a $117M email
Back to Thanoj — who, armed only with the allowed tool, asked Cortex not just to clean data but to find use cases. Same lazy prompts: score the datasets for relevance; tell me what problems they could solve; estimate the value, the timeline, and who'd care. Cortex came back with 15 ranked use cases, complete with named stakeholders to take each one to.
Then the punchline that made the room sit up:
He went to their head of data analytics. The man said: "In November, we hired a consultant. That consultant did a two-and-a-half-month strategy exercise. 12 of these 15 are what they recommended."
— Anand, on a quarter of consulting reproduced in an afternoon
It's not just the SDLC we can augment. It's not just the data scientist. It is the strategy consultant we can augment.
And if a consulting exercise has fallen from a few hundred thousand dollars to a few hundred dollars in tokens, the math on trying changes completely:
Do a few consulting exercises. Ten go into the trash can — big deal. One clicks, good enough. One in a thousand clicks, that's ROI. Huge ROI.
— Anand, on the new economics of the speculative
So Thanoj asked: should we pitch for these cases? Anand's answer reframed the whole consulting model: "Why pitch, then build? Build, then pitch." Two weeks later, all 15 were done — by prompting. One of them, customer churn, ended not in a dashboard but in an email addressed to the stakeholder:
2,217 customers have either left or are about to leave. That's a $117 million impact — and you can act on about $37.5 million of it. Here are the customers slipping now. By the way, you don't have an early-warning system; building one might be worthwhile.
— The agent's churn email, written for a human to simply act on
The pattern beneath all three stories — reconciliation, HR discovery, the strategy report — is a single pipeline Anand named explicitly. Agents can now let anyone find datasets, clean them, organize them, analyze them — in a loop, without human intervention, even with metadata only — then verify and present. And "present" does not mean a dashboard.
What is a person going to do with a dashboard? They're going to think and figure out what actions to take. Tell them the actions. An email saying "do this, here's the benefit, here's the evidence" is all we need.
— Anand, on the death of the dashboard as a deliverable
This, he argued, is what "forward-deployed engineers" are really for — except you don't need them only at clients. Point one internally and you have an internally-deployed engineer: "somebody saying, 'I have data, let's solve problems with it.'"
Section 08 · One Box or Three?The instinct an agentic stack punishes
Midway, Anand slipped in a teaching question disguised as a poll. You have 10,000 documents and three needs: find documents similar to this one; correlate sales with marketing spend; trace investor lineage across a chain of holdings. One storage choice for all three — or a different one per question?
Similar →
Vector embeddings. "Find another RFP like this RFP."
Correlate →
A tabular / relational store. "Is marketing actually moving the number?"
Trace →
A knowledge graph. "Who invested in whom, two hops out?"
The room split almost exactly down the middle: three voted "one store," three "different per question," one "not sure." The framework answer is three — and the split itself was the lesson.
The instinct to put it all in one box is exactly the instinct an agentic stack punishes.
— from the survey analysis, handed back to the room
Section 09 · When It Doesn't Work"We were not as lucky as you"
The most honest moment came from the audience. Someone had tried exactly this — merged documents into one CSV, built the PPT, showed the business team — and been told flatly: "These are not matching. We're not interested." His word for Anand's success was pointed: "lucky."
Anand didn't flinch. He agreed. And then he gave the room his actual operating system for failure — three moves:
1 · Portfolio, not promise
"If you commit and don't deliver, it's a problem. Don't commit, deliver, and ask: what mistakes am I making?" Spread it across twenty people; two say yes; ignore the rest.
2 · Human as an Interface
A teammate who "doesn't apply his brain" — just transcribes a leader, runs it through Claude, returns the output. The leader thinks he's brilliant.
3 · The impossibility list
Log every failure with its prompt. Run a post-mortem; convert repeat failures into skills. Re-test in three months — the models keep improving.
The second move deserves its own spotlight, because it answers the "but executives won't type prompts" objection so neatly. Anand runs a small innovation team; one member, Pavan, has a job title Anand invented:
My instructions to him: "Do not apply your brain. You don't know sales, you don't know the clients — you're literally fresh out of college." Transcribe what the leader says. Put it into Claude. Take the output, give it back. A week later the leader says: "Anand, this guy is so good — where did you find him?"
— Anand, on "Human as an Interface"
The trick: a person who can't second-guess the model is the perfect conduit. "He is very comfortable saying yes to everything; he has no idea what is possible." Claude infers intent; the human carries the relationship. The agent is brought "to the table" without anyone having to type.
Then two more audience stories arrived — and they pointed at the richest seam of all. One company asked: are there employees who are also vendors? Same phone numbers, same email IDs — caught in three days, not the month they'd feared. Another traced undeclared relatives via shared ZIP codes.
What people often don't explore is cross-domain stuff. Vendors — that's procurement. Employees — that's HR. Once you start connecting across, it becomes fantastic.
— Anand, on where the gold is buried
Section 10 · The MirrorThe audience becomes the dataset
For the finale, Anand did the most recursive thing possible. He took the room's own poll responses — the numbers they'd typed minutes earlier — pasted them into Claude with almost no context, and ran a live analysis in front of them. "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, he noted, is the real meaning of "bringing agents to the table." Not a talking robot. Just one person — even someone who knows nothing — transcribing a meeting and feeding it through. "Imagine doing this in a board meeting."
The candor extended to the demo's own risk. When he asked Claude for punchy lines to read aloud, he warned the room first:
How often has it happened that Claude gives you stuff that — when you tell it to read out — it totally messes up? [Audience: "All the time."] Yeah. That's just what happened to me.
— Anand, modelling how to fail in public gracefully
But then it found the thing. The real insight wasn't in any single answer — it was in a contradiction sitting across two questions.
agents can use today
data-stack problems
agents weren't good enough
The room had guessed, on median, that 40% of their data was agent-ready. Then, asked what was blocking deployment, they listed: broken data, data quality, unstructured data, siloed institutional knowledge, access issues, missing SOPs, data security. Every single blocker was a data-stack problem. Not one person blamed the model.
Not one of you said the agents weren't good enough. Not one. The bottleneck didn't disappear — it moved. It moved into your data stack.
— Claude's punch line, delivered by Anand
One respondent crystallised the paradox in a single person: he answered 100% of our data is usable — then named "data security" as his blocker. As the analysis put it: "the optimism and the pain are living in the same person. That person is every company in this room."
And the spread — that 60× scatter from the opening — got its meaning at last. It wasn't that some people were right and some wrong. It was that nobody actually knows anymore:
The reconciliation isn't being estimated like an engineering task. It's a vibe. Half the room is quoting a sprint, the other half a quarter — and nobody flinched that someone was ten-X off.
— from the live survey analysis
For the five people who answered the reconciliation question both before and after the demo, the total estimate fell 56% — from 25 days to 11. But the movement was one-directional and telling: the optimists didn't budge; the skeptics capitulated. VD went from 10 days to 1Of the before/after pairs: VD 10→1, VV 10→5, and three low estimators (1, 3, 1) held steady. The demo didn't persuade the believers — it converted the doubters down to where the believers already were.. "That's not persuasion — that's a floor dropping out."
Anand chose not to re-poll the room on whether their "40%" had shifted. He left it as a question to carry home — alongside the closing questions on the form (which asked, again, how many days they'd now quote a team, and what no-risk move they'd try this week). His thesis, gently planted:
My thesis is maybe that percentage is not as high as you think. The model is no longer the hard part — you just proved it to yourselves. The hard part is the thing you've been deferring for ten years, and the agents have stopped letting you defer it.
— Anand, closing the loop