Founder to Fortune

Flow States and High Stakes: How a human performance optimizer does agentic coding

Vidya Raman — Tue, 28 Apr 2026 04:16:44 GMT

The “traditional” engineering org chart is a relic of a time when code was the primary bottleneck. For technical founders today, the challenge has shifted from managing human velocity to orchestrating agentic systems and defending product taste.

In a recent Founder to Fortune conversation, Clayton Kim, CTO of FlyKitt and professional aerial acrobat, broke down how he transitioned from managing dozens at Wayfair to running a “wizard-led” team of three that outpaces traditional squads.

The Death of the Middle Manager

Clayton’s thesis is clear: the industry is over-correcting toward a flattened organization. The “middle management” layer—those whose primary output is consensus—is being rendered obsolete by agentic workflows.

For the technical founder, this means:

Hiring “Wizard Architects”: You need ICs (Individual Contributors) who can manage five simultaneous Claude Code sessions, making high-level architectural trade-offs rather than just writing functions.
The Soft-Skill Paradox: As technical tasks are offloaded to agents, the value of cross-functional “buy-in” and “commanding a room” skyrockets. Your best engineer must now be your best communicator.

“Taste” as the Only Defensible Moat

When any PM can “vibe-code” a functioning prototype, feature parity becomes instant. Clayton argues that taste—the ability to manifest a cohesive, delightful design opinion—is the only thing preventing your product from becoming generic “AI slop”.

Regulatory Complexity: In industries like health-tech (FlyKitt’s domain), the moat isn’t the feature; it’s the underlying legal and insurance infrastructure that an LLM can’t replicate.
Human Behavior Psychology: AI coaches fail because they lack social accountability. Clayton’s insight: “People will ignore a notification, but they won’t ignore a Navy SEAL on a Zoom call”.

The Tactical Hack: Lock Picking and Flow State

The most provocative part of Clayton’s workflow is how he manages the “micro-downtime” of agentic coding. Traditional “flow” is disrupted when you have to wait 20 seconds for a bot to finish a PR.

Avoiding the Doom-Scroll: To prevent the cognitive drain of Twitter or Slack during these gaps, Clayton uses lock picking.
The Benefit: It’s a short, tactile, high-focus activity that keeps the brain primed for deep work without shifting into “passive consumption” mode.

The Takeaway for Founders

Don’t build a team to write code; build a team to orchestrate systems. Success in the next 18 months will belong to those who can maintain a “design opinion” while leveraging agents to handle the “boots on the ground” execution.

Listen to the full episode with Clayton Kim on Founder to Fortune podcast.

DevTool Founder-mode: Hiring for Grit, Reading Code, and Building Trust

Vidya Raman — Thu, 26 Mar 2026 03:02:23 GMT

From the early days of Borg at Google to a massive enterprise exit, Kubecost co-founder Ajay Tripathy breaks down the blueprint for the 2030 technical founder.

In the current startup climate, “Founder Mode” is often discussed as a personality trait—a mix of obsession and micromanagement. But for those building in the “gut” of the cloud—the developer tools and infrastructure layer—Founder Mode is a survival requirement. It’s the difference between building a tool that people “like” and building a system that an enterprise “trusts” with a $100 million cloud budget.

When Ajay Tripathy left Google to build Stackwatch (the company behind Kubecost), he was stepping out of the most sophisticated infrastructure environment on the planet. He had spent years working on Borg and Kubernetes, seeing firsthand how Google managed the staggering complexity of distributed systems.

His transition from a senior engineer at a “Big Tech” giant to a scrappy founder writing vanilla JavaScript in a text editor provides a masterclass in three specific areas: hiring for endurance, surviving the inevitable shift toward an AI-automated engineering stack and building the team that can deliver business outcomes.

The “Life is Short” Catalyst: Beyond the Golden Handcuffs

Many engineers at places like Google or Meta talk about starting a company, but few pull the trigger. For Tripathy, the push was both a lifelong entrepreneurial “mythology”—inspired by inventors like the fictional Tony Stark—and a visceral reminder of mortality.

Following the passing of a colleague, the abstract idea that “life is short” became a concrete directive. He realized that while Google provided a stable, prestigious environment, it didn’t offer the one thing he craved: total ownership of his output.

“I think that owning your own output is a really, really good way to grow as someone who’s interested in technology,” Tripathy explains. Along with his co-founder, whom he met at Google, he identified a massive market gap. While Google had internal versions of “cost control” for its massive Borg clusters, the rest of the world—which was rapidly adopting Kubernetes—was flying blind. They were spending millions on cloud compute with no way to see where the money was actually going.

1. The Grit Filter: Why Your First 10 Hires Shouldn’t be “Qualified”

One of the most counterintuitive lessons from the Stackwatch journey is Tripathy’s hiring philosophy. In the early “0-to-1” phase, a traditional, “highly qualified” resume can actually be a liability.

Tripathy argues that in a startup, technical skills are a commodity, but grit is a rare earth mineral. For his first four engineering hires, he ignored the standard algorithmic interviews in favor of a different metric: Evidence of doing something world-class hard.

He hired a math major who had built a coffee roasting business and completed an Iron Man. He hired long-distance swimmers. People who had looked at a daunting, physically or mentally exhausting goal and refused to quit.

“I can teach programming,” Tripathy says. “I can’t teach the founder mentality—the ability to do things that are world-class hard.”

In the first year of a startup, your code will break in ways you didn’t anticipate. Your roadmap will shift overnight because of a single customer call. You don’t need a specialist who can optimize a database but wilts under the pressure of a 2:00 AM production outage. You need a “finisher”—someone whose identity is tied to getting the job done, no matter the obstacle.

2. Vibe Coding: The Art of the “Dirty” Prototype

There is a myth that technical founders spend their first six months building a “perfect” backend. Tripathy’s experience was the opposite. Even as a deep-systems backend engineer, he spent the early days “vibe coding”—writing the frontend in vanilla JavaScript and using simple text editors like Nano.

The goal wasn’t architectural purity; it was validation. He and his co-founder operated as a “T-shaped” partnership. Tripathy handled the technical “guts,” while his co-founder (a PM by trade) focused on the market and fundraising. However, they overlapped constantly. If a mock-up was needed to close a deal, Tripathy didn’t wait for a frontend specialist. He “faked it” until the logic was proven.

This approach prevents the “Engineering Trap”: spending months building a scalable, beautiful system for a problem that nobody actually wants to pay to solve. By building “dirty” prototypes, they were able to pivot quickly based on real-world feedback from their first few users.

3. Weaponizing the Roadmap: Speed as a Competitive Edge

Founders often fear the “feature request.” They worry that saying yes to a customer will lead to technical debt or a bloated product. Tripathy suggests a different path: Let your first 10 customers pick the roadmap.

In the enterprise world, speed is a weapon. When a VP at a multi-billion dollar company tells a startup they need a specific integration, they are often used to the timelines of incumbents like VMware or IBM, where “soon” means six months to a year.

Tripathy’s strategy was to deliver in two weeks. To a large enterprise, a two-week turnaround feels like magic. It creates a perception of “infinite velocity.”

“When they say they want it ‘tomorrow,’ they really mean ‘this quarter,’” Tripathy notes. By “cheating” and delivering at 10x the speed of a legacy vendor, a startup can close deals that they have no business winning on paper. This isn’t just about being fast; it’s about using engineering responsiveness as a primary sales tool.

4. Open Source as a “Honesty” Mechanism

Kubecost was built with an open-source core, a strategic move that Tripathy views as essential for developer-tool startups. Open source serves two purposes:

High-Leverage Marketing: It allows developers to “try before they buy,” bypassing the friction of a formal sales process.
Risk Ownership: It allows the team to ship experimental features. If a feature is open-source, the user “owns the risk” of trying it. If it works, it becomes part of the enterprise standard.

More importantly, it keeps the team honest. When your code is public, you can’t hide behind marketing fluff. You have to listen to the community. The community acts as a massive, distributed QA team that identifies the “real” problems in the wild that no founder could simulate in a lab.

5. 2030 Vision: The Shift from “Writing” to “Reading” Code

Perhaps the most provocative portion of the conversation was Tripathy’s outlook on the future of the engineering profession. He points to a massive “coherence jump” in AI models that occurred in late 2025.

His prediction for 2030 is stark: The “Writing” era of engineering is coming to a close. In the next five years, AI will handle the bulk of code generation—the syntax, the boilerplate, and even the initial architecture of standard systems. The role of the “Senior Engineer” will shift 100% toward Code Review and Pull Request (PR) oversight.

Success will no longer go to the person who can write the most efficient Python script in an hour. It will go to the Architect—the person who can read an AI-generated PR of 5,000 lines and spot the subtle logic flaw that would cause a system to fail at scale. The engineer of the future is essentially a highly skilled editor and verifier.

6. The Outcome Economy: Why SaaS is Moving Toward “Trust”

Following the acquisition of Stackwatch by IBM, Tripathy has had a front-row seat to how the “giants” play the game. The realization? Enterprises don’t buy software; they buy outcomes.

“We have never sold just software,” Tripathy says. “We sell a guarantee that your costs are going to go down.”

This is the “Trust Model” of enterprise sales. A startup can have a better UI or a faster engine, but an incumbent like IBM wins because they stand by the software for the long term. They provide “eternal licenses” and a guarantee of business results.

For founders, this means your GTM strategy shouldn’t focus on “features.” It should focus on the Delta: The difference between the customer’s world today and their world after using your tool. If you can’t quantify the business outcome, you’re just selling a “nice-to-have.”

7. Technical Yield: The Future of GPU Interleaving

As we move deeper into the AI-native era, the next massive cost problem isn’t just cloud compute—it’s GPU utilization. Tripathy is currently looking at how to maximize “yield” from the most expensive hardware on the planet.

One concept he emphasizes is GPU Interleaving. Currently, many companies have separate clusters for “Inference” (answering user questions) and “Training” (building the models). During the day, inference demand is high; at night, it drops.

By building application-layer software that can interleave these jobs—automatically pivoting GPU power to training during low-inference periods—companies can drastically reduce their AI “burn.” This is the next frontier of infrastructure optimization: making sure that every second of GPU time is generating value.

The Final Word: The Exit is the Bow

For Ajay Tripathy, the acquisition by IBM wasn’t an “end,” but a transition. He views his current role as an opportunity to learn the “10-to-100” skills that a 0-to-1 founder rarely sees.

His advice to builders is simple: Focus on the value. If you build a tool that solves a $100 million problem and you staff it with people who have the grit to see it through, the “exit” is simply the final “bow” on the value you’ve already created.

If you found this deep-dive valuable, please share it with a fellow founder or engineer.

Engineering Capital: Investing in Technical Risk

Vidya Raman — Wed, 04 Mar 2026 20:59:34 GMT

Ashmeet Sidana invests in technical risk.

That bet has shaped the entire philosophy behind Engineering Capital, the firm Ashmeet founded after decades in Silicon Valley as both an engineer and venture investor.

In a recent episode of the Founder to Fortune podcast, I sat down with Ashmeet to discuss what really separates enduring startups from the rest.

We talked about:

why founders should treat startups as a last resort
the one signal that proves product-market fit
why every founder must learn how to sell
the biggest mistake junior VCs make in board meetings
and the single behavior that compounds across the life of a company

The conversation turned into something deeper than an investment philosophy.

It became a masterclass on how founders actually build companies that last.

Here are the key lessons.

The Most Underrated Risk in Venture

Ashmeet defines technical risk as the question:

Can the product actually be built?

Many venture capitalists prefer to evaluate market dynamics, customer adoption, or business models.

But technical risk is different. It requires understanding whether the underlying engineering problem is solvable—and if solving it creates a durable advantage.

Ashmeet illustrated this through a simple comparison.

Google started with a technical problem: how to rank and index the web efficiently using the PageRank algorithm.

Facebook, on the other hand, was fundamentally a consumer insight: people crave social validation and will share personal information in exchange for it.

Both became extraordinary companies.

But the core risk each company solved was completely different.

Engineering Capital focuses on companies in the first category—those built on solving difficult technical problems.

Because when technical risk is solved, the resulting advantage can be enormous.

Becoming a Founder Should Be Your Last Resort

One of the most striking things Ashmeet said during our conversation was this:

Starting a company should never be a casual career move.

Too many people approach entrepreneurship as the next step after leaving a job.

But the founders who succeed tend to have a very different mindset.

They start companies because they cannot imagine doing anything else.

Today, starting a company is easier than ever. Infrastructure is abundant. Tools are plentiful. Capital flows freely during boom cycles.

But building a successful company is still brutally hard.

If founders underestimate that reality, they often abandon the journey when things inevitably become difficult.

The founders who succeed are the ones who are all in from the beginning.

The Real Purpose of the First VC Meeting

When Ashmeet meets founders for the first time, he focuses on two things.

1. The founder themselves

Why are you starting this company?

Why are you the right person to build it?

How ambitious are you?

How deeply do you understand the problem?

Great companies rarely exist without exceptional founders.

2. The scale of the opportunity

Many problems are worth solving.

But venture capital requires problems that can grow into massive markets.

The goal of the first meeting is not to decide whether to invest.

It is simply to decide whether there should be a second meeting.

Given how many founders investors meet each year, that filter has to be applied quickly.

Product-Market Fit Has Only One Real Signal

Founders often misinterpret what signals progress.

They celebrate:

enthusiastic meetings
pilot programs
technical interest
product downloads
requests for demos

But none of those signals actually matter.

Ashmeet defines product-market fit very simply:

A customer writing you a check.

Everything else is noise.

He also warns about a trap many technical founders fall into: what he calls “playing house.”

This includes activities like:

setting up payroll systems
organizing the office
building internal processes
focusing on culture activities

None of these are harmful.

But they do not move the company closer to product-market fit.

Until customers are paying, founders must remain ruthlessly focused on solving real problems for real buyers.

Every Founder Must Learn to Sell

One myth among technical founders is that sales can be hired later.

Ashmeet rejects this idea completely.

In his view:

You cannot be a successful founder if you cannot sell.

Sales is not a personality trait. It is a skill.

And skills can be learned.

Founders who embrace this reality gain an enormous advantage. They learn directly from customers, refine their messaging, and shape the product around real needs.

Delegating that learning too early often delays product-market fit.

Venture Capital Is an Elbow-Grease Business

From the outside, venture capital can look glamorous.

Conference talks. Media interviews. Podcasts.

But according to Ashmeet, that visible layer represents maybe one percent of the job.

The real work involves:

interviewing customers
studying technology deeply
evaluating product architecture
conducting founder references
analyzing market trends

This work transforms investing from speculation into calculated risk-taking.

Good investors do not gamble.

They do the work.

Why Great Board Members Speak Less

One of the most counterintuitive lessons Ashmeet shared concerns board meetings.

Many junior investors believe they need to prove their value by speaking frequently.

But great board members operate differently.

According to Ashmeet, investors should speak about one percent of the time.

Their job is primarily to listen.

Advice should be given rarely—perhaps only a handful of times across the life of a company.

But when it is delivered at the right moment, it can change the trajectory of the entire business.

The Real Value a VC Can Provide

Connections and introductions are helpful.

But the most valuable thing a venture capitalist can provide is perspective.

Founders operate under intense focus. Every day they wake up thinking about a specific problem they are trying to solve.

Investors see a broader landscape.

They meet hundreds of founders, observe emerging patterns, and develop an outside perspective on the market.

Occasionally, this vantage point allows them to spot something the founder cannot see yet.

Those moments are rare.

But when they happen, they can change everything.

Companies Grow at the Speed of Learning

When I asked Ashmeet what founder behaviors compound over time, he answered with a single word.

Learning.

Companies grow at the speed at which their founders learn.

Product-market fit itself is an act of learning:

learning what customers actually want
learning how they want the product delivered
learning what they are willing to pay
learning how the company should position itself

Founders who treat learning as their superpower build organizations that evolve faster than competitors.

Ashmeet once considered giving himself the title “Professional Student.”

In many ways, that title may describe the best founders as well.

Entrepreneurship Is an Expedition

Ashmeet ended our conversation with a book recommendation: Undaunted Courage, the story of the Lewis and Clark expedition.

It might seem like an unusual recommendation for founders.

But the parallel is striking.

Lewis and Clark set out across an unknown continent with limited information, uncertain outcomes, and enormous risk.

Entrepreneurs do something similar.

They venture into unexplored territory, chasing possibilities that may or may not exist yet.

And like explorers, they often reshape the landscape in ways no one anticipated.

One Final Thought

If there is one theme that ties Ashmeet’s philosophy together, it is this:

Great founders compound learning faster than everyone else.

They learn from customers.

They learn from failure.

They learn from every conversation and every experiment.

Over time, that learning becomes an unfair advantage.

And sometimes, it turns a difficult technical problem into a world-changing company.

Your Co-Founder Relationship Is Your Startup’s Biggest Risk

Vidya Raman — Sat, 14 Feb 2026 14:13:44 GMT

Conflict between co-founders is inevitable.

Letting it spiral out of control is optional.

In this episode of Founder to Fortune, Vidya Raman sits down with Dr. Matt Jones — licensed psychologist, co-founder coach, and author of The Co-Founder Effect — to explore why the co-founder relationship is the single most under-managed risk in startups .

Matt works exclusively with founding teams to improve communication, teamwork, and decision-making. In this conversation, he shares both deep psychological insight and highly tactical tools founders can implement immediately.

Key Topics Covered

• Why the co-founder relationship is the floor and ceiling of execution

• The concept of emotional debt — and how it erodes trust

• How to contain conflict so it doesn’t contaminate the business

• Co-founder syncs vs. co-founder dates

• Meta-communication: working on the relationship, not just in it

• The dangers of rigid stories and confirmation bias

• When you need co-founder coaching (and why waiting is risky)

• Rethinking 50/50 equity splits

• Recognition gaps between technical and business co-founders

• The three relational languages: operational, psychological, archetypal

• Power dynamics in complementary founding teams

• The pursue/withdraw cycle

• Why 3-founder teams add exponential relational complexity

Rapid-Fire Toolkit for Founders

• Use breath to regulate before responding

• Replace “you always…” with “I feel X when Y…”

• Call for pauses in spiraling conversations

• Repeat back what you heard (reflective dialogue)

• After high-stakes meetings: debrief, regulate, then repair

If you are building a venture-scale company, this episode will change how you think about risk.

Because most startups don’t fail from lack of intelligence.

They fail from unmanaged relationships.

The #1 Risk First-Time Founders Always Underestimate (It's Not Technology)

Vidya Raman — Mon, 26 Jan 2026 23:31:49 GMT

Most first-time founders believe startups fail because of bad ideas, weak technology, or poor timing.

In this episode, Tarang Vaish, CTO of Granica argues that the real failure mode is far less obvious—and far more dangerous: people risk.

Drawing from his journey across hardware, data infrastructure, SaaS, and AI, Tarang shares hard-earned lessons on co-founder dynamics, solo founding, risk stacking, and founder mindset. He also offers a practical mental model for using AI effectively—by treating it like an intern, not magic.

This conversation is for founders who want to think more clearly about risk, leadership, and what actually determines success in the early days.

🔑 Key Topics & Takeaways

Why people risk is the most underestimated startup risk
Why solo founding is exponentially harder—especially fundraising
How first-time founders accidentally stack too many risks at once
Why technical brilliance rarely saves a startup on its own
The importance of co-founder complementarity, not similarity
What “realistic optimism” really means for founders
Why being transparent about founder ambitions can build trust
Lessons from building across hardware, storage, SaaS, and AI
Why data and security remain evergreen startup categories
How to use AI effectively: treat it like an intern, with structure and feedback

About Granica

Granica is an AI research and infrastructure company building reliable and steerable representations for enterprise structured data.
The rarest thing in enterprise AI is durable access plus trust. Crunch is how we earn it: a policy-driven physical health layer that keeps large tabular data estates efficient and reliable, safely and reversibly.
On top of that foundation, we’re building structured intelligence using Large Tabular Models: systems that learn cross-column and relational structure to deliver trustworthy answers and automation with provenance and governance built in.

About Tarang Vaish

Tarang Vaish is a systems engineer who’s spent his career building at scale—where infrastructure, cost, and reality collide.

Before co-founding Granica, he led core engineering efforts at Cohesity as a Senior Staff Engineer, helping build its distributed storage platform from the ground up. He was also a founding engineer at Armorblox, where he helped launch an AI-powered email security product, and earlier in his career worked on GPU architectures and compute SDKs at Vivante and AMD.

Today, as Co-Founder and CTO of Granica, Tarang is tackling one of the hardest problems in cloud computing: the cost of data. Granica’s real-time data optimization layer compresses and reshapes cloud data at petabyte scale—cutting storage and compute costs by over 50% without changing pipelines or sacrificing performance.

A rare mix of deep systems thinking and real-world impact.

Announcing "Fundraising for First-time Founders"

Vidya Raman — Sun, 04 Jan 2026 06:49:05 GMT

Since I became an investor, I’ve spent countless hours working formally as well as informally with more than a 100 founders on the topic of fundraising. Many of these people I’ve helped are my friends, former colleagues, and neighbors! I was wondering if there is a way to scale my system and my reach. Thus was born this course I’ve designed for first-time founders. I put in a ton of time during the holidays to distill everything I share over weeks and months with the folks I help fundraise. If you are someone who wants to learn what it takes or know someone who might, there is a lightning lesson they can sign up here. The entire course is open for enrollment here.

The Future of AI in 2026: Insights from the Most Important Research of 2025

Vidya Raman — Tue, 30 Dec 2025 15:01:10 GMT

Why This Matters Now

2025 was the year AI crossed from capability demos into operational systems.

Across agents, data infrastructure, security, and software engineering, the strongest research papers shared a common shift in posture: they stopped asking *“Can models do this?”* and started asking *“What does it take to run this reliably, safely, and at scale?”*

That distinction matters for founders and executives. It marks the transition from experimentation to system-building—and it clarifies what will differentiate real products from prototypes in 2026.

This post synthesizes the most important research signals across four domains, grounding them in what the papers actually show and what they unlock next.

---

AI Agents

The most important AI agent research of 2025 converged on a simple realization: agents are not prompts with tools; they are long-running systems.

Three ideas stand out.

First, how agents do work is fundamentally different from humans.

Research comparing human and agent workflows shows that agents operate almost entirely programmatically—through APIs, scripts, and structured commands—bypassing interfaces and visual checks entirely. This makes them fast and cheap, but brittle. When ambiguity or novelty appears, agents rarely pause to question assumptions. Instead, they proceed deterministically, sometimes fabricating missing steps.

Second, reliability must be enforced at the system level.

Papers like SagaLLM borrow transaction concepts from distributed systems—validation, rollback, compensating actions—to keep multi-agent workflows consistent when partial failures occur. This separates “intelligence” from “correctness,” a pattern that is essential for enterprise-grade use cases.

Third, agent architectures themselves may be learned.

Instead of hand-designing agent roles and workflows, some research treats agent design as a search problem—automatically discovering structures that outperform human-designed baselines as tasks evolve.

What this unlocks in 2026

Expect agent platforms to look less like orchestration scripts and more like workflow engines: explicit state, validation, recovery, and adaptive structure. The winning systems will not chase autonomy for its own sake—they will design for predictable collaboration between agents and humans.

---

Data Engineering

The strongest data engineering research of 2025 did not add “AI features” to existing stacks. Instead, it questioned whether the stack itself still makes sense.

Three shifts stand out.

First, streaming and storage are collapsing together.

Systems such as Ursa show that writing streams directly into lakehouse tables can eliminate connector sprawl and reduce cloud costs—by recognizing that most modern ingestion needs sub-second freshness, not ultra-low latency architectures designed for a different era.

Second, retrieval and generation must scale independently.

The Chameleon paper demonstrates that RAG serving is a systems composition problem, not just a GPU problem. Retrieval and generation have different compute profiles, and forcing them onto the same hardware leads to inefficiency. Disaggregated, heterogeneous architectures show measurable latency and throughput gains.

Third, ML inside databases must become reusable and generalizable.

Foundation Database Models (FDBMs) propose pre-trained, transferable representations that dramatically reduce per-dataset retraining overhead. This turns “learned DB components” from bespoke one-off projects into platform capabilities.

What this unlocks in 2026

Data platforms will increasingly be judged on how well they support AI-native workloads: fewer moving parts, clearer scaling boundaries, and predictable cost profiles for retrieval-heavy systems. Infrastructure that aligns with how AI actually runs—not how analytics ran five years ago—will pull ahead.

---

AI Security

AI security research in 2025 made one point unambiguous: model-centric safeguards are no longer sufficient.

Three lessons recur across the best papers.

First, autonomy changes the threat model.

Anthropic’s documentation of an AI-orchestrated cyber-espionage campaign shows agents acting as execution engines, not just advisors. While full autonomy remains brittle, the direction is clear: AI can already coordinate multi-step operations with limited human oversight.

Second, security failures emerge from composition.

Papers on agent security show that risks arise across tool chains, shared memory, and multi-agent coordination—not just from prompt injection. The system, not the model, becomes the attack surface.

Third, protocols like MCP require governance, not trust.

MCP makes tool integration powerful but introduces new injection surfaces through tool descriptions, files, and metadata. Treating tools as trusted extensions is unsafe by default; they must be scoped, monitored, and audited like credentials.

TRiSM frameworks for Agentic AI respond to this by treating trust, risk, and security as continuous system properties—spanning lifecycle governance, observability, and control.

What this unlocks in 2026:

Security will increasingly be a design-time concern for agentic systems, not an afterthought. Enterprises that invest early in tool governance, runtime monitoring, and system-level threat modeling will move faster with fewer surprises—not slower.

---

Software Engineering

AI’s impact on software engineering in 2025 was way more than code generation.

The most credible research shows three shifts.

First, testing must target risk, not coverage.

Meta’s mutation-guided testing demonstrates that many high-value tests do not increase line coverage at all. They prevent real incidents by simulating meaningful failure modes.

Second, iteration beats one-shot automation.

Search-based code optimization and feedback-driven systems consistently outperform single-pass prompting. Measurement and selection matter more than clever prompts.

Third, developer time is still a scarce resource.

Research on developer work patterns shows productivity drops when developers spend time on tasks they least value—meetings, setup environments, compliance, monitoring dashboard setups, and more. The most effective AI systems reduce cognitive load, not just keystrokes.

Large-scale deployments like WhatsApp’s internal GenAI platform (WhatsCode) reinforce this: success came from workflow integration, graduated automation, and human judgment—not full autonomy.

What this unlocks in 2026

AI tooling will be evaluated less on “how well does it write code” and more on whether it improves reliability, focus, and decision quality. Teams that optimize for resilience and human attention will see durable gains.

---

Cross-Cutting Themes

Across all four categories, a few patterns emerge naturally:

Systems matter more than models

Iteration and feedback outperform one-shot intelligence

Autonomy shifts work; it doesn’t eliminate it

Governance and reliability are prerequisites for scale

Importantly, none of the research argues for slowing down. It argues for building differently.

---

Final Takeaway for 2026

The best research of 2025 points to a clear direction:

AI is becoming infrastructure.

In 2026, competitive advantage will come from teams that treat agents as systems, data as AI-native infrastructure, security as continuous governance, and productivity as a function of reduced risk and cognitive load.

The winners won’t be those with the flashiest demos—but those who build AI systems that hold up under real-world complexity.

---

Referenced Papers

Anthropic, Disrupting the First Reported AI-Orchestrated Cyber Espionage Campaign, 2025
A. Zou et al. Security Challenges in AI Agent Deployment: Insights from a Large Scale Public Competition, arXiv 2025
Y. Guo et al. Systematic Analysis of MCP Security, Proceedings of the ACM CCS 2025
S. Razaa et al. TRiSM for Agentic AI: A Review of Trust, Risk, and Security Management in LLM-based Agentic Multi-Agent Systems, arXiv 2025
S. Hu et al. Automated Design of Agentic Systems, ICLR 2025
Z. Wang et al. How Do AI Agents Do Human Work? Comparing AI and Human Workflows Across Diverse Occupations, arXiv 2025
E. Chang et al. SagaLLM: Context Management, Validation, and Transaction Guarantees for Multi-Agent LLM Planning, PVLDB 2025
K. Wang et al. 1000 Layer Networks for Self-Supervised RL: Scaling Depth Can Enable New Goal-Reaching Capabilities, arXiv 2025
Google DeepMind, SIMA 2: A Generalist Embodied Agent for Virtual Worlds, 2025
H. Yang et al. Unlocking the Power of CI/CD for Data Pipelines in Distributed
DataWarehouses, PVLDB 2025
C. Foster et al. Mutation-Guided LLM-based Test Generation at Meta, ACM 2025
S. Gao et al. Search-Based LLMs for Code Optimization, IEEE/ACM 2025
S. Kumar et al. Time Warp: The Gap Between Developers’ Ideal vs Actual Workweeks in an AI-Driven Era, IEEE/ACM 2025
K. Mao et al. WhatsCode: Large-Scale GenAI Deployment for Developer Efficiency at WhatsApp, ICSE-SEIP 2026
M. Merli et al. Ursa: A Lakehouse-Native Data Streaming Engine for Kafka. PVLDB 2025.
W. Jiang et al. Chameleon: a Heterogeneous and Disaggregated Accelerator System for Retrieval-Augmented Language Models. PVLDB 2024.
Johannes Wehrstein et al. Towards Foundation Database Models. CIDR 2025.

AI Security Is Becoming a Systems Problem

Vidya Raman — Fri, 26 Dec 2025 15:01:31 GMT

Why This Topic Matters Right Now

Enterprise interest in AI agents has shifted quickly—from experimentation to early deployment.

Teams are no longer just asking whether large language models can write code or answer questions. They are exploring agents that can plan, act, use tools, persist memory, and coordinate across workflows. In other words: systems that do *work*, not just generate text.

This shift changes the risk profile fundamentally.

Traditional model-centric safety controls—prompt filters, content moderation, offline evaluation—were not designed for this.

The research covered here looks squarely at that gap. Rather than arguing for slower adoption, these papers ask a more practical question: **what needs to change in how we design, govern, and secure AI systems as they become more autonomous?**

---

The State of the Art — and Its Limits

Today’s enterprise AI deployments often rely on assumptions that no longer hold:

- Model-level safeguards are treated as sufficient, even when systems are embedded in complex workflows.

- Human-in-the-loop is assumed to mean safety, without examining how infrequent or superficial that oversight may be.

Model Context Protocol (MCP) and Its Security Implications

YouTube Video Link

What Problem This Paper Tackles

MCP standardizes how AI systems connect to external tools, data sources, and execution environments. While this enables powerful integrations, it also creates a uniform interface for misuse.

The question is not whether MCP is unsafe, but **how it should be governed**.

Core Idea

The paper highlights that while any given MCP tool call may appear benign in isolation, but it might be dangerous in aggregate.

Security therefore depends on context-aware authorization, logging, and policy enforcement across sessions.

Why This Is Meaningfully Different

What’s different is where attacks live and how they propagate. The paper demonstrates MCP-specific failure modes—including poisoned tool descriptions, file-based payloads, and chain attacks that spread through shared context as agents invoke multiple tools in sequence. These are not edge cases; they arise naturally from how MCP is designed to compose tools.

Practical Implications

Enterprises using MCP must treat tools and their metadata as untrusted inputs, not as safe extensions of the model.

Concretely, this means:

Scoping and isolating tools rather than sharing broad registries across agents
Separating data from instructions so files and tool descriptions cannot silently steer behavior
Regularly red-teaming and regression-testing agent workflows as tools change

---

Paper 4:

Trust, Risk, and Security Management (TRiSM) for Agentic AI

YouTube Video Link

What Problem This Paper Tackles

Existing AI governance frameworks focus on fairness, bias, and explainability at the model level. They struggle to extend to multi-agent systems with memory, planning, and tool use.

This paper proposes a broader governance lens.

Core Idea

The authors introduce a TRiSM framework tailored to agentic AI. It integrates explainability, ModelOps, security, privacy, and lifecycle governance, mapped explicitly to agent workflows and failure modes.

They also propose new evaluation metrics to measure inter-agent coordination and tool-use efficacy.

Why This Is Meaningfully Different

Rather than adding controls ad hoc, TRiSM treats trust and risk as system properties. Governance is continuous, not a pre-deployment checklist.

Practical Implications

For regulated or high-stakes domains, agentic AI will require explicit governance architectures. TRiSM offers a starting point for designing those systems without freezing innovation.

---

How These Papers Relate

These papers approach different layers—real-world misuse, system security, tool protocols, and governance—but they converge on a shared insight:

- Agentic AI systems can weaponise both content and behavior

- Security failures emerge from composition, not single components

- Governance must be designed into the system, not bolted on

None of the papers argue against deploying AI agents. They argue for treating them as first-class software systems.

---

What This Unlocks Over Time

If these ideas are taken seriously, we should expect:

- Clearer architectural patterns for safe agent deployment

- Tool ecosystems designed for least privilege and auditability

- Governance frameworks that scale with autonomy

- Faster, enterprise adoption—not slower will help us build a safer and innovative future

---

## References

- Anthropic. *Disrupting the First Reported AI-Orchestrated Cyber Espionage Campaign*, 2025

- *Security Challenges of AI Agent Systems*, 2024.

- *Model Context Protocol (MCP) and Security Implications*, 2024.

- *Trust, Risk, and Security Management (TRiSM) for Agentic AI*, 2025.

The Future of AI Agents: What The Best Research In 2025 Tells Us About Where Things Are Heading

Vidya Raman — Tue, 23 Dec 2025 15:02:11 GMT

Why This Topic Matters Right Now

AI systems are crossing a quiet but consequential threshold. They are no longer just generating answers, recommendations, or snippets of code. Increasingly, they are being asked to **do work**: coordinate tasks, manage state over time, recover from failures, learn from interaction, and operate semi-autonomously inside real systems.

The five papers taken together, offer a clearer picture of the future of agentic systems.

---

The State of the Art — and Its Limits

Most “AI agents” in production today are orchestration layers wrapped around large language models. They rely on prompts, tool calls, and ad-hoc control logic. This approach works for short-lived tasks, but it breaks down when systems must:

- maintain consistency across many steps

- coordinate multiple agents

- recover gracefully from partial failure

- learn new behaviors over time

- generalize beyond narrow task definitions

In practice, teams compensate with manual safeguards, human oversight, and brittle rules. The research below responds to these limitations by treating agents not as clever prompts, but as systems that must be engineered, trained, and evaluated as such.

---

Paper 1:

Automated Design of Agentic Systems

YouTube Video Link

### What Problem This Paper Tackles

Today’s agent architectures are mostly handcrafted. Engineers manually decide how agents are structured, how tasks are decomposed, and how feedback loops work. This process is slow, error-prone, and unlikely to scale as agent complexity grows.

Core Idea

This paper proposes automating the **design of agents themselves**. Instead of humans specifying agents, a meta-system searches over possible agent designs—encoded as executable code—and evaluates them on real tasks. Over time, the system discovers increasingly effective agent architectures.

Why This Is Meaningfully Different

The key shift is treating agent design as a **search and optimization problem**, similar to how neural architectures or hyperparameters are learned rather than hand-tuned. The discovered agents often exhibit non-obvious structures—novel combinations of roles, feedback, and decomposition—that outperform human-designed baselines.

Practical Implications

For product teams, this suggests a future where agent orchestration evolves automatically as workloads change. Instead of repeatedly redesigning workflows, teams could rely on systems that adapt agent structure based on observed performance.

---

Paper 2:

How Do AI Agents Do Human Work?

YouTube Video Link

What Problem This Paper Tackles

Much of the current conversation around AI agents assumes they are performing “human work” in roughly human ways. This paper challenges that assumption directly. Instead of asking whether agents can complete tasks, it asks a more revealing question: how do agents actually do the work compared to humans?

This distinction matters because two systems can produce similar outputs while following radically different processes—with very different implications for reliability, cost, and oversight.

---

Core Idea

The central finding is that **AI agents approach work almost entirely programmatically**, even for tasks humans perform visually or interactively.

In the study, agents overwhelmingly rely on:

- scripts and structured commands

- file and data manipulation

- direct API calls

- automated tool execution

Humans, by contrast, perform the same tasks through:

- visual inspection

- iterative adjustment

- contextual judgment

- and ad hoc problem solving

In other words, agents don’t “use software” the way humans do. They bypass interfaces and operate directly on representations of the work.

---

Why This Is Meaningfully Different

This leads to a critical insight: **agents and humans may complete the same task, but they are not doing the same work**.

Agents tend to:

- execute end-to-end plans quickly

- make fewer exploratory adjustments

- skip visual validation

- and treat ambiguous steps as deterministic

This makes agents dramatically faster and cheaper, but also more brittle. When something unexpected happens, agents are less likely to notice, ask for clarification, or correct course gracefully. In some cases, they fabricate missing data or silently proceed with incorrect assumptions.

Humans, meanwhile, are slower—but continuously validate, adjust, and apply judgment throughout the process.

---

Practical Implications

The paper shows that **full automation often shifts work rather than eliminating it**—from execution to verification, correction, and risk management.

The most effective deployments pair agents with humans deliberately:

The paper demonstrates that generalization, continual learning, and interaction can coexist in a single system. SIMA-2 improves not just through training, but through experience after deployment.

Practical Implications

This suggests a path toward agents that don’t need constant retraining for every new domain, reducing long-term operational cost and increasing adaptability.

---

How These Papers Relate

Each paper addresses a different layer of the same challenge:

- how agents are designed

- how work is structured

- how failures are handled

- how learning scales

- how agents generalize across environments

Together, they highlight that progress toward agentic systems requires *advances across architecture, learning, and systems engineering.

---

## References

- *Automated Design of Agentic Systems*, 2024

- *How Do AI Agents Do Human Work?*, 2024

- *SagaLLM: Context Management, Validation, and Transaction Guarantees for Multi-Agent LLM Planning*, 2025

- *1000 Layer Networks for Self-Supervised Reinforcement Learning*, 2025

- *SIMA-2: A Generalist Embodied Agent for Virtual Worlds*, 2025

AI Is Rewiring Software Engineering — But Not in the Way Most Leaders Expect

Sat, 20 Dec 2025 15:01:46 GMT

Why This Topic Matters Right Now

Software teams are under pressure from every direction at once.

Across these papers, a few themes recur naturally:

- Iteration beats one-shot automation

- Risk relevance matters more than surface metrics

- Production context cannot be abstracted away

- Human time and attention are the scarcest resources

Notably, none of the papers argue for removing humans from the loop. Instead, they show how AI reshapes *where* humans focus.

---

What This Unlocks Over Time

If these ideas mature, we should expect:

- Testing that targets real business risk, not just code paths

- CI/CD systems that respect data reality, not code metaphors

- AI tools designed around workflows, not prompts

- Developer productivity gains driven by reduced cognitive load, not raw output

Adoption barriers remain—tooling complexity, trust, and integration cost—but the direction is clear.

## References

- *Unlocking the Power of CI/CD for Data Pipelines in Distributed Data Warehouses*, Yang et al.

- *Mutation-Guided LLM-Based Test Generation at Meta*, Foster et al.

- *Search-Based LLMs for Code Optimization*, Gao et al.

- *Time Warp: The Gap Between Developers’ Ideal vs Actual Workweeks*, Kumar et al.

- *WhatsCode: Large-Scale GenAI Deployment for Developer Efficiency at WhatsApp*, Mao et al.

AI-Native Data Infrastructure: What Recent Research Tells Us About Where This Is Heading

Fri, 19 Dec 2025 03:37:15 GMT

If you’re building modern data products—analytics, agents, copilots, personalization, fraud, or operations—you’re running into the same structural problem:

Your “data plane” and your “AI plane” are evolving faster than your infrastructure can keep up.

Teams are being squeezed from both sides:

More real-time demands (freshness expectations measured in seconds, not hours)
Higher reliability requirements (enterprise SLAs, exactly-once guarantees, auditability)
A sharp rise in operational complexity (multiple systems stitched together with connectors)
Compute cost pressure (especially for cloud networking, replication, and GPU utilization)

The result: even strong teams end up shipping systems where every new capability—streaming ingestion, vector search, retrieval-augmented generation (RAG), learned DB optimization—adds another layer of infrastructure and tuning.

The research in this post tackles a shared theme: how to make core data infrastructure more “AI-native”—meaning cheaper to run, easier to scale, and better aligned with the workloads we actually serve today.

The State of the Art — and Its Limits

Today’s industry norm looks roughly like this:

Streaming data lands in Kafka (or equivalent) for operational ingestion.
A patchwork of connectors and pipelines move data into the lakehouse for analytics.
For AI applications, you bolt on a vector database (or vector index inside a DB) for retrieval.
Meanwhile, databases increasingly use ML internally—but usually via one-off models trained per dataset and per task, which makes them expensive to deploy and maintain.

This stack worked because each layer was independently best-in-class. But at scale it breaks down:

Duplicated infrastructure (streaming + storage + connectors + indexes)
Costly replication and cross-AZ traffic when designs optimized for ultra-low latency are used for data-heavy cloud ingestion
Inefficient RAG serving when retrieval and generation contend for the same compute resources (typically GPUs/CPUs)
High ML training overhead inside DBMSs, where collecting training data can require executing tens of thousands of SQL queries and take hours or days
The papers below propose three different “cuts” at the problem: redesign streaming for the lakehouse, redesign RAG serving hardware for retrieval + generation, and redesign ML-in-databases around reusable foundation models.

Paper 1:

Ursa: A Lakehouse-Native Data Streaming Engine for Kafka

YouTube Video Here

What Problem This Paper Tackles

Lakehouses are popular because they combine low-cost object storage with warehouse-like guarantees. But real-time ingestion often still depends on Kafka plus connectors that copy data into lakehouse tables—adding operational complexity and cost.

A key observation in the paper: traditional leader-based streaming systems were designed for sub-100ms latency, but many lakehouse ingestion workloads only need sub-second latency (hundreds of milliseconds). When you run “ultra-low-latency” architectures for “data-heavy ingestion” in the cloud, cross-AZ disk replication can drive up network traffic and storage overprovisioning.

Core Idea

Ursa proposes a Kafka-compatible streaming engine that is lakehouse-native: instead of writing events to broker disks and then moving them via connectors, it writes directly to open lakehouse tables on object storage.

It also removes a common scaling pain: leader-based replication. Ursa is described as leaderless and “cloud-native,” aiming to reduce the cost and operational footprint while preserving important semantics like exactly-once delivery.

Why This Is Meaningfully Different

Rather than “optimize Kafka” or “optimize connectors,” Ursa changes the integration point: it treats the lakehouse table format + object storage as the destination streaming systems should write to, not an after-the-fact sink.

Practical Implications

For founders and data platform leaders, the promise is straightforward:

Fewer moving parts (less connector sprawl)
Lower cloud cost by avoiding architectures that force heavy cross-AZ replication for ingestion workloads
A simpler path to near-real-time lakehouse analytics with Kafka-compatible producers/consumers

Paper 2:

Chameleon: a Heterogeneous and Disaggregated Accelerator System for Retrieval-Augmented Language Models

YouTube Link Here

What Problem This Paper Tackles

Retrieval-Augmented Language Models (RALMs) pair an LLM with a vector database: retrieve relevant context via vector search, then generate text using that context. This approach can reduce inference cost because the model doesn’t need to “store” all knowledge in parameters; it can fetch knowledge during inference.

The serving challenge: you now have two heavy workloads in the loop—vector search and LLM inference—and they scale differently.

Core Idea

Chameleon proposes a serving system that is both:

Heterogeneous: use different accelerators for different parts of the pipeline
Disaggregated: scale retrieval and generation independently
In their prototype, vector search runs on FPGAs and LLM inference runs on GPUs, with CPUs coordinating the cluster.

Why This Is Meaningfully Different

Most teams treat RAG serving as “GPU problem + database problem.” Chameleon argues it’s a systems composition problem: retrieval and generation have different compute profiles, so you shouldn’t force them onto the same architecture.

Empirically, they report up to 2.16× latency reduction and 3.18× throughput speedup versus a hybrid CPU-GPU approach .

Practical Implications

For enterprise AI teams, the message is: if RAG is a core workload, hardware architecture becomes product architecture.

You may want infrastructure that treats vector search as a first-class accelerated workload (not an afterthought)
Disaggregation offers a cleaner scaling story: retrieval-heavy and generation-heavy workloads can grow independently

Paper 3:

Towards Foundation Database Models (FDBMs)

YouTube Video Link

What Problem This Paper Tackles

ML inside DBMSs has shown promise for tasks like query optimization, cardinality estimation, and cost estimation. But in practice, adoption is limited because most learned components are instance-specific: train a specialized model for a specific task on a specific dataset.

The paper highlights the real cost: collecting training data can require executing tens of thousands of SQL queries, taking hours or days, and each new dataset/task combination requires retraining and maintenance.

Core Idea

The authors propose “Foundation Database Models”: models that generalize across both datasets and tasks, inspired by how foundation models work in NLP.

Their key architectural idea is a mixture of pre-trained expert models:

A data expert learns embeddings that summarize dataset characteristics (like distributions and correlations) using a transferable encoding that avoids database-specific constants and names
A logical plan expert enriches representations with how relational operations transform data
A physical plan expert adds understanding of physical operators and hardware/runtime factors

Downstream tasks can then be solved by simple “shallow” models on top of these representations, reducing task-specific data needs.

Why This Is Meaningfully Different

Instead of “train a model per DB,” the proposal is “pretrain reusable experts once, then adapt cheaply.” The mechanism is not magic—it’s modularity + transferable representations.

Practical Implications

If this direction matures, it could make ML-in-DBMS practical in more settings:

Lower training and maintenance overhead for learned DB components
A more realistic deployment story for cloud providers where per-customer training can be constrained
A platform path: DB intelligence becomes a reusable capability, not a bespoke project

How These Papers Relate

These papers are about different layers—streaming ingestion, RAG serving, and DB internals—but they rhyme:

They reduce “one-off integration tax.” Ursa removes connector-heavy pipelines; FDBMs aim to remove per-dataset/per-task model retraining.
They lean into specialization where it matters. Chameleon uses different accelerators for retrieval vs generation; FDBMs use different experts for data vs plans.
They optimize for cloud realities. Ursa explicitly calls out cross-AZ replication cost pitfalls; Chameleon argues for disaggregation to match workload scaling.

The shared theme: the next wave of “data infrastructure” is being redesigned around the dominant workloads of the next decade—real-time lakehouse analytics and retrieval-augmented AI—rather than around yesterday’s assumptions.

What This Unlocks Over Time

If directions like these become mainstream, expect:

Simpler end-to-end data paths (stream → lakehouse table without a second infrastructure tier)
More predictable RAG performance and cost as retrieval becomes a first-class, independently scalable component
DBMS intelligence that feels like a platform capability, not a research deployment—if foundation-style pretraining and reusable embeddings hold up across real enterprise diversity
Adoption barriers remain real: ecosystem compatibility, operational tooling, and proving reliability under messy production workloads. But the trajectory is clear: AI-era systems are pushing us toward integrated, modular, and cost-aware infrastructure designs.

What Founders and Leaders Should Take Away

Three practical questions to ask your team (or your vendors) after reading these papers:

Where are we paying “integration tax” for data movement? (connectors, duplicated storage, multi-tier pipelines)
Are we scaling RAG as one monolith, or as two distinct workloads (retrieval + generation)?
If we’re using ML inside data systems, are we building one-off models—or investing in reusable representations?

The big shift isn’t “more AI.” It’s AI-native system design: fewer bespoke components, more modularity, and architectures that match real cost and scaling behavior.

References

Matteo Merli, Sijie Guo, Penghui Li, Hang Chen, Neng Lu. Ursa: A Lakehouse-Native Data Streaming Engine for Kafka. PVLDB 18(12): 5184–5196, 2025.
Wenqi Jiang, Marco Zeller, Roger Waleffe, Torsten Hoefler, Gustavo Alonso. Chameleon: a Heterogeneous and Disaggregated Accelerator System for Retrieval-Augmented Language Models. PVLDB 18(1): 42–52, 2024.
Johannes Wehrstein et al. Towards Foundation Database Models. https://www.vldb.org/cidrdb/2025/towards-foundation-database-models.html

Small Models, Big Impact: Why the Future of AI Isn't Trillion-Parameter

Vidya Raman — Tue, 02 Dec 2025 15:51:08 GMT

Episode Summary

Most AI conversations start with parameter counts. This one doesn’t.

In this episode, we go inside the origin story of smallest.ai, a company built on the contrarian belief that true intelligence can be achieved with compute-constrained, smaller models — especially when the goal is real-time speech intelligence that can run actual workflows in production.

Sudarshan shares how his background in self-driving vehicles shaped his thinking on reliability, active learning loops, and why 90–95% of the work lives in data and labeling, not model training. We then zoom into real-world enterprise use cases like collections, outbound calls, and multilingual customer support, and talk through how CIOs can actually start with voice AI in a messy legacy stack.

In the second half, we switch gears into his founder journey: using LinkedIn and Discord as core distribution and learning channels, building the largest voice AI community, and his unfiltered advice on cold outreach, selecting whose advice to listen to, and running asset-light experiments before raising large rounds.

If you’re a founder building AI for the enterprise — or an executive trying to separate hype from deployable systems — this episode will give you a grounded way to think about small models, agents, and voice AI.

Key Topics

Origin story of smallest.ai and the shift from self-driving to speech AI
Why “small vs large models” is the wrong framing — and how to think in terms of specialized vs general-purpose agents instead
Building one of the world’s fastest text-to-speech and speech-to-speech systems
Emotional information in audio vs traditional speech-to-text → LLM → TTS pipelines
Handling multilingual, code-switching conversations (Hinglish and Spanish/English) in real-world deployments
The hidden 90–95%: data collection, labeling, and active learning loops inspired by Tesla’s approach
How CIOs and CTOs can actually start: quick-win use cases in collections and outbound calling with simple Excel-based feedback loops
Why legacy call center software is optimized for human agents, not infinite-capacity AI agents
Who ends up making the buying decision: CEOs, CIOs, heads of AI transformation, and VPs of collections
Building a founder-led growth engine:
- 30K+ LinkedIn connections
- The largest voice AI Discord community
- Leveraging community feedback to shape product and GTM
Founder advice: cold outreach, whose advice to ignore, asset-light validation, and benchmarking yourself against the best

Notable Quotes

“We should stop talking about intelligence in terms of models. We should always talk about intelligence in terms of agents that do end-to-end tasks in the economy.”
“Training is actually very quick. 90–95% of the work is the data — labeling it, fixing label errors, and feeding it back through active learning loops.”
“For enterprises, start with quick wins. Collections is a great one — run outbound calls, compare the agent to your humans, and only then worry about integrating deeply into your systems.”
“I wouldn’t take pitch deck advice from someone who’s never raised from a tier-one VC. Or engineering advice from someone who hasn’t written code in five years.”
“Talking to a lot of high-agency people is a superpower — and social media is one of the fastest ways to make that happen as a founder.”

About Sudarshan Kamath

Sudarshan Kamath is the founder & CEO of smallest.ai, a company focused on building compute-efficient, real-time speech intelligence and specialized voice agents for enterprise use cases like collections and customer support. Prior to smallest.ai, he worked on deploying deep learning systems for self-driving vehicles, building safety-critical systems that cannot fail.

About Founder to Fortune

Founder to Fortune is hosted by Vidya Raman, an investor and former operator who helps founders crack the enterprise market. Each episode dives deep into the realities of building, selling, and scaling products for enterprise customers — with operators, founders, and researchers who’ve actually done it.

Subscribe on Spotify, Apple Podcasts, or YouTube, and leave a review if this episode helped you think differently about AI in the enterprise.

Why 99% of Partnerships Go Nowhere (and How to Build the 1% That Win)

We Edit Podcasts — Tue, 11 Nov 2025 19:19:38 GMT

What if your biggest partnership was actually holding you back?

Pankaj Dugar, who helped scale Databricks and drove strategy at AI21 Labs, joins Vidya Raman to share why partnerships fail right after the Press Release — and how to build ones that actually sell.

This episode breaks down the uncomfortable truths behind partner ecosystems, the role of technical integration, and why “boring is where the money is.”

If you’ve ever thought a partnership could change your startup’s trajectory — listen before you celebrate.

Is UX Dead? How Vibe Coding is Rewriting the UX Playbook

We Edit Podcasts — Fri, 24 Oct 2025 23:06:15 GMT

What happens when PMs, designers, and AI all start speaking the same language?

In this episode, Vidya Raman sits down with Hailey Nevins (Director of UX Foundations at MongoDB) and Wenbo Wang (founding designer and former Databricks/Cloudera product designer) to explore how vibe coding is collapsing the old boundaries between design, product, and engineering.

You’ll hear how GenAI is forcing UX to evolve—from pixel pushing to taste-driven orchestration—and why the best design teams now operate at startup speed without sacrificing rigor.

We go deep into:

How “vibe coding” changes collaboration between PM, UX, and Engg
Why the new frontier isn’t just design systems—but design velocity
The rise of hybrid roles like “design engineer” and what they signal
How to build guardrails and evals for GenAI-powered products
When chat interfaces work—and when they absolutely don’t

And just wait till you hear their hot takes on AI “killing” the wrong kind of design work, why hallucinations can actually make UX better, and what founders get wrong about hiring designers too late.

If you care about product velocity, UX craft, or what “taste” means in an AI-first world—this conversation will challenge how you think about building.

Relevant links:

Hailey Nevins on LinkedIn

Wenbo Wang on LinkedIn

Open Lovable

Playbook for the AI-Native Chief Marketing Officer

We Edit Podcasts — Fri, 10 Oct 2025 16:15:22 GMT

In this engaging conversation, Kady Srinivasan, CMO of You.com shares her journey from software engineering to becoming a marketing leader across various industries. She discusses the importance of defining an Ideal Customer Profile (ICP) in B2B marketing, the impact of AI on marketing strategies, and the evolving role of marketers in a fast-paced environment. Kady emphasizes the need for discipline in narrowing down ICP, the significance of content creation, and the necessity of hiring the right marketing talent. She also highlights the importance of judgment in marketing and the need for continuous learning in the ever-changing landscape of marketing.

Takeaways

Defining a clear Ideal Customer Profile (ICP) is crucial for B2B success.
Discipline is necessary for narrowing down ICP and avoiding distractions.
AI has drastically increased the speed at which marketers must operate.
Multi-threaded marketers can drive outcomes across various disciplines.
SEO is not dead but GEO and AEO are becoming vital.
Content creation is still table stakes for differentiation in the market.
Hiring the right marketing talent depends on the go-to-market strategy.
Judgment in marketing comes from experience and learning from failures.
Sales leaders should be prioritized in early-stage startups with outbound strategies.
Continuous learning and adaptation are vital in the marketing field.

Relevant links:

Kady Srinivasan on LinkedIn

You.com

Founders of You.com: Richard Socher and Bryan McCann

Some links to the resources that Kady referred to:

Maven

GrowthX

Every.to

Watch us on YouTube here.

Product Leadership, Cyber Startups, and Agentic AI

We Edit Podcasts — Wed, 24 Sep 2025 22:32:28 GMT

Ely Kahn’s career spans government, startups, and now leading product at SentinelOne. From shaping U.S. cybersecurity strategy at the White House to building one of AWS’s early security products to launching SentinelOne’s fastest-growing AI product line, his journey offers a rare vantage point on how security and product innovation intersect.

In this episode, we dig into:

How AI is transforming threat hunting and investigations—and what that really means for teams on the ground.
The surprising role of “digital twins” in scaling product management.
Why cybersecurity, despite the noise and consolidation pressures, might actually be one of the best spaces for founders.
And the future of AI pricing, product velocity, and reinventing core parts of the security stack.

If you’re a founder, operator, or product leader navigating the next wave of AI and security, this conversation will leave you rethinking both the challenges—and the opportunities—ahead.

Links:

Ely Kahn on LinkedIn

Listen on YouTube

GTM Cheat Sheet Every Founder Needs

We Edit Podcasts — Thu, 11 Sep 2025 18:23:18 GMT

Veteran GTM leader Jim Fisher shares lessons from scaling Cloudera from $50M to $1B ARR and advising today’s fastest-growing startups.
The three golden KPIs that reveal the health of any go-to-market strategy.
Why most founders get ICP wrong—and how to fix it.
The surprising truth: consistency, not revenue, is the real signal your GTM is working.
When to hire a GTM advisor, fractional leader, or full-time VP—and how to know the right timing.
How AI is reshaping sales with coaching, opportunity analysis, and bias-free deal reviews.
Advice for founders on landing and learning from their first 10 customers.
Common GTM mistakes that derail growth—and how to avoid them.

Links:

Jim Fisher on LinkedIn

Listen on YouTube:

From Dorm Room to Boardroom: Life lessons in leading from the front

We Edit Podcasts — Thu, 28 Aug 2025 18:08:15 GMT

In this episode with Saket Modi, we explore:

How a college dorm-room hacker turned an idea into a global cybersecurity company
The surprising way he landed his first customers (hint: it involved live hacks)
Why he once turned down a multimillion-dollar deal—and why it was the best decision
His unconventional approach to learning (including hiring a PhD tutor just for himself)
The leadership principle he lives by: never ask your team to do what you won’t
Why SAFE is betting on Cyber AGI—and what that means for the future of security

Links:

Saket Modil on LinkedIn

Safe Security

Listen to this and more episodes on our YouTube channel!

Check out Founder to Fortune website for all the latest!

Your AI Co-Founder Can Build - Can you Lead?

We Edit Podcasts — Thu, 31 Jul 2025 22:39:33 GMT

What happens when a veteran CTO jumps into the world of AI-native tools, no-code platforms, and “vibe coding”? In this episode, Michael Raybman—former Hustle Fund CTO and founder whisperer—joins Vidya to break down how building software has been turned on its head.

They explore:

Why non-technical founders can go further, faster than ever before
The tools that actually deliver (with a live build of a working app in minutes!)
When to go from solo tinkering to hiring real developers
How to spot and fix a broken engineering team
And why PMs are suddenly cool again (spoiler: AI has something to do with it)

You’ll walk away with a new lens on building product—from prototype to production—and a playbook for navigating early-stage chaos with clarity.

⚡ Bonus: Michael drops two hot takes on vertical AI apps and the comeback of the product manager you don’t want to miss.

Watch on YouTube:

The Future of Building with Data

We Edit Podcasts — Thu, 26 Jun 2025 18:08:09 GMT

What happens when two long-time product and engineering leaders—who once yelled at each other across the office—reunite on a podcast to decode the future of data and AI?

In this episode, Vidya Raman hosts Anjan Kundavaram (CPO at Fivetran) and Chandler Hoisington (formerly CPO at EnterpriseDB and AWS exec) for a candid, behind-the-scenes conversation that spans:

Why the Lakehouse architecture is more than a buzzword—and how Iceberg is quietly winning the open standards race
Whether RAG, embeddings, and vector databases are already becoming yesterday’s news
What’s really holding enterprise AI adoption back (hint: it’s not just the models)
Why unstructured data is the new oil—and what most companies are missing
How the roles of PMs and engineers are being reshaped (but not replaced) by AI

And a whole lot more—from the false promises of CI/CD for data to whether you’ll really need a vector DB six months from now. If you’re building, shipping, or leading in the age of intelligent infrastructure, this episode is one you won’t want to miss.