Suresh Madhuvarsu

Co-founder @ SalesTable, Product10x Accelerator
3x Founder (RT != endorsement)
AMA on building #startups 0 to 1
Investor in Health, Ed and HRTech

[Suresh Madhuvarsu @sureshkrishna]

@boardyai @andrewdsouza building SalesTable AI, compliance-safe sales execution with AI coaching and embedded role plays for regulated teams. Boardy Pro would be huge for this

[Suresh Madhuvarsu @sureshkrishna]

One of the most consequential early decisions in any AI product:

How does your agent actually get the data it needs?

Most teams don't think about this carefully enough upfront. They hit a wall when they scale.

There are three distinct retrieval patterns, each with a different capability ceiling:

Pattern 1: Structured query
You pass a filter string to an API. The system executes it and returns results.
Example: searching Gmail with "is:unread newer_than:7d -category:promotions"

Fast. Clean. Constrained.
Works great when the data source has a good filter interface.
Breaks down when your logic is more complex than the API supports.

Pattern 2: SQL query
You write a SQL statement. A database interface executes it and returns structured results.
Example: SELECT * FROM deals WHERE stage NOT IN ('closed') AND days_since_contact > 7 ORDER BY deal_value DESC

More expressive. Schema-dependent.
Works well for relational data with known structure.
Requires a database interface on the other end. Not all systems have one.

Pattern 3: Code execution
The LLM writes actual code (Python, etc.). That code runs in a sandbox against raw data. The output comes back for interpretation.
Example: load a CSV of 5,000 deals, filter with custom logic, rank by composite score, return top 10.

Fully flexible. No API dependency.
Handles large, messy, unstructured datasets that no query language can cleanly express.
Slower. Requires a code runtime. More complex to build and secure.

The architecture decision:

At small data volumes and clean APIs: structured queries are enough.
At mid-scale with relational data: SQL is the right tool.
At enterprise scale with complex logic and raw data: only code execution holds.

The mistake I see most often:

Teams build the first version with Pattern 1, hit the ceiling, and realize they need to re-architect for Pattern 3 when they're already in production.

The right approach: know which pattern your enterprise use case ultimately requires, and design toward it from the start.

Your retrieval architecture is your scale ceiling. Choose it deliberately.

This was concept 6 of 6. The full framework: six foundational concepts for building AI-native products, came from one hands-on building session. Sometimes the best education is just doing the work and paying attention.

Hope this series was useful. What would you add?

[Kr$na @krishdotdev]

It's not FAANG anymore.

It's MANGO.

[Suresh Madhuvarsu @sureshkrishna]

There's a real difference between using AI and building on AI infrastructure.

Most products today do the first. They add an AI feature: a chatbot, a summarizer, a scoring model on top of an existing product structure. Additive AI.

Building on frontier LLM infrastructure is something different. Here's what actually changes:

1. Reasoning quality, not just pattern matching

Most domain AI tools are pattern matchers. They detect signals and return pre-mapped outputs. Frontier LLMs reason across unstructured context, hold multiple constraints simultaneously, and explain their conclusions. That's a qualitatively different capability, especially for complex domains where the answer isn't always in a lookup table.

2. Cross-system intelligence natively

With MCP connectivity built in, your product can reason across every connected system at once. Not one integration at a time. The agent sees email + CRM + calendar + documents simultaneously and synthesizes across all of them. No manual stitching. No isolated silos.

3. Explainability matters more than people admit

In high-stakes domains, "the AI said so" is never enough. Frontier LLMs can show their reasoning: walk through what they considered, what they weighted, and why they concluded what they did. That's not a nice-to-have. In regulated industries, in enterprise sales, in anything audit-sensitive, it's a requirement.

4. The compounding advantage is real

Every interaction handled by a domain-specific agent builds signal about what good looks like in that context. Teams that start earlier with a focused vertical build a reasoning flywheel that generic horizontal tools cannot replicate, not because the model is better, but because the context is richer and more specific over time.

5. What you take on

Prompt engineering. Eval infrastructure. Latency design. Cost management at scale. Human-in-the-loop checkpoints for high-stakes autonomous actions.

These aren't afterthoughts. They are core product requirements the moment your agent starts acting on behalf of users.

The honest summary:

Building on frontier LLM infrastructure doesn't make your product smarter.
It changes what your product fundamentally is.

Concept 5 of 6. Last one tomorrow: why the retrieval pattern you choose sets your scale ceiling.

[Suresh Madhuvarsu @sureshkrishna]

Everyone says their product is "agentic."

Most of them are not.

After building with AI infrastructure hands-on, I've mapped out four genuinely distinct levels. Most products sit at Level 1 or 2 and call it agentic. The real differentiation starts at Level 3.

Here's the honest breakdown:

Level 1: Reactive
You ask. The LLM answers from training knowledge.
No tools. No live data. No external systems.
This is a chatbot. It's useful. It's not agentic.

Level 2: Assisted
One question triggers multiple tool calls.
The LLM adapts mid-task based on what it finds.
It might query your email, then your CRM, then synthesize both.
You're still the trigger. The AI does the multi-step work.
This is where most "AI-powered" products actually live.

Level 3: Triggered agentic
A schedule or event fires the agent.
No human prompt required.
It acts, uses tools, returns output, or takes action autonomously.
Goals are defined by humans upfront. Execution is autonomous.
This is a meaningful shift: the human sets direction, the agent runs.

Level 4: Fully autonomous
The agent holds goals persistently.
It self-monitors, detects conditions, defines its own sub-tasks.
It acts continuously without waiting for a human to initiate anything.
The human sets the objective. The agent figures out the steps.

Where most products are: Level 1 and 2
Where real value is created: Level 3 and 4

The jump from L2 to L3 is not a feature addition. It's an architectural shift.
Request-response logic gets replaced by goal-persistence logic.

The jump from L3 to L4 requires the agent to self-monitor and self-correct. That's a different system design entirely, and it's where the hard product and safety questions live.

Before you call your product agentic, ask honestly: which level is it actually at?

Concept 4 of 6. Next: what actually changes when you build on frontier LLM infrastructure.

[Suresh Madhuvarsu @sureshkrishna]

We talk a lot about AI quality.

Prompt quality. Model quality. Output quality.

But there's one quality problem almost nobody talks about honestly:

The quality of the data the AI is reasoning on.

Here's what I learned building hands-on with AI on top of real operational data:

An LLM can navigate bad data. It cannot fix it.

What does bad data look like in practice?

Missing fields: records with no dates, no amounts, no context. The AI simply can't rank what it can't read.

Stale records: entries that were never closed, archived, or updated. The AI treats them as active. Your insights are now polluted.

Inconsistent schemas: the same field populated differently by different people, or mixed formats across teams. The AI reasons on whatever it finds.

Ghost data: batch imports, placeholder entries, test records that never got cleaned up. They show up as real signals.

The result: your AI gives you confident-sounding answers built on a shaky foundation.

This is the part most AI product pitches skip.

Garbage in, garbage out has always been true. But with AI, it's worse: because the output sounds authoritative even when the input is wrong.

The implication for anyone building AI-native products:

Data hygiene is not an ops task you hand off post-launch.
It is a core product requirement.
You need to design for it from day one.

The best AI products I've seen don't just surface insights. They enforce the input quality that makes those insights trustworthy.

That's the product layer most teams underinvest in.

Concept 3 of 6. Next: the agentic spectrum, and where most products actually sit on it.

[Suresh Madhuvarsu @sureshkrishna]

Here's something that surprises most people when they first build with AI.

The LLM remembers nothing.

Not your emails from last week.
Not the CRM entry you updated yesterday.
Not the conversation you had with it this morning.

Every session starts from zero.

When an LLM accesses your data: email, calendar, CRM, documents... it makes a live API call in that exact moment. It reasons on what comes back. When the session ends, that data is gone.

Nothing is stored in the model.

This is not a bug. It's how stateless API calls fundamentally work, and privacy is a big part of why it's designed this way too.

If LLMs retained everything they accessed, every sensitive business conversation, every personal email, every financial record would be sitting somewhere in a model's memory. That's a privacy and security problem at scale.

So instead: live access, ephemeral reasoning, no persistence.

What this means for product builders:

1. Your AI can't know what it hasn't been shown. You have to design the data access layer intentionally.

2. Context has to be reconstructed every session. That's a retrieval and architecture problem, not an AI problem.

3. Non-determinism is real. The same question asked twice may produce a different answer if the underlying data has changed. Build for that.

4. There's a difference between memory and judgment. The LLM doesn't remember, but it reasons brilliantly on whatever you give it. Design the input well and the output takes care of itself.

The mental model I use:

Think of an LLM like a brilliant consultant who reads your files fresh every meeting. No notes from last time. No assumptions carried forward. Just sharp reasoning on whatever's in front of them right now.

That changes how you design for it.

Concept 2 of 6. Next: why data quality is an AI product problem, not just an ops problem.

[Suresh Madhuvarsu @sureshkrishna]

Most people think an LLM is like a smart search engine.

It's not. On its own, it knows nothing about your world.

It doesn't know your emails. Your deals. Your calendar. Your customers.

So how does it actually connect to all of that?

Through something called MCP: Model Context Protocol.

Here's what that means in plain terms:

MCP is an open standard for connecting an LLM to the outside world: Gmail, Salesforce, Slack, databases, any API-connected system.

The LLM reads a tool's schema (basically: what does this system accept and return?), constructs the right call, sends it, and gets data back.

It never stores that data.
It reasons on what comes back.
When the session ends, it's gone.

Think of it this way:

The LLM is the brain.
MCP is the hands and eyes.
Your connected systems are the world it reaches into.

Without MCP, an LLM is a brilliant mind in a sealed room.
With MCP, it can actually do work.

The practical implication for anyone building AI products:

Your AI is only as capable as the integrations you build.
The quality of the insight depends on the quality of the API on the other end.
And none of it is persistent: everything is constructed fresh, every single time.

That's not a limitation. That's the architecture.

This is concept 1 of 6 from a framework I developed while building an AI-native product hands-on. Each post covers one foundational concept every product builder should understand before writing a single line of AI code.

Next up: why LLMs have no memory, and what that means for product design.

[Suresh Madhuvarsu @sureshkrishna]

https://t.co/c8fqw2OEeO

[Suresh Madhuvarsu @sureshkrishna]

Your team wrote the document. Nobody read it.

I don't mean nobody glanced at it. I mean nobody actually read it.

Here is what happened instead.

PM writes PRD → engineer feeds it to LLM → LLM writes test cases → QA feeds test cases to LLM → LLM writes a summary → someone pastes summary into a Notion doc → someone else summarizes the Notion doc.

The original document? Sitting there. Untouched.

And the strange part is that nobody noticed. Conversations sounded normal. People used the right words. They referenced the right sections. On the surface, the team was aligned.

But alignment on what exactly?

On the summary of the summary of the document.

Not on the thinking behind it. Not on the tradeoffs that were debated. Not on the decisions that were made and why. That context does not survive compression. It just disappears quietly.

I have watched this happen across product docs, sales playbooks, and messaging frameworks. Weeks of thinking reduced to three bullets. And nobody questions the bullets because they came from AI, and AI sounds confident.

This is what I call the document illusion.

Everyone knows what the document says. Nobody knows what it means.

The risk here is not that AI is replacing our thinking. The risk is that we are willingly handing it over and calling it efficiency.

When a sales rep reads an AI summary of a product doc, they learn the features. They do not learn why those features matter to a specific customer.

When an engineer reads a summary of requirements, they learn what to build. They do not absorb the edge cases, the customer context, the reasons certain decisions were made.

That knowledge gap shows up later.
- In demos that miss the point. In products that technically work but solve the wrong problem.
- In deals that stall because nobody in the room could go deeper than surface level.

Teams that look ready on paper but fall apart when the customer asks a hard question. Not because the information did not exist. Because nobody actually sat with it long enough to internalize it.

There is a simple test I have started using.

Ask someone to explain the reasoning behind a document, not just what it says.

Can they walk you through the decision? Can they defend the tradeoffs? Can they tell you what almost made it in and why it did not?

If they can't, the document never really did its job.

AI is an incredible tool. We use it every day. But there is a difference between using AI to help you think and using AI to avoid thinking.

We are drifting toward the second one. And most teams are not even aware it is happening.

[Aaron Levie @levie]

The CEO of Goldman Sachs is taking the other side on the pessimistic takes on AI and jobs.

If you looked at what work looked like a few decades ago and saw how much faster everything is or easier it is to produce the same thing as before - even before AI - you’d certainly have been convinced there’d be no jobs left.

What happens is we constantly just demand more from everything. Instead of automating a task and delivering the same value proposition, but cheaper, we just expect more from the overall product or service. Because some players in the market decides to do more with the automation, and it raises everyone’s expectations. So those that don’t respond can’t compete.

We get more financial analysis from analysts. We get much more comprehensive legal advice. We get more tailored financial services offerings. We get better software in niches we never thought we could automate. Our healthcare providers offer more tests and deeper medical advice. This just goes on and on.

When you move from believing the world is static and you’ll have a better view of how jobs evolve due to AI.

[Suresh Madhuvarsu @sureshkrishna]

@AlfieJCarter CLAUDE

[Suresh Madhuvarsu @sureshkrishna]

@AlfieJCarter 31 thank you for the great resource

[Suresh Madhuvarsu @sureshkrishna]

I have been a huge proponent of high value of employees who builder and sell. Every business need to be ai-native or ai-bolt-on to run business.

@DJ_CURFEW has an honest state of what's happening and what's valued in the AI era

[Zeb Evans @DJ_CURFEW]

Today we reduced headcount by 22%. The business is the strongest it's ever been. So I think it's important to be direct about what I'm seeing and why.

First, I made this decision and I own it. I did it because the way to operate at the highest level of productivity is changing, and to win the future, ClickUp needs to change with it.

Second, this wasn't about cutting costs. Most savings from this change will flow directly back into the people who stay. We'll be introducing million-dollar salary bands. If you create outsized impact using AI, you'll be paid outside of traditional bands.

Most importantly, I have the deepest gratitude for those affected. We're doing this from a position of strength specifically so we can take care of people properly. Everyone affected receives a package aimed at honoring their contributions and easing the transition.

I only see two options: wait for this to play out gradually in the market or be honest about what I'm seeing and act proactively.

THE 100X ORGANIZATION
The primary change is that we're restructuring around what I call 100x org. The goal is 100x output. The roles required to build at the highest level are fundamentally different than they were a year ago.

Incremental improvements to existing systems won't get us there. We need new ones. That means creating enough disruption to rebuild rather than iterate on what's already broken.

The common narrative is that AI makes everyone more productive. It doesn't. Many of the workflows of today, if left unchanged, create bottlenecks in AI systems.

These roles will evolve. But waiting for that to happen naturally means falling behind now.

The 100x org is actually heavily dependent on people - infinitely more than today. This is only possible with 10x people that have embraced and adopted new ways of working.

THE BUILDERS, AGENT MANAGERS, AND FRONT-LINERS

— THE BUILDERS: 10X ENGINEERS
I don't think most companies have internalized what's actually happening with AI in engineering. The common narrative is that AI makes all engineers more productive. That may be true in isolation, but at an organization level - that is the farthest thing from reality.

Here's what we've validated recently at ClickUp: the great engineers, the ones who can orchestrate, architect, and review, are becoming 100x engineers. They're not writing code. They're directing agents that write code. The skill is judgment.

AI makes the best engineers wildly more productive, and everyone else using AI slows these engineers down.
Think about it - the bottlenecks are (1) orchestration - telling AI what to do, and (2) reviewing - what AI did. Everything is leapfrogged and no longer needed.
So who do you want orchestrating and reviewing code?

And how do you want your best engineers to spend their time?

If your best engineers are spending time reviewing other people's code, then this is inherently an inefficient bottleneck. These engineers can review their agent's code much faster than reviewing human code.

The new world is about enabling your 10x engineers to become 100x.

The wrong strategy is to push every engineer to use infinite tokens. Companies doing this are celebrating 500% more pull requests. But customer outcomes don't match the volume of code being generated.

I call this the great reckoning of AI coding, and every company will face this soon if not already.

More code is just another bottleneck to the best engineers, and ultimately to your company's impact as well.

— THE BUILDERS: 10X PRODUCT MANAGERS
Product management and design roles are merging.

Designers that have customer focus, become more like product managers.

And product managers that have intuition for UX become more like designers.

The bottleneck of user research is gone. It takes us just one mention of an agent to kickoff research and analyze results.

The bottleneck of product <> design iteration is also gone. The product builder iterates on their own, along with agents and skills that ensure alignment with quality and strategy.

Also controversial today - I believe that the wrong strategy is to have your PMs shipping code - that just introduces another bottleneck that the best engineers will waste their time on.

To be clear, PMs should be coding but they should do this in a playground to iterate, validate, and scope. That code should not go to production.

Everything outside of managing systems, orchestrating AI, and reviewing output becomes a bottleneck.
That's why the other roles that are critical along with these are the systems managers (to reduce bottlenecks) along with a bottleneck you can't replace - customer meeting time.

— THE SYSTEM MANAGERS
Ironically, the people that automate their jobs with AI will always have a job. They become owners of the AI systems - agent managers. We have many examples of these people at ClickUp.

The underlying systems in which we operate are absolutely critical to get right. I think most companies are delusional to think they can iterate on existing systems and compete in this new world.

You must create enough disruption so that old systems are deprecated entirely. If there's any definition for 'AI native' that's what it is.

— THE FRONT-LINERS
In a world that will become saturated with AI communication, the human touch will matter more than anything to customers.

This is a bottleneck that you shouldn't replace - even when agents are high enough quality to do video meetings.

One-on-one meeting time with customers is something that shouldn't be automated. The systems around the meetings should be - so that front-liners spend nearly 100% of their time with customers.

REWARDING 100X IMPACT
In a world where companies are able to do so much more with less, where does that excess money go?
In our case, much of the savings in this new operating model will flow directly back to those that enabled it.

We must reward people that create productivity accordingly. This aligns incentives on both sides. Plus, in a world where your best people create 100x impact, you can't afford to lose them.

You should aim to retain these employees for decades. The context they have and their ability to efficiently orchestrate and review will be nearly impossible to replace.

Compensation bands of today should be thrown out the door. We're introducing $1 million cash/year salary bands with a path available to nearly everyone in the company if they produce 100x impact by creating or managing AI systems.

THE FUTURE
Nearly every company will make changes like these. The ones that do it proactively will define what comes next.

The future is not fewer people. It's different work, new roles, and better rewards for those who embrace it. We're already seeing entirely new roles emerge, like Agent Managers, that didn't exist a year ago.

ClickUp is positioning to lead this shift, not just internally, but for our customers too. I've never been more certain about where we're headed.

[Suresh Madhuvarsu @sureshkrishna]

Some obervations from #SaaStr + #Google I/O

Everyone's building everything now.

Same models, same tools, same infrastructure. The differentiation game has completely changed.

Product side:
- It's not about the AI anymore, it's about trust in what the AI produces
- Evals are the new moat. Can you prove your output is reliable? Can you show it getting better?
- Meet users where they already work. Don't ask them to learn a new interface, show up in their flow
- The model is commodity. The reliability layer is the product.

GTM side:
- Time to value is the only metric that matters now
- Not just "did they see value" but "how fast" and "how consistently"
- Users need to see improvement over time, not just a one-time wow moment

anything else?

[Suresh Madhuvarsu @sureshkrishna]

Will be at @Google I/O This Week

After spending the last year building on agentic AI, I'm curious to see where @googleio taking their Gen AI stack, especially anything around enterprise deployment and the governance layer.

What I'm watching for:
- Which Gen AI capabilities are moving from prototype to production-ready
- How Google is addressing the compliance and governance layer (the unsexy stuff that blocks enterprise adoption)
- Where the platform plays are heading vs. where the white space still exists for startups

If you're there and want to grab coffee between sessions, let me know. Always good to compare notes with folks who are actually building with this stuff.

[Deedy @deedydas]

The vibes in SF feel pretty frenetic right now. The divide in outcomes is the worst I've ever seen.

Over the last 5yrs, a group of ~10k people - employees at Anthropic, OpenAI, xAI, Nvidia, Meta TBD, founders - have hit retirement wealth of well above $20M (back of the envelope AI estimation).

Everyone outside that group feels like they can work their well-paying (but <$500k) job for their whole life and never get there.

Worse yet, layoffs are in full swing. Many software engineers feel like their life's skill is no longer useful. The day to day role of most jobs has changed overnight with AI.

As a result,
1. The corporate ladder looks like the wrong building to climb.
Everyone's trying to align with a new set of career "paths": should I be a founder? Is it too late to join Anthropic / OpenAI? should I get into AI? what company stock will 10x next? People are demanding higher salaries and switching jobs more and more.

2. There’s a deep malaise about work (and its future).
Why even work at all for “peanuts”? Will my job even exist in a few years? Many feel helpless. You hear the “permanent underclass” conversation a lot, esp from young people. It's hard to focus on doing good work when you think "man, if I joined Anthropic 2yrs ago, I could retire"

3. The mid to late middle managers feel paralyzed.
Many have families and don't feel like they have the energy or network to just "start a company". They don't particularly have any AI skills. They see the writing on the wall: middle management is being hollowed out in many companies.

4. The rich aren’t particularly happy either.
No one is shedding tears for them (and rightfully so). But those who have "made it" experience a profound lack of purpose too. Some have gone from <$150k to >$50M in a few years with no ramp. It flips your life plans upside down. For some, comparison is the thief of joy. For some, they escape to NYC to "live life". For others still, they start companies "just cuz", often to win status points. They never imagined that by age 30, they'd be set. I once asked a post-economic founder friend why they didn't just sell the co and they said "and do what? right now, everyone wants to talk to me. if i sell, I will only have money."

I understand that many reading this scoff at the champagne problems of the valley. Society is warped in this tech bubble. What is often well-off anywhere else in the world is bang average here.

Unlike many other places, tenure, intelligence and hard work can be loosely correlated with outcomes in the Bay. Living through a societally transformative gold rush in that environment can be paralyzing. "Am I in the right place? Should I move? Is there time still left? Am I gonna make it?" It psychologically torments many who have moved here in search of "success".

Ironically, a frequent side effect of this torment is to spin up the very products making everyone rich in hopes that you too can vibecode your path to economic enlightenment.

[Suresh Madhuvarsu @sureshkrishna]

CPO has become a great job to highly stressful job in 2026

- from SaaStr AI

[Suresh Madhuvarsu @sureshkrishna]

Heading to #SaaStrAnnual tomorrow with one thing on my mind: the gap between AI hype and Revenue execution.

~80% of sales reps missed quota for the last 2 years. That number hasn't moved despite every new sales tool promising to fix it.

Why? Because most AI tools solve the wrong problem.

They analyze calls after they happen. They build dashboards managers don't look at. They generate insights reps don't use.

The real problem is simpler: Reps go into high-stakes calls unprepared. They freeze on objections. They say "I'll get back to you" instead of closing.

Recording the failure doesn't fix it. Practice before the call does.

At SaaStr AI, I'm looking for one thing: teams solving execution problems, not just analysis problems.

The shift isn't from sales enablement to revenue enablement. It's from post-call analysis to pre-call readiness.

Thanks to Gerhard Gschwandtner for this discussion on the shift - in the right direction. From enablement to revenue.

#SaaStrAnnual #SaaStr #SaaStrAI #AIAgents #AgenticEnablement #RevenueEnablement