A founder texted me this morning. His partner had just posted on X about leaving the firm, and he wanted to know how to manage the risk. I remembered a post Hunter Walk wrote in 2019 about exactly this, and if you haven’t read it, it’s worth finding. He covers the VC mechanics clearly. But after talking to many founders who’ve gone through it, I kept running into the same gap: the advice from inside the VC system assumes you understand how a firm works from the inside, and most founders don’t. So this is the founder’s side of the story.

Why it’s happening more

For a long time, getting check-writing authority at a venture firm took close to a decade. The title carried real weight because the partnership had already formed a view of you before you ever wrote a term sheet. Then the incentives shifted. Some firms started handing out partner titles broadly, for marketing, for volume, to compete for talent. Once that happened, more disciplined firms followed, because their junior investors would leave for the title elsewhere. A generation of investors started writing checks before the partnership fully believed in them. Some are exceptional and build long careers. Some move to better-branded firms. Some start their own funds. And some leave by choice, to start companies, to join the AI wave, to go somewhere their judgment fits better. The reason for leaving says nothing about what happens to you. VC departures are structurally more common than they used to be, and if your partner had check-writing authority, you are directly affected.

Two perspectives on the same situation

Before the tactical advice makes sense, it helps to know that two completely different lenses exist on this situation, and you need both of them.

The founder perspective says: you are still the CEO, and that doesn’t change because a partner left. Your responsibility is to act in the best interest of the company and its shareholders. You can disagree with investors about how to create value. That is part of the job. I’ve given this advice to founders before and heard experienced founders pass it to others: stay grounded, keep reinforcing your conviction, treat rebuilding internal support like fundraising. Consistency over months compounds. The people watching you hold your footing through a hard period will respect you for it later.

The structural perspective says: firms allocate attention and capital based on internal ownership, not warmth. When your partner left, your position inside the firm reset regardless of how the emails read. A partner who believes in your company will find a way to put more money in. Without a concrete signal of commitment, all the good conversations in the world tell you nothing about what the firm will actually do.

Use only the founder lens and you risk spending months rebuilding belief with people who have already moved on internally. Use only the structural lens and you make decisions from a defensive, cynical posture that costs you the credibility you need to re-earn support. You need both.

What changed when your partner walked out

When your VC leaves, your company gets re-evaluated inside the firm. Not in a meeting. Not in a memo. Just in where attention flows, who speaks up for your company in partner discussions, who uses their political capital on your behalf. The partner who wrote your check carried context that isn’t in any document: why you made the calls you made early, the reasoning behind bets that weren’t obvious yet, what made the thesis work before it was visible to others. That institutional memory left with them. From the outside, nothing looks different. Emails stay warm. Conversations still happen. But engagement without ownership is just politeness, and in a firm, ownership is the only thing that moves resources.

Diagnose before you do anything

Before you try to rebuild anything, you need to know where you actually stand. Ask directly: who owns us internally now? Under what conditions would the firm invest again? Are we still a priority for the partnership? These are uncomfortable questions, and most founders avoid them for that reason. Without answers, you’re operating on optimistic assumptions. Ask.

The gray zone: re-pitching is right, but it’s not enough

Most founders land in the gray zone. People are polite and the surface looks normal, which is exactly why it’s the hardest state to respond to correctly. The right instinct is also the one that gets executed incompletely. Yes, treat this like fundraising. Re-pitch the full partnership. Show what’s already working, not just what will work. Address the doubts you know exist but haven’t been voiced. Do this over months, not weeks. Rebuilding belief is slow.

Where founders get stuck is assuming that rebuilding the relationship is the goal. The actual goal is getting a concrete signal of commitment. Inside firms, the default behavior when things are uncertain is to stay supportive, avoid conflict, and defer hard decisions. You can have a run of strong conversations and interpret that as momentum. Often it isn’t. One pattern shows up repeatedly: a founder tries to gauge support before raising their next round, and the firm comes back with something that sounds reasonable. Go raise from the market, and if the round comes together, we’ll take our pro-rata. That’s not backing. That means the firm won’t take independent risk. They’re waiting for an external lead to validate the decision for them. If you’re in that position and you do need to raise, don’t wait for internal clarity before starting external conversations. Internal repair takes months. Starting external conversations early isn’t disloyalty. It’s an accurate read of the timeline.

When the system actually disappears

There’s a state that almost never gets addressed. You’re not just written off. No one picked up ownership after your partner left. Board members stop responding. Decisions that require governance stall because no one wants to be accountable, and no one wants to be seen as the person who let the company down. Sometimes the company has real options in this state: a potential acquirer, IP that could be sold, a strategic fit somewhere. And the people with fiduciary responsibility are nowhere to be found.

The board dynamics in this state can get structurally bad in ways that are often preventable earlier. If you remove a co-founder from operations, think carefully about whether they keep their board seat. A removed co-founder who is unhappy, with board rights and no operational role, can do real damage at exactly the moment when you need governance to function. And sometimes a board member knows what vote is needed but abstains anyway, because they don’t want their name attached to a hard decision. They’re protecting their own reputation, not the company. This is what I’ve called the Schrödinger’s VC: someone who preaches partnership before the deal and goes quiet when adversity arrives. The way to screen for it before you take someone’s money is to ask how they behaved when a portfolio company was struggling. Ask for a specific example, then go verify it directly with that founder. Character in adversity is the only reference check that matters. I talked through how to do this pre-investment on 20VC.

Find help outside the cap table

In the abandoned state, the instinct is to focus entirely on the investors who are supposed to be there. That’s the wrong frame. The most useful help often sits completely outside your existing cap table. Founders who have been through shutdowns, acquihires, or partial sales know the actual mechanics: which corp dev teams to talk to, how to position an asset sale, what an acquihire process looks like in practice. Those conversations cost nothing and are frequently more actionable than anything a checked-out board will give you. Reach out to former founders. Ask for specific introductions. Don’t wait for your investors to lead that effort. If a sale or acquihire becomes the real path, the mechanics of getting there are more specific than most founders expect. I wrote a detailed guide to early-stage M&A here, including how to build relationships with acquirers before you need them, what buyers actually value at the early stage, and why you need at least 9-12 months of runway before starting the process.

Landing the plane

Most outcomes are not venture-scale wins. Some are acqui-hires. Some are partial asset sales. Some are quiet shutdowns done carefully. How you move through any of these, whether people got paid, whether employees were told the truth early enough to make real decisions, whether you pursued every real option before closing, is part of your record as a founder. Companies deserve dignity at the end, not just at the peak.

When your VC leaves, the system reallocates its attention. Your responsibility doesn't. How you lead from that moment, how you diagnose clearly, how you communicate with your team, how you treat the people around you when things get hard, is exactly who you are as a founder. That doesn't change with a personnel announcement.

about Motive Force: Pre-seed & seed firm for founders who build before anyone asks. Backing Beautiful Software that amplifies human agency.

Leave a comment

Share

More essays: Your Sleep Debt is Diluting Your Equity, Founder Mental Software, Normalizing the Founder Journey, 7 Key Questions - learnings from my founder story

That’s one reason I invested in Poolside early, and why I’ve stayed excited watching them build quietly for years.

I knew Jason Warner before Poolside existed, though not personally. I knew him through the products he helped ship, and through what those products said about how he thinks. At GitHub, he oversaw an era that reshaped how developers work. GitHub Actions, Codespaces, Advanced Security, and the early incubation of Copilot all happened under his watch. Before that, Heroku became one of the most beloved developer platforms of the decade because it took infrastructure pain off the table and let people focus on building. What stood out wasn’t that Jason was technical. It was that he understood something many leaders miss: engineering is not a support function. It’s often where the most meaningful product leverage gets created.

I knew Eiso through a different path. Before Poolside, he spent years building at the intersection of AI and developer tooling long before it became fashionable. At source{d}, he was already working on large language models and machine learning systems applied to code years before the rest of the market became obsessed with AI coding. He later built Athenian, which helped engineering teams better understand how they build. Across both companies, there was a consistent curiosity about how software gets created, where friction emerges, and what better systems could look like.

That history matters because Poolside feels less like a reaction to the current AI cycle and more like the natural continuation of two long-running obsessions: making developers dramatically more effective, and rethinking how software gets made.

Today, Poolside is releasing Laguna M.1 and Laguna XS.2, its first publicly available foundation models built for agentic coding and long-horizon software work. Laguna XS.2 is also their first open-weight model, released under Apache 2.0.

That alone is worth paying attention to. But what stood out from today’s launch wasn’t the release of another frontier model. It was how carefully they seem to have thought about how developers actually want to work.

You can download the open model through Hugging Face, route it through OpenRouter, deploy it through Baseten, run it locally through Ollama, use it via Poolside’s API, or experiment directly in the browser through Shimmer. That ecosystem approach is unusually thoughtful at a moment when many AI companies are still trying to force users into tightly controlled interfaces and calling that a product strategy.

The best developer companies have historically won by respecting developer time and cognitive load. They remove invisible friction. They make complexity feel manageable, sometimes even elegant. That’s what beautiful software looks like: not software that’s aesthetically polished, but software that’s deeply considerate of the person using it. Software that helps people stay in flow.

That principle matters right now because most AI software still feels like a demo pretending to be a product. It can generate impressive moments, but often collapses under real workflows, messy edge cases, and sustained use.

That’s why Poolside’s focus on long-horizon software work is worth taking seriously. Most coding products today optimize for short loops: generating snippets, writing functions faster, accelerating repetitive tasks. Those improvements matter, but they don’t touch the hardest parts of software engineering.

Real engineering work means maintaining context across large codebases, debugging systems that fail in unpredictable ways, navigating ambiguity, making architectural decisions, and recovering when the first five approaches don’t work. It requires persistence, planning, and the ability to reason across longer stretches of work.

Software may also be one of the best training grounds for broader AI systems because it offers something most domains don’t: tight feedback loops. Code either works or it doesn’t. Systems either break or they don’t. Hallucinations get exposed quickly. Progress requires iteration.

That makes this a much harder problem than autocomplete, and a far more interesting one.

I’m an early investor in Poolside, so I’ve had a front-row seat to this. But what made me write that first check wasn’t just conviction in the market. I believed in the team’s ambition, and I told them early on that I wanted to help however I could, especially by connecting them with exceptional AI talent.

That offer still stands.

If you’re a researcher, engineer, or technical builder who cares about the future of software creation and wants to work on one of the hardest problems in AI, feel free to reach out.

Ambitious infrastructure companies often underestimate product. Product companies often underestimate technical depth.

Poolside is trying to do both.

Congrats to Jason, Eiso, and the team. Excited to see what developers build with this.

With Ryan Ni, the founder of Orca, outside Salesforce Tower.

A few weeks ago I came across a tweet that simply read: “No dating until Series B.”

Last night I heard Arthur Brooks speak about his new book, The Meaning of Your Life. I left carrying a copy and thinking about that tweet.

The juxtaposition is almost too clean. Brooks spent an hour arguing that the meaning crisis affecting young people today comes from one specific mistake: treating complex problems like complicated ones.

Complicated problems are hard but solvable. A jet engine is complicated. Scaling infrastructure is complicated. AI is complicated. Work on them long enough and they yield. Complex problems don’t yield. Marriage, grief, friendship, purpose. You don’t solve these. You live inside them. The meaning of your life is a complex problem. Love is a complex problem.

What happened after 2008, Brooks argues, is that the culture got very good at the first kind and lost its tolerance for the second. Every complicated problem now has a tool, an app, a solution. Every complex problem gets treated like a bug waiting to be fixed. The result: a generation that has optimized everything except the parts that matter.

“No dating until Series B” is the startup version of this mistake. It treats love like a feature you can ship later. After the architecture is stable, after the company works. But love doesn’t queue. It doesn’t wait for product-market fit. And the longer you practice deferring it, the worse you get at the underlying skill.

Brooks made a claim that felt almost intentionally provocative in a room full of founders: falling in love may be the most entrepreneurial thing you can do.

His reasoning is exact. Founders take enormous professional risks: leave stable jobs, raise capital at long odds, spend years on outcomes with no guarantees. But many ambitious people have become radically conservative about emotional risk. Falling in love requires vulnerability, the possibility of failure, and no upside to model. It requires surrendering control in a way that no framework manages.

People in their 20s today are a third less likely to say they’re in love than people in their 20s a generation ago. Brooks told the room: if you want to prove you’re an entrepreneur, go confess your love for someone.

He told a story about a young man who heard a version of that talk and flew somewhere to tell a woman he’d been secretly in love with how he felt. She rejected him. She was already in love with someone else and introduced them. He came back to thank Brooks months later. Not because it worked. Because it was the thing he was most afraid of. And he survived it. He wasn’t afraid anymore.

That’s the point. The fear of emotional failure is just professional risk in a different category. Founders who can’t tolerate it are running on a narrower band than they think.

If you’ve already fallen

Brooks is also writing a book on staying in love, which he says generates more demand than anything else he covers. A few things he shared that are worth keeping.

Falling in love is the ignition. The goal is companionate love: deep friendship. The question to ask at the three-to-five year mark is not whether you’re still in the early passionate stage. It’s whether you’re actually friends. That’s what the data on happy couples shows.

He also argues that what makes couples last is complementarity, not sameness. Dating apps filter for sameness: shared interests, shared values, shared aesthetics. That’s mostly wrong. Difference is what holds. You can’t quantify it, which is why the algorithm keeps getting it wrong.

Two things he says every couple needs: adoration and admiration. Women, on average, need to feel adored. Men, on average, need to feel admired. The cycle runs in both directions. A lack of adoration produces a lack of admiration, which produces a lack of adoration. Most relationship failures aren’t dramatic. They’re this slow erosion. One half withdrawing, then the other following.

His advice for staying married: adore her and be admirable. What if you don’t feel it? Love isn’t a feeling, he says. It’s a commitment. The feeling is evidence of love, not the thing itself. You adore her anyway.

Brooks also said something about technology that landed differently in a room full of people building it: technology improves your life when it solves complicated problems, and degrades it when it substitutes for complex ones. Using AI to free up time and attention so you can give more of both to the people around you: good. Using it to replace those people: not good.

The founders who build things that last are not the ones who deferred everything until the company worked. They’re the ones who already knew how to commit under uncertainty, at work and everywhere else. You can’t manufacture that orientation. It either runs through everything or it doesn’t. It shows up in the product and it shows up in how you live.

That’s not a soft skill. That’s the engine.

“No dating until Series B” doesn’t describe discipline. It describes someone who has learned to optimize the left side of their brain and let the right side atrophy. You can build a company that way. You probably can’t build a life.

Image credit

Most people measure brightness.

They look for the credentials, the logos, the schools, the fundraising speed. The signal that’s easy to perceive. Brightness is fast to evaluate. Brightness fills a slide deck.

But brightness is just light reflected from somewhere else. Point a strong enough source at anything and it will look bright.

What I look for is wavelength.

The frequency that’s yours and only yours. The thing that doesn’t need external light to keep going. The internal source.

And then: what you do with the light that hits you.

For me it was a NASA space station design competition. I was a kid in rural Romania. I had no computer at home. I found one and entered. The idea came from watching the honeycomb structure of the bees in my backyard. Nobody asked me to enter. I won the grand prize.

Nobody expected that. Including me.

But I could not look at the problem and do nothing. There is a phenomenon in physics called fluorescence. A material absorbs energy at one frequency and re-emits it at another. It doesn’t reflect what hits it. It transforms it. The light it gives off comes from within its own structure, triggered by pressure but not merely bounced back by it.

This is what motive force founders do with adversity, with friction, with the years when nothing is working. They don’t just survive it. They absorb it and change how they act. The energy that comes out is not the same energy that went in.

Resilience means you survived the hit. Fluorescence means you integrated it, and what you emit now is yours. The people who get burned absorb without integrating. The pressure finds no structure to work with and destroys what’s there.

Image credit

The Source of Motion

You know if you have it.

Not because someone told you. Because you noticed that you couldn’t stop. You were building before anyone funded you, thinking about this before anyone asked you to. The problem didn’t come from a market map. It came from something you couldn’t unsee.

You didn’t pick it. It picked you.

Image credit

Energy, Not Geometry

Credentials are train stations.

Harvard is a station. YC is a station. A previous exit is a station. The train passes through all of them, or it doesn’t. The station doesn’t tell you whether the engine is running.

I have met founders with every credential who had genuine motive force. I have met founders with none who had it. I have met founders with every credential who were coasting on brightness alone, and unknown founders already three years deep into a problem they couldn’t walk away from.

The credentials don’t disqualify anyone. They don’t qualify anyone either.

The question is always the engine.

Image credit

The Architecture of Necessity

You did not wait for permission.

That is the thing I look for first. Not what you are planning to build. What you already built when no one was watching, when there was no funding, no market validation, no reason except that you could see something that didn’t exist yet and the gap was intolerable.

You have a version of this. The thing you made before anyone called you a founder. The problem you kept returning to before it had a name. The moment you stopped asking whether this was reasonable and started asking how.

That moment is what I am looking for. Not the pitch. The moment before the pitch existed.

Every founder has a documented function: what they say they believe, what they put in the deck. And then there is the actual implementation: what they built before anyone asked, how they operate under pressure, what they cannot stop doing even when it is inconvenient. The gap between those two things tells you everything. I am not looking at the documented function. I am looking at the actual implementation.

The market looks at the product and sees a category. I learned to look past that. There is a founder I almost missed because the category he was in was going to lose. What I almost failed to see: he was not attached to the category. He was attached to the underlying problem. When the center of gravity shifted, he moved with it. The market saw a company in a declining space. I nearly agreed. What was actually there was an engine that had already found its next problem.

Motive force is not stubbornness around an idea. It is persistent orientation toward truth as it emerges.

You know the difference between conviction and stubbornness because you have felt both. Conviction updates when reality asks it to. Stubbornness doesn’t. The founders who burn out are not the ones who were wrong. They are the ones who stopped being able to find out.

Commitment without the willingness to be corrected becomes a trap. The force has to stay in contact with reality to matter. The engine and the destination are the same thing. You are not building toward the moment this matters. The building is already the thing that matters. It is not sacrifice. It is not even ambition.

It is inevitability.

Image credit

The Shape of Coherence

Motive force expresses itself in what it builds.

I call it Beautiful Software. Not beautiful as in polished. Beautiful as in coherent: technically rigorous, designed to fit into how work actually happens, priced in alignment with the value it creates.

You know this feeling. You are paranoid about the small thing that doesn’t fit the picture in your head. Does it matter to the customer right now? Maybe not. But you spend the time anyway, because you know what it becomes later. Because you cannot ship something you know is wrong and call it done.

That standard is not a one-time decision. It is an everyday practice. It compounds.

The alternative also compounds. The team that does whatever the customer asks ends up with a bloated product, conflicting features, engineers refactoring constantly because the requirements kept changing. They moved fast. They broke things. And then they kept breaking them.

The same force that shapes the founder shapes the product. I have seen this in both directions. A founder whose father told her from childhood: do good on the largest possible scale. She built software to treat hundreds of patients simultaneously. Every product decision from day one was made with massive scale in mind. Her internal directive and her architecture were the same thing. I have also seen a team rewrite their entire codebase on a tight deadline purely because their community requested it. Re-engineering your product mid-flight is not rational, unless user trust is your true north.

But there is a third dimension to Beautiful Software that founders with motive force most often get wrong, and it is the one that determines whether the work survives.

There is a developer tool I think about often. Hundreds of millions of downloads. Nearly ran out of money because the founders were afraid to charge for it. Not because they were weak. Because they loved what they had built. The love was real. What it was missing was the courage to say: this is worth paying for.

You may recognize this feeling. The product works. People depend on it. Charging for it feels like a betrayal of the thing you made it to be. So you wait. And something that hundreds of millions of people depend on nearly runs out of money to exist.

Economic courage is part of the craft. A thing you cannot sustain is a thing you eventually abandon. The founders who build things that last think about monetization from day one, not because they are mercenary but because they understand that sustaining the work is an expression of respecting it.

Image credit

The Atmospheric Opportunity

I am not looking for founders who need momentum.

I am looking for founders who generate it.

You got close enough to something broken to feel it. Not read about it. Feel it. The gap between what existed and what should exist became intolerable. That is not the same as having an idea. Most people have ideas. You had a wound that wouldn’t close.

The applications you describe feel fragmented to people who need the market to already exist. The use cases seem disconnected. That is not a problem with your idea. It is what it looks like when a primitive emerges before the workflows around it have formed. You are not imagining a future from the outside. You felt the break from the inside, and you left to fix it.

The skill on my side is separating empty dreaming from early truth. They are not the same thing and they do not feel the same in a conversation. The founder with early truth has been unusually proximate to the place where the current system breaks. That proximity is the tell.

Right now there is a lot of artificial brightness in this market. People who were in the right place at the right time, who started companies because the moment was obvious, building without a particular attachment to what they are building. That is fine. It is how markets work. But it creates noise, and the noise makes it harder for founders with genuine motive force to be seen, because the signal and the performance of the signal look similar from a distance.

There should exist a fund that sees the difference.

The energy is already there. In the people who are too early, too obsessed, too deep into a problem that doesn’t have a category yet. Most of it goes unharnessed. The opportunity is not to create it. It is to recognize it early and build around it correctly.

Image credit

Thermal Management

A note on endurance.

Some people respond to friction by pulling back. Reducing exposure. Reducing ambition. Waiting for better conditions. I don’t think that works.

Real rockets don’t survive reentry by stopping. They survive because of the heat shield, because of thermal management, because of infrastructure built specifically to protect the engine from the heat it generates. The engine at full capacity produces the most heat. The solution is not to throttle it. The solution is to build for it.

This fund is a cooling system. Not just fuel.

The founders who burn out are not the ones who worked too hard. They are the ones who started making decisions from fear. Fear of losing users. Fear of being perceived as something other than what they built themselves to be. Fear of asking the monetization question that might reveal they don’t know the answer. That fear is the heat that melts things. It converts internal drive into external approval-seeking. The engine starts running on the wrong fuel.

You know what it looks like when it starts. You stop building toward truth and start building toward safety. The product decisions change first. Then the hiring decisions. Then the fundraising story. By the time it is visible from the outside, it has been running for a long time.

My job is to reduce it. Not by protecting founders from hard things, but by protecting them from the specific thing that turns motive force into its opposite: the environment that rewards the performance of building over the actual thing.

More engine. Less horn.

Oana Olteanu, Motive Force

PS: If you are reading this and thinking: this is me, it probably is.

The founders I am looking for will recognize this immediately. Not because I described a type. Because I described a feeling they have been living without anyone naming it.

The ones who don’t have it will read this and wonder what I mean.

That is how you know.

Henry Ford’s Rouge (source)

A robot running at 95% accuracy sounds impressive. In a factory running fifty cycles an hour, that means fifty failures every shift. Each one requires a human to intervene, log the incident, reset the system, and decide what happens next. The robot is working. The deployment isn’t.

This is the gap that ends most robotics companies. Not the hardware. Not the vision model. Not the manipulation benchmark. The system around the robot.

We have been spending time with founders and engineers working in physical AI, and the same failure mode keeps surfacing. The robotics conversation is almost entirely about the machine: better models, better form factors, better demos. The deployment conversation barely exists. And almost nothing in the stack was built for what comes after the demo.

Physical AI is not a robot problem. It’s a skills, workflows, and learning system problem.

The hierarchy nobody draws

At its core, a robot is just an embodiment: joints, sensors, actuators. The real abstraction sits above the machine.

Physical work can be structured as a hierarchy: scenarios decompose into skills, skills into tasks, tasks into trajectories. This defines how complex industrial processes become machine-executable actions. It is also, not coincidentally, how enterprise software has always modeled work. The systems we worked on at SAP were built on exactly this kind of decomposition. What’s different now is that AI can learn the levels of this hierarchy, not just execute against a fixed specification.

The primary challenge is therefore not the robot. It’s the toolchain that lets robots learn, operate, and improve: simulation environments, workflow models, perception and planning stacks, data pipelines, the software that converts human demonstrations into reusable skills. This is the infrastructure that lets automation move beyond isolated machines toward scalable systems.

Hardware is a data acquisition device

Here is the reframe that matters for thinking about where value accumulates.

Robots increasingly function as data acquisition devices. Each deployment generates operational telemetry and demonstrations that feed back into learning systems. Over time, those feedback loops produce skill libraries, workflow abstractions, and training datasets that let automation capabilities transfer across tasks, sites, and embodiments.

This is why many of the most interesting robotics founders are not primarily designing new machines. They are building learning systems that combine simulation, real-world telemetry, and human motion data to continuously improve performance across fleets. The compounding advantage is in the accumulation of operational data and the ability to convert it into reusable automation capabilities.

One idea we keep coming back to from several conversations: the intelligence doesn’t have to live inside the robot. One architecture inverts the assumption entirely: the brains are in the environment, and the robot is just a tool the physical model uses to act on the world. That inversion changes the cost structure, the upgrade path, and the distribution model. It also makes the robot itself much cheaper, which is the actual bottleneck for adoption in most markets.

The deployment gap is real, and it’s not about the model

The pattern is consistent: great demos, almost no real deployments. And when companies do deploy, they hit a different set of problems than they expected.

Integration with existing operations. Financing and asset lifecycle. Service networks. Change management. Human workflow alignment. These are not engineering problems. They are adoption problems, and almost nothing in the robotics stack was built to solve them.

The deployment stack is where most robotics companies die: not on the benchmark, but on the installation. Nobody can plug the robot into the existing ticketing system. Nobody has figured out how to triage a failure at 2 am. The operator doesn’t know when to trust it and when to override. And the vendor who sold the hardware has no infrastructure to help.

This is the tank problem. Germany built the most complex and complicated tanks in the second world war but lacked scale everywhere. The Soviet Army built the most tanks of all, but they were designed as disposable items. The United States built simpler tanks at scale with a massive supply chain and service network.

Robotics is still in the beautiful tank era. The market winners will build the whole logistics network.

Berlin, summer 2024. Research.

The agent runtime is the missing layer

There is something happening in the software stack that will define which robotics companies matter in the next few years, and it is barely being discussed.

The architecture of a capable physical AI system is, at its core, two things: the model and the agent runtime. The models are getting better and everyone is paying attention to that. The agent runtimes are almost invisible in the conversation, and yet the performance of the whole system is insanely dependent on them.

An agent runtime for physical AI has to do things that software has never had to do before. Operate continuously, not just on demand. Manage asynchronous input from the physical world. Reason about state across long time horizons. Coordinate between multiple agents pursuing different objectives in the same physical space. Log decisions in a way that’s legible to humans who need to understand what happened and why.

This is not a solved problem. What most people are building today are either model wrappers or task-specific automation. Neither is infrastructure for continuous physical operation. Neither was designed for a world where the agent is running, the robot is acting, and a human somewhere needs to understand and trust all of it.

The companies building the agent runtime layer for physical AI don’t have a clean category name yet. That’s usually the right sign.

Where value actually accrues

Selling a robot is a capex transaction. Scaling automation requires owning the workflow layer: the point where robotic skills integrate with customer operations, business processes, and human workflows.

That layer determines adoption. It determines utilization. It determines whether a company accumulates the operational data that makes the next deployment better than the last one. And it determines whether, when a customer’s processes change, the automation changes with them or breaks.

The companies that define this market won’t necessarily be those that build the most sophisticated machines. They will be those that develop the most effective learning and workflow systems around machines. The robot is the vessel. The system is the product.

What we’re looking for

The category map writes itself. Simulation and training infrastructure. Workflow modeling tools. Agent runtimes for continuous physical operation. Incident management and operational orchestration. Context layers for physical assets. End-to-end deployment platforms that treat automation as a service, not a product.

None of these require building the robot. All of them are more defensible than the robot.

We’re looking for founders who see physical AI as a systems problem, not a hardware problem. Who understand workflows and operations, not just models and sensors. Who think in hierarchies: what is the scenario, what are the skills, what are the tasks, what are the trajectories, and how does learning flow back up through all of them.

If you’re building in this layer, or working in physical environments where you’ve felt the deployment gap firsthand, we’d genuinely like to talk.

About Motive Force: We back technical founders at the idea stage, before the category has a name. If that’s you, reach out.

About Christian Dahlen: angel investor with investments in robotics and industrial software and a Ph. D. in engineering. Select investments include Wandelbots, deltia.ai, and SDA.

Pacific Stock Exchange Option Trading Facility, San Francisco, 1985 (credit here)

Last week I had two conversations that had nothing to do with each other.

One was with someone building infrastructure for AI agents in revenue generating workflows: systems that identify audiences, run campaigns, and continuously refine targeting. The other was with a machine learning engineer working on production systems.

They were describing different problems. But they were pointing at the same failure mode.

The break isn’t parallelism. It’s decision parallelism.

Computers have always run parallel processes. Distributed systems, async pipelines, microservices. None of this is new. That’s not what’s breaking.

What’s new is that reasoning and exploration are now happening in parallel, and non-deterministically. The bottleneck isn’t that systems can’t run multiple threads. It’s that the human coordination layer (the interfaces, the tools, the mental models) was designed for a world where one decision happened at a time. A human asked a question, got an answer, and decided what to ask next. That assumption is now wrong, and almost nothing in the stack has caught up.

On the data side: agents explore, they don’t query

Traditional data systems are built around a contract: tell me exactly what you want, and I’ll give it to you. SQL, APIs, even most modern data pipelines assume the question is known before it’s asked. Planned. Deterministic.

Agents don’t work that way. They pull some data, see something interesting, immediately try ten variations, adjust, loop. The query isn’t known in advance; it’s constructed from what was just learned. Exploration is the work, not a path toward it.

This breaks query based systems not because they’re too slow in the conventional sense, but because they’re the wrong primitive entirely. Repeated round trips to a database assume you’re converging on a known answer. Agents are doing something more like traversal, moving through a space of possibilities, not retrieving a result.

What I’ve seen people move toward is a different kind of data layer: one where relationships are already materialized, where the agent navigates rather than queries. Knowledge graphs, vector indices, precomputed decision surfaces. These aren’t new ideas, but they’re being repurposed for a different workload. The break from prior work isn’t the technology; it’s the access pattern. Instead of posing questions and waiting for answers, the agent moves through a space where relevant relationships are already resolved. The latency characteristics and the interface contract are fundamentally different.

I don’t think we have a clean name for this category yet. But it’s not BI, it’s not analytics, and it’s not a better SQL wrapper. It’s something closer to a decision layer: infrastructure designed for agents that need to act on data quickly, not humans who need to understand it slowly.

6 agents in parallel. Step 3: pray / step 4: pray some more (image credit)

On the developer side: the bottleneck is keeping track

The engineer I spoke with described his workflow like this: multiple agents running in parallel, each attempting different approaches, returning results at different times. He’s not writing code step by step anymore. He’s monitoring, redirecting, stitching. The system produces output fast. What doesn’t keep up is him.

Think about what this shift actually means. Moving from writing code by hand to writing code with agents feels like jumping all the way from writing assembly code to writing JavaScript using all the modern tooling and web frameworks. It’s a crazy shift “up” in the stack. In some ways it doesn’t feel like doing the same thing we’ve been doing for the last 50 years, at all. But in other ways it still feels exactly like programming, except that we hardly have any new tooling wrapped around this new kind of programming.

And the human multithreading problem compounds this. While you’re waiting on one agent to return, you’re spinning up another. Human “single-threaded” work (write the code, run the model, reason through the problem yourself) is going down dramatically, replaced by “spec it out with the agent and hit enter.” People needed to learn to multithread when waiting for MapReduce jobs, model training runs, CI/CD pipelines. This is that, but the tasks themselves are now the waiting, not the preamble to it.

This isn’t a missing feature. It’s an interface paradigm problem. We built developer tooling for a world where a human was the executor: write code, run it, debug, repeat. One thread. One brain loop. Even the best IDEs today are optimized for sequential attention.

What this engineer needs doesn’t exist yet. Not because no one has built the right feature, but because no one has figured out what control even means when the work is non-linear. Air traffic control had this problem. Trading floors had this problem. Both developed entirely new interfaces, roles, and mental models, not just faster versions of what came before.

There’s a precise way to say what’s missing: these are team devtools. But for a team of agents.

We’re at the beginning of that process for agent-native developer work. Right now, people are managing it with tabs and logs and intuition. It works, until it doesn’t.

JFK, 1968. Congestion reached never-seen-before levels. They built new interfaces, new roles, new mental models. Not faster versions of what came before. (source)

These are the same shift at different layers

On the data side: agents need to explore a decision space quickly, without the latency and rigidity of repeated queries.

On the developer side: humans need to maintain coherent control over multiple agents pursuing different paths simultaneously.

Both break because the existing infrastructure assumes a single thread of decision-making. The shift isn’t just to probabilistic systems. It’s to parallel, exploratory ones. And almost nothing in the stack was designed for that.

The open question I’m sitting with

Is this structural, or is it a workaround for current model limitations?

There’s a pattern worth taking seriously: orchestration tends to be created to remedy deficiencies in models. It provides a short-term solution, but eventually the desired capabilities get integrated natively into the model layer, and most of the scaffolding gets jettisoned. RAG was a way to mitigate context size limits. The process repeats. If orchestration is just a seam, it will eventually disappear.

If future models become good enough at self-coordination, if the orchestration problem gets absorbed into the model layer, then the human interface problem partially dissolves. Agents coordinate themselves, data access gets handled internally, and the category doesn’t need to exist.

I don’t think that’s where we’re headed, but I hold it seriously. And worth noting: “orchestration” is itself a moving target. Every time models get better, we try to do more with them. We’ll mean something different by orchestration next year than we do today. The category keeps shifting forward.

What I keep coming back to is that even if models improve dramatically, the human accountability layer doesn’t go away. Someone still needs to understand what agents did, why, and whether it should have happened. And there’s something deeper here: making agent activity legible isn’t just about oversight or logging. It’s about surfacing unknown unknowns: preferences, context, judgment that lives in the human’s head and hasn’t been articulated yet. That’s a coordination and legibility problem that better models don’t solve on their own.

What I’m looking for

The tooling list writes itself. IDEs, version control, CI/CD, testing, bug trackers. Every layer of the developer stack was designed for a world where one human executed one thread of work. None of it has caught up. Each one is a company.

Infrastructure that makes agent exploration over data fast and navigable, not better querying, but a different access pattern designed for traversal and speed.

And systems that make parallel agent workflows legible and controllable for humans, not just dashboards or logs, but a new interface paradigm for work that doesn’t move in a line.

The companies building this probably don’t have a clean category name yet. That’s usually the right sign.

If you’re building in either direction, or if you’re working in production systems where you’ve felt both of these break, I’d genuinely like to talk. Not pipeline. I want to think through it.

Thanks to Kwindla Hultman Kramer (Daily), Justin Uberti (OpenAI), Piotr Migdal (Quesma), Catalin Tiseanu (Coinbase), and Yiliu Shen-Burke (stealth) for reading drafts of this.

About Motive Force: We back technical founders at the idea stage, before the category has a name. If that's you, reach out.

A note for founders who think sleep is a luxury.

Founders track the health of their companies through numbers: revenue, growth, burn rate, runway. In startup conversations these often collapse into a single signal, the North Star metric, that tells you whether the system you are building is healthy. Marketplaces watch transactions. SaaS companies track active users. Many AI startups now focus on successful task completion: the number of times a system actually finishes the work it was designed to do.

But behind every one of those metrics sits another system that rarely gets measured: the founder.

I’m the founder of Motive Force, a pre-seed and seed investment firm, and I spend a lot of time thinking about what allows entrepreneurs to maintain clarity over long periods of uncertainty. Startups rarely rise or fall on a single dramatic moment. They compound through thousands of small decisions: hiring choices, product tradeoffs, strategic pivots, fundraising timing. The quality of those decisions matters. So does the condition of the person making them.

The founders I admire most are not just smart, they are unusually good at sustaining clarity under pressure. In my work at Motive Force, I often think about the internal energy that allows someone to do that over many years.

Over time I realized that one signal captures this surprisingly well: sleep.

The founder reality nobody likes to admit

If you talk privately with founders building companies today, especially in AI, you hear a similar story repeated in different forms. The ground is constantly moving. A technical advantage that looked meaningful a few months ago can suddenly feel fragile. Models improve, tooling changes, and entire product categories reshape themselves faster than traditional software cycles.

At the same time, the company still needs direction. Customers expect momentum. Teams need conviction. Investors expect clarity. The founder becomes the person absorbing all of these pressures simultaneously while trying to make decisions under uncertainty.

The brain does not easily shut off this mode of thinking. Pattern detection, scenario planning, and risk assessment continue running long after the laptop closes, and over time that cognitive loop becomes physiological stress that shows up most clearly at night.

For a long time I assumed poor sleep was simply the cost of building.

My Oura readiness scores reflected that assumption. Many days they sat in the 40s, occasionally climbing into the 50s on a good night.

A few months ago, while waiting nervously in the lobby of an LP meeting, I noticed a set of egg-shaped hanging chairs and sat in one to calm my nerves. By coincidence, Lee, who would later become my sleep coach, was sitting nearby with her husband.

She handed me her card. That is how the conversation started.

When I began working with her, I expected the usual advice that circulates in productivity culture: drink tea, avoid screens, maybe meditate before bed. Instead, her approach to sleep looked strikingly similar to how strong founders approach systems.

She did not treat sleep as a checklist of habits. She treated it as the outcome of interacting variables: stress load, physiology, light exposure, behavior, and recovery cycles. Sleep quality, in her view, emerges from how those variables interact over time.

Within a few weeks something happened that I had never seen before. My readiness score crossed 90. The Oura app literally said, “We had to double-take.”

But the number itself was not the most interesting part. What mattered was how my mind felt the next day: calmer, less reactive, and more capable of holding complex problems without immediately tipping into stress.

That experience forced me to rethink the role sleep plays in founder decision making.

Why this matters for founders

Sleep does not replace judgment or experience. It shapes the state from which judgment operates.

It affects emotional regulation, patience, cognitive stamina, and the ability to sit with uncertainty without reacting impulsively. For founders, those qualities matter enormously. Building a company requires sustained decision making under ambiguity, and the internal operating state of the founder shapes how those decisions are made.

The shift for me was moving from seeing sleep as recovery to seeing it as decision infrastructure. Nothing about the external environment changed, markets were still uncertain, fundraising was still ambiguous, companies were still hard to build. What changed was my ability to navigate those conditions with clarity.

That difference compounds over time.

Turning sleep into something observable

One of the simplest suggestions from my coach was to start tracking a few signals daily. The tracker was intentionally simple: sleep score, readiness score, stress exposure, and short notes about the day.

After a few weeks patterns began to appear.

Sunlight and walking had a stronger effect on sleep quality than I expected. Late-night cognitive work, especially unresolved problem solving, tended to linger in the body longer than I realized. And perhaps most surprisingly, the effects were often delayed. A stressful day on Tuesday might show up as poor sleep two days later.

The tracker did not solve the problem by itself. What it did was make the system visible. Once patterns appeared, behavior started adjusting naturally.

Sleep as founder infrastructure

The deeper lesson in all of this is that sleep is not indulgence.

It is infrastructure.

Founders are comfortable investing in systems that improve company performance: better tools, faster feedback loops, stronger hiring, tighter processes. Yet we rarely think of the human system producing decisions with the same seriousness.

But the same logic applies. When the system producing your clarity degrades, everything downstream eventually degrades with it.

Sleep does not guarantee good decisions. It does something more subtle and more important: it stabilizes the conditions under which good decisions become possible.

A thought for founders

Most founders already track the metrics that describe the health of their companies. Those numbers matter.

But if the system producing your clarity and judgment begins to break down, the company will eventually feel it too.

That is why I have started to think of sleep as a founder metric, not because it guarantees wisdom, but because it shapes the state from which founders make decisions.

For people trying to build through uncertainty over many years, that state matters.

Acknowledgment

I would not have discovered this without my sleep coach. She approaches sleep with the kind of systems thinking I admire in founders: looking at how physiology, stress, behavior, and recovery interact over time instead of offering generic advice.

If sleep has been a struggle for you, I genuinely recommend speaking with her:

https://allrested.com - filled in a form for 10min before the first free session, and then I got to change my sleep in two months, price can be negotiated. It’s super easy.

She is doing the kind of work that quietly improves people’s lives, and I’m grateful I had the chance to work with her.

I spent the last few weeks collecting compensation data from AI engineers because multiple founders kept asking me the same question: “What the hell do I pay an AI engineer?”

They’d check Pave, their VCs’ platform subscriptions, the usual comp databases. All useless. The data is stale, generic, and doesn’t capture what’s actually happening in the AI talent war right now.

So I did what any reasonable person would do: I asked AI engineers directly. 50 of them shared real numbers, anonymously, across different stages, geographies, and experience levels.

This isn’t statistically rigorous research. Some buckets have just 3-4 responses. But it’s actual data from actual engineers in the market right now, and even with small samples, the patterns are unmistakable.

The headline finding? AI engineers at seed stage are getting 2-5% equity. That’s not a typo.

For context, the traditional playbook says to give your first technical hire around 0.75% equity. Senior engineers at seed typically max out at 1-1.5%.

AI engineers are commanding 3x that. And after seeing this data, I think they’re still underpriced.

The Numbers That Matter

I’m showing you exactly what I collected. Think of these as data points from the field, not a comprehensive study. With 3-7 people in most buckets, I’m showing you ranges and what was most common, not percentiles.

US Compensation by Stage

Pre-seed/Seed (US)

That senior number isn’t a mistake. The 7 senior seed-stage AI engineers who shared data are all making $240-275k base. Most at $250k. At seed. When the company has maybe 10 people and $3M in the bank.

Series A/B (US)

Interestingly, Series A/B compensation actually compresses. The desperation premium at seed disappears once companies have more resources and options.

Later Stage (US)

The Europe Reality Check

If you’re a US founder thinking “I’ll just hire in Europe,” here’s your wake-up call:

Yes, you can hire a mid-level AI engineer in Europe for $50-85k. The same person costs $175k in the US. This 3x gap is why every SF startup has a “stealth European AI team.” But there’s a reason the best European AI talent ends up working remotely for US companies at US rates.

The Equity Story Is Even Crazier

This is where things get genuinely wild. Traditional wisdom says your first engineering hire gets 0.5-1% equity. Maybe 1.5% if they’re exceptional and you’re desperate.

Here’s what the 8 seed-stage AI engineers who shared equity data actually got:

Equity at Pre-seed/Seed (8 responses)

Most common: ~2% High end: 5%+

I had to triple-check these numbers. Half these engineers are getting 2% or more. For context, 5% is what you’d traditionally give a co-founder who joined three months after incorporation. Now it’s the going rate for a senior AI engineer who can actually build your product.

My take: They’re worth it. If you’re building an AI company and your competitive advantage is the AI, then your AI engineer IS a co-founder, whether you call them that or not.

What AI Engineers Actually Think About Their Comp

The anonymous comments were more revealing than the numbers:

“Small companies are often toxic.” Translation: That 5% equity comes with 80-hour weeks and a CEO who Slacks at 2am.

“People lowball offers because they claim they’re helping you get into AI...they say it’s a favor so they can justify paying less.” This is apparently widespread. If someone tells you they’re “doing you a favor” by letting you work on their AI startup, run.

“I work as much as 3 employees would do in a regular company.” The dirty secret of AI engineering: you’re not hiring an engineer, you’re hiring an entire technical team. They’re doing ML infrastructure, data pipelines, model training, deployment, and often product thinking too.

“I got in around 2022-2023 and pay has become depressed since then. I got lucky but it is hard to hit this number now.” Some engineers are sitting on packages that would be impossible to get today. The market has rationalized somewhat from the 2022 peak, but it’s still wild by traditional standards.

“It does not match the work I do. I work as much as 3 employees would do in a regular company.” The scope creep is real. You start as an “AI engineer” and end up owning everything from data pipelines to product strategy.

So What Does This Mean?

For Founders:

1. Recalibrate your equity budget immediately. If you’re planning to hire AI engineers with a traditional 10% employee equity pool, you’re already dead. Your first two AI hires might eat 5-8% alone. Plan accordingly.

2. The $250k seed-stage senior is the new normal. Stop trying to hire senior AI talent for $150k. They have five other offers at $250k+. Either pay market or hire junior and train (if you have time, which you don’t).

3. Geography arbitrage works, but barely. Yes, you can hire in Europe for 1/3 the cost. But the best European engineers know their worth and work remotely for US companies anyway. You’re fishing in an increasingly small pond.

4. “AI Engineer” spans a huge range. Someone fine-tuning models is different from someone building training infrastructure from scratch. The person who can do both commands the high end of these ranges.

For Engineers:

1. You’re probably underpaid. Based on this data, if you’re a senior AI engineer in the US making less than $200k, you’re at the bottom of the range. Time to have a conversation.

2. Equity expectations have shifted dramatically. Don’t let anyone tell you that 0.5% is “generous” for an early AI hire. The data shows 2% is common, 5% is achievable.

3. The burden is real. Those high packages come with expectations of doing 3x the work. Make sure you’re being compensated for the actual scope, not just the title.

The Uncomfortable Truth

Here’s what nobody wants to say out loud: AI engineers aren’t just expensive because they’re scarce. They’re expensive because right now, the difference between having real AI capability and having a wrapper around GPT is the entire ball game.

If you’re a founder building an AI company, your AI engineers aren’t employees. They’re co-founders you’re paying a salary. Price them accordingly.

If you’re an AI engineer, you’re not just writing code. You’re the entire technical strategy. Price yourself accordingly.

The market is telling us something important: in the age of AI, technical talent isn’t just an input to the business. It IS the business.

Traditional engineering equity at seed: 0.75-1% AI engineering equity at seed: 2-5%

That’s not inflation. That’s the market recognizing reality.

Questions for readers: Is this matching what you’re seeing? What did I miss? And for those of you who’ve been in the market recently: what other dynamics are at play that the numbers don’t capture?

Thanks to the 50 engineers who shared their data.

Leave a comment

Share

More essays: How to Think Like a VC When Evaluating a Startup Role, What Makes 5% of AI Agents Actually Work in Production, Semantic layers, Fine Tuning, Founder Mental Software, Normalizing the Founder Journey, AI Engineer World’s Fair 2025 - Field Notes

Voice agents today are no longer just wrappers around models. They’re systems.

Systems that loop, call tools, pass memory, compress context, coordinate agents, and handle long-running tasks.

The next generation of voice isn’t just about naturalness or response quality. It’s about designing architectures that can support real-time, interactive, multi-turn orchestration. That means voice agents are increasingly looking less like interfaces and more like mini operating systems.

I’ve been watching this evolution as both a builder and an investor:

First with SAP Hybris, working on Alexa/Google Home integrations where “voice” meant wrestling with messy enterprise middleware and inventory APIs.

Now as a VC, investing in voice companies like Observe.AI, Ultravox, and OfOne, while cheering on builders like Kwindla and Nina at Pipecat and Scott at Deepgram.

Last week’s Voice AI Meetup in SF was a visceral reminder of how fast this field is moving. And how much of it still comes down to the people. Founders, engineers, model builders, infra nerds, product dreamers. On a random Wednesday night, I got to rub elbows with many of them.

Also: if you know the designer behind the Pipecat t-shirt (the loud one with neon cats in a Warhol grid), please tell them I LOVE it. Instant classic.

The Architecture Evolution

The Core Insight: Everything is a Loop + Inference + Tool Calls

Kwindla Kramer from Pipecat laid it out plainly during his talk about their voice game Gradient Bang: a voice agent isn’t just “speech in → model → speech out.” It’s fundamentally a loop: user voice input → inference → tool calls → context update → voice output → (repeat).

The loop must be non-blocking so the UI stays snappy, and capable of handing over to long-running tasks without losing context.

They flagged three core engineering challenges:

Prompt/context engineering still matters. Models don’t “do the right thing” by default. You still need to wrestle them into submission.

Coordination of sub-agents is messy. You’re now orchestrating multiple models, tools, workflows. It’s like herding cats, except the cats are on fire and also doing calculus.

Termination/latency/debugging become deeply painful. When loops can spawn sub-agents, audit trails disappear into the ether.

Nine Patterns That Actually Matter

What made the meetup particularly valuable was Kwindla walking through nine specific agentic patterns. They’ve discovered these building voice agents for enterprise use cases, and have been exploring them more in the open-ended Gradient Bang project. For engineers building voice systems, these are gold:

Pattern 1: State Machines

Build voice agents with state machines where each conversation state has its own system instruction, tool list, and context compression strategy. State transitions are opportunities to rewrite the entire LLM input. This approach measurably improves success rates. You can build this from scratch or use libraries like Pipecat Flows.

Pattern 2: Agent Handoff

Similar to state machines but conceptually different: instead of rewriting the LLM input, you transfer the conversation to another agent process. During handoff, you can operate on previous state and pass state forward. The tricky part is defining the handoff context and instructions. Choose whichever mental model (state machine vs agent handoff) maps better to your brain.

Pattern 3: Parallel Inference for Context Compaction

Run two LLMs in parallel sharing the same conversation context but with different system instructions. Use a gate (rule-based trigger) to compact conversation when context reaches certain thresholds. The compactor LLM transforms the full conversation into shorter context, replacing it in real-time.

Pattern 4: UI Driver Agent

Another parallel inference pattern: run a UI state LLM alongside your conversation LLM. The UI agent receives full conversation context each turn and outputs structured JSON that drives client-side UI. Use a “no-op” tool call or gate to handle turns where UI shouldn’t change.

Pattern 5: Long-Running Asynchronous Tasks

Make a tool call that starts a task, then returns immediately with a static success response and task ID. The long-running task then shoves context into the voice agent as XML-wrapped events. This feels like a kludge with today’s LLMs (working against the grain), but it’s so valuable that teams do it anyway.

Illustrative example

User: “Monitor the tech news sites for any announcements on new AI models”

Model: tool_call (start_monitoring_task(...))
Tool Response: { task_id: “task_123”, status: “running” }
Model: “I’m monitoring tech news sites for AI model announcements”

// 5 minutes later, task injects event into conversation:
<event task_id=”task_123” name=”news.found”>
	Source: TechCrunch
	Title: OpenAI announces GPT-5
	Summary: New model with 10x parameters
</event>

Model: “Just spotted something! OpenAI announced GPT-5 on TechCrunch with 10x the parameters of GPT-4”

//10 minutes later:
<event task_id=”task_123” name=”news.update”>
	Source: The Verge
	Title: Google responses with Gemini Ultra 2
	Summary: Multimodal model beating benchmarks
</event>

Model: “Google just responded! The Verge is reporting Gemini Ultra 2 with benchmark-beating multimodal capabilities”

Kwindla’s insight: “We’re abusing the tool call and tool response mechanism. We’re trying to figure out how to wrap events in user tag messages for the multi-turn context. It works. But if you build a lot of stuff with LLMs you develop intuitions about when you’re working with the grain of the model and when you’re working across the grain. This very much feels like working across the grain.”

Pattern 6: Sandboxed Long-Running Tasks

Same as Pattern 5 but run tasks in sandbox environments. Use network protocols (MCP or others) to decouple infrastructure, make applications extensible, or execute code safely.

Pattern 7: Library Agent

Use natural language capabilities of two different LLMs for sophisticated content lookup. Voice LLM generates queries using conversation context, then sends to another LLM with larger world context (massive system instructions, vector databases, backend systems). This separation of concerns with natural language drivers on both ends is powerful.

Pattern 8: History Agent

Similar to library agent but for querying domain-specific structured data (SQL databases, logs). The query LLM can loop through tool calls or write code. Trade-off: return structured data (more flexible but token-heavy) or natural language summary (token-efficient but less flexible).

Pattern 9: Use Audio Tokens Once

For audio-native LLMs like Gemini 2.5 Flash: feed audio directly for conversation inference (no separate transcription model), but run parallel transcription pipeline. Replace audio tokens with text after each turn because audio tokens degrade performance faster than text. Doesn’t matter if you miss a turn occasionally.

Technical Insights from the Panel

On Model Training and Multi-Turn Performance

Arjun from Cartesia made a fascinating point about architectures. Transformers scale quadratically in memory and speed, which is why longer context makes models slower. State space models (which Cartesia pioneered) are inspired by human memory: a fixed amount of space where you’re constantly recalling and reconstructing.

“Historically models have operated in this way where it’s in the cloud, you send context to it, it returns something and it completely forgets. That’s not how the world works. Whether it’s what we’re talking about now versus yesterday or 10 years ago, all of that influences how I’m talking today.”

On Error Handling: Just Throw It at the Model

John from Google had my favorite insight of the night. Instead of writing elaborate error handling code, just throw errors to the LLM:

// Old way: Precise error typing

try:

  do_some_stuff()

catch FancyException e:

  handle_this_error(e)

catch BanalException f:

  handle_that_too(f)

// New way: Let the LLM figure it out

{ “model”: tool_result<”natural language error description”>}

{ “model”: “Hey, so this thing happened...” }

The LLM has the system instruction, conversation context, and can infer user intent. It’s actually better at error handling than your code could ever be.

On Tools and Constraints

John’s advice on tools was spot-on: “The tool space has to be orthogonal. If you have contraindicated tools, if you have a ton of tools, it’s just gonna be confused.”

They discovered in Gradient Bang that they hit the tools limit before hitting context coherence limits. Too many tools = hallucination risk. The solution? Trim your tools list aggressively. Give the model breathing room.

He also shared this gem about prompting: “These models are very rational and very childlike. If you give them too many ‘do this, don’t do that’ constraints, they’ll just do something they think you want, but it’s not right.”

On Global Markets and Voice Democratization

Taruni from Hathora raised a critical point that resonates with my thesis about overlooked markets: “The English language is quite well served... but the current pricing model and types of models developed are just not conducive for innovation outside of the US.”

Arjun agreed, noting Cartesia’s Sonic 3 now supports 42+ languages and hundreds of dialects from one base model. The future of voice isn’t US-centric. Founders building for global, lower-cost regions with multi-language support may win the next wave.

What This Means for Founders

If you’re building in voice or conversational interfaces: Don’t start by picking a TTS or ASR model. Start by mapping the loop architecture. What are the states? What are the transitions? What sub-agents will you spawn?

Pay attention to tool design. A minimal, orthogonal tool set beats a sprawling “everything API” every time. Every. Single. Time.

Latency and termination = user experience. A beautiful model with 1.2 second delay will feel sluggish. Ensure your architecture supports fast turnaround, text token summarization (especially replacing audio tokens with text after transcription).

For investor-facing portfolios: Voice AI is increasingly less about model accuracy and more about system orchestration. Ask founders: how are you managing context, memory, loop termination, and tool orchestration? If they can’t answer clearly, run.

Consider global and multiplayer dimensions. Many voice stacks are US/English centric. Emerging founders who enable voice in other languages, lower cost regions, multiplayer settings and low latency may win the next wave.

The Bigger Picture

What struck me most wasn’t any single pattern or model improvement. It was the realization that we’re building something fundamentally new. Not voice interfaces. Voice operating systems.

As Kwindla put it: “Software is going to look very different once we all figure this stuff out.”

We’re moving from programming UIs to just throwing structured data across the wire and letting models figure out how to render it. We’re replacing error handling with natural language descriptions. We’re building systems where the agent loop IS the product.

This isn’t incremental improvement. It’s a phase change in how we build software.

The patterns Kwindla shared aren’t just clever hacks. They’re the early design patterns of a new computing paradigm. State machines, agent handoffs, parallel inference, long-running tasks producing XML events. This is what building voice systems looks like in 2025.

And here’s what excites me most as an investor: the best builders aren’t waiting for models to get better. They’re architecting around current limitations, discovering patterns that will define how we build for the next decade.

If you’re building in voice (infrastructure, UX, or model layers), find me. I want to meet you. Email me at oana@motiveforce.ai

Special thanks to Kwindla for sharing the patterns that are actually moving the needle, and to Jeff for pushing me to include the technical meat that engineers actually care about.

Leave a comment

Share

More essays: What Makes 5% of AI Agents Actually Work in Production?, Agentic systems: panning for gold, Semantic layers, Fine Tuning, Founder Mental Software, Normalizing the Founder Journey, AI Engineer World’s Fair 2025 - Field Notes

While most investors chase markets, I map work.

Why Process First

Agentic AI is changing the nature of enterprise software. The question is no longer “Where can I use AI in this department?” It’s “What would this department look like if agents ran 60% of it?”. And you can’t answer that question without understanding the work itself.

I started my career at SAP building something most people have never heard of: a business process ontology. I mapped how work actually happens across 25 industries and 11 lines of business. This ontology, a formal map of business processes and their relationships, became the foundation for semantic layers that translate between how businesses describe work and how systems execute it. Not how consultants think it happens. Not how software vendors wish it happened. How it actually happens, every approval, every handoff, every place where data gets stuck. That experience taught me something crucial: enterprises don’t buy AI. They buy solutions to workflow problems.

That’s why I evaluate startups based on their understanding of how information flows inside companies, not just what their model can do.

From People to Processes and Back

Instead of starting with use cases or verticals, I decompose work systematically:

This lets me reason top-down (Who does what work?) and bottom-up (How do those tasks recombine into core processes?). The goal is to identify where agentic automation can create real value across the enterprise, regardless of vertical.

Each layer answers critical questions:

• People/Occupations: Who performs the work? What are their roles, skills, and decision boundaries?

• Tasks: What do they actually do every day? How much can be automated today vs. near-term?

• Business Processes: How are those tasks orchestrated into workflows that deliver outcomes?

• Lines of Business: Which functional domain owns the process?

• Industries: How much variation exists across sectors?

The Vertical Trap

I’m seeing 10+ startups just in sales order processing, each claiming their vertical requires specialized AI. “Healthcare orders are different!” “Manufacturing has unique requirements!”

Usually, they’re wrong.

When I decompose their “unique” workflows, I find the same pattern. But here’s what these founders are actually sensing: every industry has evolved its own semantic layer. A “customer” in healthcare is a “patient.” In banking, they’re an “account holder.” In manufacturing, they’re a “buyer.” The entity is functionally identical (someone who owes you money for services), but every industry wraps it in different vocabulary.

True vertical differentiation only exists when the process architecture itself is unique (clinical trials in pharma, loan origination in banking), when regulation fundamentally reshapes the workflow, or when domain expertise is required to interpret the data, not just relabel it.

Most vertical AI startups aren’t building vertical solutions, they’re building horizontal workflows with vertical vocabulary. The ones who recognize this and architect for semantic configurability rather than vertical specialization will capture 10x more value.

How I Evaluate: The Three Filters

I’m looking for founders who understand the work deeply enough to automate it reliably at scale.

1. Automation Potential & Value

Automation potential = What percentage of a process can be realistically automated with current AI?

Automation value = Number of workers × average wage × automation potential

For example, founders who know their process can tell me exactly: “In accounts payable, we know X% is rule-based matching (fully automatable), Y% requires exception handling (partially automatable), Z% needs human judgment for vendor disputes (human-required).”

If they can’t break it down this precisely, they don’t know the work.

2. Adoption Readiness

Technical feasibility ≠ organizational readiness. Even when automatable, adoption depends on:

1. System integration (How digital/connected is the workflow?)

2. Compliance requirements (How much human oversight is legally or culturally required?)

3. Stakeholder complexity (How many people must align to change the process?)

4. Data structure (Can AI actually reason over the inputs?)

High adoption = standardized, repeatable, already digital. Low = fragmented, people-heavy, organizationally resistant.

3. Technical Feasibility

This reveals if founders have actually built enterprise software. The questions that matter:

1. How do you handle errors in a multi-system workflow? (robustness, evaluation, fallback logic)

2. How do you coordinate multiple agents effectively? (task delegation, communication protocols)

3. How do you integrate agents with human workflows? (handoffs, explainability, trust)

4. How do you manage agent resources and capabilities? (cost, latency, prioritization, governance)

5. How do you expand from this current process to an adjacent one? (roles overlap, context engineering, structure vs semantics)

Founders who hand-wave these questions are building demos, not products.

Where I Invest

Founders who understand process sequence (where one workflow hands off to the next), roles touched and degree of automation x adoption readiness, can choose the right entry point.

Green Zone (High automation, high adoption): Quick wins where AI already works. Structured data, repeatable workflows, measurable ROI. Great for case studies but crowded with competition.

Orange Zones (Medium-high automation, medium-high adoption): Where billion-dollar companies get built. Complex enough that incumbents struggle, feasible enough that focused startups can win. These require cross-system orchestration (SRM ↔ ERP ↔ CRM) and produce massive value once solved.

Red Zones (Low adoption or low automation): Either too early (waiting for AI breakthroughs) or not worth automating.

Yellow Zone (Low automation, high adoption): Human-in-the-loop opportunities. Augmented decision support rather than full automation.

I invest where technical feasibility meets organizational readiness, but hasn’t been commoditized yet. To show how this works in practice, I will be picking one line of business and map every workflow to identify the opportunities. I will share that analysis in a future post.

The Founders I’m Looking For

Beyond understanding workflows, I’m seeking:

• Technical builders who’ve lived inside the legacy stack (SAP, Oracle, Workday…)

• Domain experts who’ve felt the pain firsthand

• Workflow thinkers who trace processes like electrical engineers trace circuits.

These founders combine three rare qualities:

1. Deep process knowledge: they know their domain’s workflows cold

2. Technical sophistication: they need to understand what makes AI reliable at scale, how agentic will directionally evolve

3. Commercial empathy: they grasp why enterprises buy transformation, not technology

Ready to Build?

I don’t care which industry or line of business you’re in, whether you’re at the imagination stage or have paying customers. I care how well you understand the work. If you can trace a process with precision and reimagine it with agents, I want to meet you.

Don’t pitch me a market. Show me the work.

Reach me at oana@motiveforce.ai

Leave a comment

Share

More essays: What Makes 5% of AI Agents Actually Work in Production?, Agentic systems: panning for gold, Semantic layers, Fine Tuning, Founder Mental Software, Normalizing the Founder Journey, AI Engineer World’s Fair 2025 - Field Notes

I didn’t meet Cris Dobbins at a pitch event.

I was helping a portfolio company figure out their design hire when I asked them a simple question: “What products do you admire?” They didn’t name a designer. They named HashiCorp. So I went looking for who built that experience. I found Cris.

She’d spent seven years shaping the design language for Terraform, Consul, and Vault. Infrastructure tools that somehow felt human. I convinced her to leave HashiCorp and join our portfolio company. And I’ve been waiting for her to build her own thing ever since.

Now she is. And I couldn’t be more excited to back Soffi with Motive Force Ventures.

Beautiful Software Compounds

At Motive Force, I look for three things: founders with unstoppable drive, markets at inflection points, and beautiful software. That last one matters more than people think.

Beautiful software isn’t just pretty. It’s thoughtfully architected, emotionally intelligent, and spreads organically because people can’t imagine working without it. I learned this from watching HashiCorp.

Mitchell Hashimoto made Terraform “wrong” in all the right ways. An external state file that users could edit? JSON instead of a proper database? CLI-only with no server? Every choice broke convention. But each one made Terraform feel right to the people using it. Not righteous, but usable.

That’s the lineage Soffi inherits.

The Handoff is Dead

Today’s product development is a game of telephone: Figma to Notion to Jira to GitHub to Slack. Design gets divorced from code. Specs go stale. Everyone comments. Few ship.

AI is collapsing these boundaries. PMs prototype with Claude. Designers submit PRs. Engineers care about pixels. The future isn’t better handoffs. It’s no handoffs.

Soffi gets this. It’s not another AI mockup generator. It’s the first true product workspace where teams design, build, and ship directly on live product surfaces. Your actual app becomes the canvas. Changes generate production-ready PRs. Metrics live next to mockups.

Why Cris, Why Now

Cris is exactly what I call a Motive Force founder. She ships v1 in weeks, not quarters. She closes customers from slide zero. She’s relentlessly resourceful and has that rare combination of taste and commercial ambition. Most importantly, she builds beautiful software because she takes deep pride in her craft. She’s building Soffi for herself.

She isn’t chasing today’s AI hype. She’s building for the world that’s coming, where “full-stack builders” become the norm and AI handles the heavy lifting. But she’s doing it the hard way: enterprise-ready from day one, with proper infrastructure and compliance built into the foundation, not bolted on later.

She’s already assembled a team of builders who’ve lived these problems at scale (GitHub, HashiCorp etc). People who know that the small stuff compounds. The kind who believe software should be beautiful all the way down, even in the parts no one sees.

The Next Chapter

Steve Jobs insisted the motherboard be beautiful. Dieter Rams said “less, but better.” This philosophy isn’t aesthetic. It’s strategic. Beauty compounds.

Soffi is building that future. One where product teams move at the speed of thought. Where the best idea wins, regardless of who can code. Where craft still matters, even when AI does the typing.

If you’re a PM sketching in notebooks, a designer fixing copy in GitHub, or an engineer who cares about pixels, this is for you.

Join the waitlist at soffi.ai

And if you’re building beautiful software that amplifies human intent, I’d love to hear from you.

Most founders think they’re building AI products. They’re actually building context selection systems.

This Monday, I moderated a panel in San Francisco with engineers and ML leads from Uber, WisdomAI, EvenUp, and Datastrato. The event, Beyond the Prompt, drew 600+ registrants, mostly founders, engineers, and early AI product builders.

We weren’t there to rehash prompt engineering tips.

We talked about context engineering, inference stack design, and what it takes to scale agentic systems inside enterprise environments. If “prompting” is the tip of the iceberg, this panel dove into the cold, complex mass underneath: context selection, semantic layers, memory orchestration, governance, and multi-model routing.

Here’s the reality check: One panelist mentioned that 95% of AI agent deployments fail in production. Not because the models aren’t smart enough, but because the scaffolding around them, context engineering, security, memory design, isn’t there yet.

One metaphor from the night stuck with me:

“The base models are the soil; context is the seed.”

I’ve been obsessed with semantic layers for a while now, not because they’re flashy, but because they’re where founders quietly build trust, utility, and differentiation into LLM systems. I’ve seen too many teams conflate prompting with product. This panel felt like a moment where the real engineering work started getting its due.

Below are the takeaways, not just quotes, but patterns I see repeating in serious AI teams. If you’re building at the infra, tooling, or vertical AI layer, this is the scaffolding you’ll need to get right.

Context Engineering ≠ Prompt Hacking

Several panelists echoed the same insight: fine-tuning is rarely necessary. Retrieval-augmented generation (RAG), when done well, is enough. But most RAG systems today are too naive.

The failure mode:

• Index everything → retrieve too much → confuse the model

• Index too little → starve the model of signal

• Mix structured + unstructured data → break embeddings or flatten key schema

So what does advanced context engineering actually look like?

Read more about the context layer here.

a) Feature selection for LLMs

One speaker reframed context engineering as LLM-native feature engineering:

• Selective context pruning = feature selection

• Context validation = schema/type/recency checks

• “Context observability” = trace which inputs improved/worsened output quality

• Embedding augmentation with metadata = typed features + conditions

This framing matters. It means you can treat context like a versioned, auditable, testable artifact , not a string blob.

b) Semantic + metadata layering

Several teams described dual-layer architectures:

• Semantic layer → classic vector search

• Metadata layer → enforce filters based on document type, timestamp, access permissions, or vertical ontology

This hybrid layer helps normalize across messy input formats (PDFs, audio, logs, metrics) and ensures you’re not just retrieving “similar content,” but relevant structured knowledge. Think: taxonomies, entity linking, and domain-specific schemas on top of embeddings.

c) The text-to-SQL reality check

When the moderator asked the audience “How many of you have built text-to-SQL and put it into production?”, not a single hand went up.

This isn’t because the problem is niche, it’s because query understanding is brutally hard. Natural language is ambiguous. Business terminology is domain-specific. And LLMs don’t know your company’s definition of “revenue” or “active user” without extensive context engineering.

The teams that succeed don’t just throw SQL schemas at the model. They build:

• Business glossaries and term mappings

• Query templates with constraints

• Validation layers that catch semantic errors before execution

Feedback loops that improve understanding over time - read more here.

Governance & Trust Are Not “Enterprise Only” Problems

Security, lineage, and permissioning came up again and again, not as check-the-box items, but as blockers to deployment.

Founders building in verticals: take note

• You must trace which inputs led to which outputs (lineage)

• You must respect row level, role based access (policy gating)

• You must allow user specific output even if the prompt is the same

One speaker said:

“If two employees ask the same question, the model output should differ, because they have different permissions.”

Without these controls, your agent may be functionally right but organizationally wrong, leaking access or violating compliance.

The leading pattern here: unified metadata catalogs for both structured + unstructured data, with embedded access policies at index + query time.

The trust problem is human, not technical

One panelist shared a personal story that crystallized the challenge: his wife refuses to let him use Tesla’s autopilot. Why? Not because it doesn’t work, but because she doesn’t trust it.

“When AI touches very sensitive parts about your safety, your money, did you trust AI? I think that is the one big blocker. We do AI agents sometimes, but it’s a human being thinking: do I really trust the AI?”

This isn’t just about consumer products. The same barrier exists for enterprise AI agents making decisions about revenue recognition, medical records, or compliance reporting. Trust isn’t about raw capability, it’s about consistent, explainable, auditable behavior.

The successful 5% of AI agents? They all have one thing in common: human-in-the-loop design. They position AI as an assistant, not an autonomous decision maker. They create feedback loops where the system learns from corrections. They make it easy for humans to verify and override.

Memory Isn’t Just Storage, It’s Architectural

Everyone wants to “add memory.” But memory isn’t a feature, it’s a design decision with UX, privacy, and system implications.

Levels of memory:

• User level: preferences (e.g., chart types, style, writing tone)

• Team level: recurring queries, dashboards, runbooks

• Org level: institutional knowledge, policies, prior decisions

Most startups hard-code memory into app logic or local storage. But the best teams abstract it as a context layer + behavior layer, versioned and composable. One speaker described this as:

“Semantic memory + taxonomy + runbooks = context.
Individual preferences = memory.”

Memory as personalization

At the application level, memory serves two purposes:

1. Customizing behavior to individual users, their writing style, preferred formats, domain expertise

2. Proactive assistance based on events and metadata, not just reactive chat responses

One team described building a conversational BI tool at Uber. The cold-start problem? Users don’t know what to ask. The solution? Build memory from their past query logs, then suggest relevant questions as conversation starters, like a good host who remembers what you talked about last time.

But here’s the tension: when does helpful personalization cross into creepy surveillance?

One panelist described asking ChatGPT for family movie recommendations, only to have it respond with suggestions tailored to his children by name, Claire and Brandon. His reaction? “I don’t like this answer. Why do you know my son and my girl so much? Don’t touch my privacy.”

Design tension:

• Memory improves UX and agent fluency

• But over-personalization can creep into privacy territory fast

• And shared memory can break access controls unless carefully scoped

There’s a missing primitive here: a secure, portable memory layer that works across apps , usable by the user, not locked inside the provider. No one’s nailed it yet. One panelist said if he weren’t building his current startup, this would be his next one.

If you’re building this, call me.

Multi-Model Inference & Orchestration Patterns

Another emergent design: model orchestration.

In production, you don’t just call GPT-4 for everything. Teams increasingly run model routing logic based on:

• Task complexity

• Latency constraints

• Cost sensitivity

• Data locality / regulatory concerns

• Query type (e.g., summarization vs semantic search vs structured QA)

Example pattern:

• For trivial queries → local model (no network call)

• For structured queries → call DSL → SQL translator

• For complex analysis → call OpenAI / Anthropic / Gemini

• Fallback or verification → dual-model redundancy (judge + responder)

This is closer to compiler design than webapp routing. You’re not just “sending to LLM” , you’re running a DAG of decisions across heterogeneous models, tools, and validations.

Why it matters:

If your system gets slower or more expensive as usage grows, this is the first layer to revisit. And if you want AI to feel seamless to users, routing can’t be brittle or hand tuned forever. You’ll need adaptive policies.

One team described their approach: simple questions go to small, fast models. Complex reasoning tasks get routed to frontier models. The key insight? The model selection itself can be learned over time by tracking which queries succeed with which models.

When Is Chat Actually the Right Interface?

Not every task needs a chatbot.

One audience member challenged the premise directly: “I’m not sure natural language is always preferable to a GUI. If I’m ordering an Uber, I don’t want to speak to a phone. I just tap, tap, tap, I’ve got my car.”

The panel’s consensus: conversation works when it removes a learning curve.

For complex tools like BI dashboards or data analysis where there’s traditionally been expertise required, natural language lowers the barrier to entry. But once you have an answer, users often want GUI controls, switching a pie chart to a bar chart shouldn’t require more typing.

The hybrid pattern:

• Start with chat for zero-learning-curve entry

• Provide GUI controls for refinement and iteration

• Let users choose their mode based on task and preference

One panelist described two perfect use cases for NLP:

1. Sporadic, emotional tasks, like customer service, where someone is frustrated and just wants to vent or get help without navigating menus

2. Exploratory, open-ended queries, like “find me an Airbnb near California, first row, with an ocean view and blue sky” where the requirements are complex and contextual

The key insight: we should understand why people want to use natural language and design for that intent, not force every interaction into chat.

What’s Still Missing (and Where Builders Can Win)

Several ideas came up that feel underexplored , real primitives waiting to be productized:

Context observability

What inputs consistently improve output? What kinds of context lead to hallucination? How do you test context like you test model prompts?

Right now, most teams are flying blind, they don’t have systematic ways to measure which context actually helps vs hurts model performance.

Composable memory

Could memory live with the user (not the app), portable and secure, with opt-in layers for org vs team vs personal state?

This solves two problems:

1. Users don’t have to rebuild their context in every new tool

2. Privacy and security are user-controlled, not vendor-locked

This is the biggest missing primitive in the stack.

Domain aware DSLs

Most of what business users want is structured and repetitive. Why are we still trying to parse natural language into brittle SQL instead of defining higher-level, constraint safe DSLs?

One team suggested that instead of text-to-SQL, we should build semantic business logic layers, “show me Q4 revenue” should map to a verified calculation, not raw SQL generation.

Latency aware UX

One panelist described a memory enhanced chatbot that responded slowly, but delightfully. Why? It showed a sequence of intelligent follow-ups based on what the user had asked last week.

There’s a UX unlock here for async, proactive AI , not just chat. Think: agents that prepare briefings before your meetings, surface relevant context when you open a document, or alert you to anomalies in your data before you ask.

The key insight: different tasks have different latency requirements. A joke should be instant. Deep analysis can take 10 seconds if it’s showing progress and feels intelligent.

What I’ll Be Watching

I left this panel with stronger conviction that we’re about to see a wave of infra tooling, memory kits, orchestration layers, context observability, that’ll look obvious in hindsight. But they’re messy and unsolved today.

The next real moats in GenAI won’t come from model access, they’ll come from:

• Context quality

• Memory design

• Orchestration reliability

• Trust UX

If you’re a founder building infra, apps, or agents: how much of your roadmap explicitly addresses those four?

Founders: 5 Hard Questions to Ask Yourself

Try these as a context/agent system builder:

1. What’s my app’s context budget?
(What size context window is ideal, and how am I optimizing what goes into it?)

2. What’s my memory boundary?
(What lives at the user level vs team vs org? Where is it stored, and can users see it?)

3. Can I trace output lineage?
(Can I debug an LLM response and know which input led to it?)

4. Do I use one model or many?
(How am I routing requests by complexity, latency, or cost?)

5. Would my users trust this system with money or medical data?
(If not, what’s missing from my security or feedback loop?)

If you’re building in this layer, I want to hear from you. Especially if you’re doing it before everyone else calls it infrastructure.

And if you’re a technical reader, especially in infra or AI/ML, let me know: would you want a deeper series on context pruning patterns, building dual layer context systems, memory abstractions, or governance by design?

Or just reply with your biggest “context engineering” headache right now, I’d love to dig into it.

Leave a comment

Share

More essays: Semantic layers, Fine Tuning, Founder Mental Software, Normalizing the Founder Journey, AI Engineer World’s Fair 2025 - Field Notes

The question hangs on the wall in elegant typography: "What are things for?" But as I walked through MUDE's chronological journey from 1900 to 2020, I realized I was seeing more than design history. I was witnessing how each era's deepest anxieties and aspirations crystallize into objects, and getting a preview of how our AI moment will be remembered by future museum visitors.

The exhibition poses even deeper questions: "How do ideas materialise in things and, over time, what influence do they exert? What are the dreams, visions, utopias, or dystopias of the creators of ideas that give rise to things? Do we really need so many things to live our lives? What meaning should be given to new things? Do we even need new things?"

These questions hit me with particular force because I spend my time thinking about software, the most prolific "things" humans now create. The museum's approach reveals "the how and why of things being imagined, planned, drawn, produced, materialised, accepted, perceived and consumed." That sequence matters: before anything else, we imagine. In our AI era, imagination has become the bottleneck, not execution.

The Power of Imagination First

The museum's insight about "the how and why of things being imagined, planned, drawn, produced, materialised, accepted, perceived and consumed" reveals something crucial: imagination comes first in the sequence. Before we can build responsibly, we must imagine responsibly.

In our AI moment, this is both our greatest opportunity and our greatest risk. When imagination is democratized, when anyone can prompt a model to generate code, content, or analysis, the quality of our imagination becomes the determining factor. The museum's provocative questions apply directly: "Do we really need so many things to live our lives? What meaning should be given to new things? Do we even need new things?"

Replace "things" with "AI applications" and the urgency becomes clear. Do we need another chatbot, another content generator, another automation tool? Or should we be imagining software that genuinely elevates human capability while respecting planetary boundaries?

Givenchy/Alexander McQueen Dress and cape 1997, Jean Paul Gaultier Jumper 1997

Five Threads Through Time

Across 120 years, the exhibition reveals objects as mirrors of collective questions. Five leitmotifs run through every room, as relevant to today's AI builders as they were to yesterday's furniture makers:

Purpose: Why should this exist? The progression from Belle Époque prestige objects to today's survival-focused, circular design reveals changing answers to fundamental questions of value.

Material & Technique: What new medium is available and how do we tame it? Each era grapples with its transformative material: steel, plastic, digital bits, and the social implications of new capabilities.

Politics & Power: Who controls the narrative? From World Fair nationalism to Estado Novo propaganda to brand cults, every "thing" embeds someone's vision of how society should work.

Consumption & Identity: How do "things" say who I am? The evolution from luxury Art Deco to postmodern excess to DIY counter-culture shows how objects become identity markers.

Responsibility: What debt do we owe the planet and society? The arc from early craft revivals through the anti-design movement to today's reuse/recycle/repair ethos reveals growing consciousness of consequence.

Dieter Rams, Hans Gugelot Braun SK 61-S radio and record player 1956

The Rhythm of Technological Transformation

What struck me most was the predictable rhythm each transformative technology follows:

1900s: Optimistic Display

The Belle Époque mentality: "Exhibit modern identity abroad." Portugal's Universal Exhibition pavilion embodied confident nationalism. A Paródia newspaper caricatures mocked tradition while celebrating progress. The question was simple: how do we show the world we've arrived?

AI parallel: Today's AI demos and capabilities showcases. We're still in the "look what's possible" phase, focused on impressing rather than integrating.

1920s-30s: Democratizing Function

"Do more with less" became the modernist rallying cry. Buckminster Fuller's cantilever seats and Bauhaus-influenced chairs promised democracy through rational design. The belief: good design could be mass-produced affordably, making quality accessible to all.

AI parallel: The promise that large language models will democratize sophisticated reasoning, that no-code AI will make programming accessible to everyone. Same utopian energy, same faith in technology as social leveler.

1930s-50s: Appropriation and Propaganda

The Portuguese Estado Novo's "Good Taste Campaign" showed how authoritarian regimes co-opt modernist aesthetics. Traditional craft vocabulary was pressed into nationalist propaganda. Clean lines became tools of control.

AI parallel: This is our current inflection point. Who controls the training data? Whose values get "aligned"? When AI systems scale to billions of users, what assumptions are we baking in? The same aesthetic neutrality that made modernist design appealing to dictators makes AI systems attractive to would-be controllers of information.

1945-60s: Reconstruction and Mass Hope

Post-war optimism channeled into "Good Design",durable, affordable objects for everyone. The Vespa scooter, Eames furniture, and the Isetta microcar embodied democratic access to mobility and comfort. Function met mass production.

AI parallel: We're entering this phase now. AI-powered tools for education, healthcare, creative work,the practical applications that could genuinely improve quality of life at scale.

1960s-70s: Miracle Materials and Growing Doubt

Alain Resnais' Le Chant du Styrène celebrated plastic's "resistance, versatility, plasticity, lightness, durability, and low cost." But Victor Papanek simultaneously pioneered social design, critiquing consumerism and calling for environmental responsibility. Plastic went from miracle to menace in a single decade.

AI parallel: We're living through this same inflection point. Compute abundance mirrors plastic's early hype, but energy costs and e-waste concerns are mounting. The initial euphoria over AI capabilities is giving way to questions about environmental impact, labor displacement, and whether we're solving real problems.

1980s-90s: The Designer Superstar Era

Gilles Lipovetsky's "Era of Emptiness": utilitarian objects became status symbols, design became pure surface. Alessandro Mendini's "Proust" armchair exemplified postmodern excess, function divorced from form, meaning from utility.

AI parallel: When every startup can access frontier model capabilities, differentiation moves toward branding and artificial scarcity. We see AI companies creating "designer" models and cult-like followings around commodity capabilities. The risk of AI becoming about lifestyle brands rather than substance.

1990s-2020s: Planetary Consciousness

The return to purpose. "Reuse-Recycle-Repair" flat-pack furniture, bio-inspired textiles, nomadic home goods designed for a climate-conscious, digitally networked world. Traditional crafts gained new relevance as ecological practices proved valuable "in the context of the current environmental emergency."

AI parallel: This is where we need to go,and where the most thoughtful builders are already heading. After the initial AI hype cycle, there's growing appreciation for craft, for deep architectural thinking, for systems that consider their full impact.

Victor Palla & Bento d’Almeida Room Divider 1956

Curating the Next Room: "What Are Models For?" (2020-2050)

Standing in the museum's final room, I imagined the exhibit labels that future curators might write about our era:

"Intent Compiler" Workstation (2024) Voice-to-software pipeline translating a startup's spec into running backend; celebrated for "designing the invisible."

"Carbon-Miser" Language Model Card (2027) First foundation model to publish a live energy dashboard and auto-throttle itself to stay within a user-set footprint.

"Reposcope" Circular-AI Repository (2029) Open platform where discarded model checkpoints are mined, remixed and redeployed,turning 'waste compute' into raw material.

"Commons Contract" Wallet (2032) Cryptographic wallet that tracks data-set lineage and pays micro-royalties to original contributors when derivatives are commercialized.

These aren't science fiction, they're extrapolations of patterns the museum revealed. Every era eventually develops resource consciousness, circular practices, and tools that honor the full lifecycle of creation.

Thomaz de Mello Bedroom furniture; dressing table 1942

The Five Questions for AI Builders

MUDE's leitmotifs translate directly into questions every AI company should ask:

Purpose: What human capability are we genuinely enhancing? Why should this model exist rather than a simpler alternative?

Material & Technique: How do we treat compute, data, and human attention as the finite resources they are?

Politics & Power: Whose worldview are we encoding? Who benefits from our choices about training data, safety measures, and access models?

Consumption & Identity: Are we creating tools that help people think better, or status objects that signal belonging to an AI-native tribe?

Responsibility: What are the second and third-order effects of deploying this capability at scale?

MUDE Museum Design Lisboa 2025

The Museum's Answer

Walking back into Lisbon's afternoon light, I understood why this exhibition moved me so deeply. Every transformative technology goes through the same cycle: utopian promise, widespread adoption, unintended consequences, excess and reaction, and finally, if we're fortunate, wisdom.

The most beautiful objects in the exhibition weren't the most technically innovative or aesthetically striking. They were the ones where you could sense the maker's deep consideration of human needs within material and social constraints. A chair that perfectly supports the human form using minimal steel. A poster that communicates with clarity while respecting the viewer's intelligence. A system that hides complexity while enabling capability.

The museum's answer to "What are things for?" is clear: they're for serving human flourishing, but only when their creators have deeply considered purpose, context, and consequence.

MUDE's curatorial statement reveals its deeper ambition: "The museological intention to provoke discussion on current development models and the urgency of economic slowdown. The vision put forward by the MUDE – Design Museum, more than merely encouraging debate on the changes needed, seeks to position MUDE as a driving force in making them happen."

This is exactly what we need now in AI: not more parameters or faster inference, but deeper consideration of what we're building and why. We need to become driving forces for imagining beautiful software, systems that are thoughtfully architected, elegantly designed, and worth the resources they consume. The question "What are things for?" should hang in every startup office, every research lab, every design review.

Because 120 years of design history suggests that technologies become truly beautiful, and truly lasting, only when their creators grapple seriously with all five leitmotifs. When they ask not just "can we build this?" but "what is this for, who does it serve, and what world does it help create?"

The choice is still ours to make. But the museum's survey suggests we'd better choose with the same intentional craftsmanship that has always distinguished lasting design from mere novelty.

Our era's fingerprint will be intent-shaping, self-aware, resource-sober AI systems, immaterial in form yet deeply material in impact. Let's curate them with the same courage, craft, and conscience that past designers applied to steel, plastic, and wood.

Share

More essays: Founder Mental Software, Normalizing the Founder Journey, Agentic systems: panning for gold, AI Engineer World’s Fair 2025 - Field Notes

For decades knowledge work has been single‑threaded: open an app, issue a command, wait. Background AI agents break that bottleneck by letting dozens of task‑specific models run in parallel, each quietly advancing your goals while you sip coffee.

We see the prototype of this future in software engineering today. Tools like Devin spin up isolated sandboxes, write code, and open pull‑requests overnight. Founders I back now spend more time curating task lists and reviewing diffs than typing functions. They have effectively graduated from developer to project manager of 30 ever‑improving interns.

Expect those practices to permeate every corner of knowledge work. Sales teams will launch lead‑qual agents after hours; lawyers will wake up to red‑lined leases; recruiters will arrive to pre‑screened candidate pools, each with a dashboard for quick approve / reject / tweak loops.

Credit to Yaroslav Bulatov for the image generation. While we are using background agents, the AI gets better because of the work we do. Human feedback is key for AI improvement.

The Human Loop: Approval, Taste & Trust

Full autonomy is sexy on stage, but partial automation wins in production. People are too hung up on "demos" of full AI automation and are missing the real opportunities around partial automation. By design, high‑impact agents:

1. Ask for permission where confidence is low.

2. Learn your taste from each correction.

3. Surface rationale so you’re never flying blind.

That feedback cycle - AI drafts, human edits, AI retrains - shrinks turnaround time without surrendering control. The result feels less like delegating to a black box and more like wielding a super‑powerful co‑pilot.

Injecting Intelligence - Without Driving Users Crazy

Picture any long‑form text that’s been blasted through a generic machine‑translation engine: the gist lands but idioms fall flat and authorial voice gets sanded off. A smarter agent could draft 90 % of the work, then let a bilingual editor define phrase‑class rules ("use translation A for this idiom, translation B for that one"). Those preferences ripple across the entire book, audiobook script, subtitle file, or support knowledge‑base, AI does the heavy lifting while the human applies nuance. The interaction model between user and AI is going to be a subtle thing. Software should provide the power in the right places and with the right controls.

For high‑stakes domains, pair your doing‑agent with a reviewing‑agent, an LLM trained on policy, tone, or legal constraints, to catch errors before a human sees them. “Delegate but verify” scales trust. Design becomes a dialogue: the system proposes, the human disposes, the model improves, and annoyance turns into delight.

What Great Founders Must Still Do

Yes, everyone now has access to the same foundation models. Differentiation shifts to:

• Novel UX: delighting users with invisible AI until the moment it matters.

• Data capture & context: owning the ingestion layer (email, Slack, calls) and the actions on top—graduating systems of record into systems of action.

• Audacious vision: being just delusional enough to ship a demo that feels like science fiction and then scaling it.

Case‑Studies in the Wild

Below are four snapshots that surfaced during the panel, each illustrating how delusional audacity plus pragmatic agent design can bend reality:

1. Filip & Wordware

Wordware’s team deliberately chose a slightly “sub‑optimal but AI‑legible” stack so agents can maintain code faster than humans ever could. Filip now manages 30 parallel agents like interns: they write PRs overnight, he reviews a dashboard at breakfast, and an agent‑tester flags regressions before code merges. The result is speed that feels unfair.

2. Background Agents for Therapy & Culture

Filip records every therapy session and dumps transcripts into a private context window. A custom agent surfaces recurring themes and coaching prompts—giving him what he calls “billionaire‑level mental health support” on demand. Inside his startup he runs a Slack‑scraper agent that compares messages and Linear tickets against quarterly goals, then pings him about alignment gaps or even brewing interpersonal conflicts.

3. Lease‑Lawyer Agents: Flat‑Fee Review at Machine Speed

A boutique real‑estate attorney exported years of redlines into a structured Google Sheet, then wired an agent to apply those rules to fresh documents. Now the AI reviews massive commercial leases overnight; the lawyer spends 30 minutes spot‑checking and emails the client a polished memo. Hourly billing felt dishonest, so she flipped to a per‑lease flat fee, pocketing higher margins while clients get next‑day turnaround. A textbook example of agents compressing intent and widening access to expert services.

4. Lovable & ElevenLabs: Winning with Audacity

Lovable should have been swallowed by Wix; ElevenLabs by the big speech labs. Both survived, and are thriving, because founders shipped jaw‑dropping demos long before the incumbents moved. Their edge isn’t raw model power; it’s risky UX choices that users fell in love with.

5. Granola.ai: Data, Context, and the Long Game

Granola gives meeting transcription away at near‑zero margin, quietly building the richest corpus of conversational work data. The obvious play is an agent layer on top—turning those transcripts into automatic summaries, task extraction, even follow‑up emails. Owning the ingestion layer first positions them to evolve from “system of record” to system of action.

A Day in 2028

Picture a typical San Francisco operator:

• Morning walk: earbuds in, personal agent summarizes yesterday, proposes priorities, books a follow‑up brunch.

• Deep‑work block: collaborates with a large model like Claude to develop ideas, then approves agent‑written memos for distribution.

• Reactive hour: 5‑6 p.m. triage of only escalated items; everything else already handled or scheduled.

For remote workers the cadence flexes further: a few bursts of approvals might suffice to run an entire side business from Bali.

Job Security, Skills & the Email Every 6 Minutes Problem

Jobs don’t vanish wholesale; tasks do. Data entry, rote search, and endless inbox grazing (the average knowledge worker checks email every six minutes) will look like manual farming to our kids. Skills that rise in value:

• Agent orchestration and prompt design

• Domain taste & judgment

• Emotional intelligence, conflict mediation beats spreadsheet wrangling

Closing Thought

Background agents aren’t merely a productivity hack; they’re a new canvas for human creativity. The sooner we craft them to respect our attention, learn our preferences, and surface only the truly important, the sooner work transforms from reactive slog to intentional craft.

Let’s build that future, and invest in the founders bold enough to paint it.

If you are a founder thinking about AI for Work, please reach out, I’d love to meet you even at the chain-of-thought phase. It’s an invitation to a conversation vs a pitch.

Leave a comment

Share

If you like this essay, consider sharing with a friend or community that may enjoy it too.

More essays: Founder Mental Software, The Unfiltered Truth About Early-Stage M&A, Agentic systems: panning for gold, AI Engineer World’s Fair 2025 - Field Notes

By understanding the typical learning phases founders experience, I can not only better identify promising entrepreneurs but also better support them through each transition. Let me break down what I've observed in each phase:

1. Messaging Phase

Mental Software Requirements:

• Core System Prompt: Must be anchored in solving a real problem

• Belief Network: Requires strong conviction despite minimal external validation. The conviction is stronger if it’s specific to their domain expertise.

• Attention Allocation: Focused on language precision over feature development

During this phase, founders are defining the language that will shape their product and company. The best founders understand that language comes first – not the other way around. While most founders rush to build features and then "put language on it," exceptional founders realize that the exact words they choose to describe their product tells both themselves and their users what they're doing. Your language defines your focus, direction, and relevance.

I evaluate founders in this phase by observing how precisely they can articulate their value proposition and how deeply they've thought about their users' psychology.

Practical tips for founders -> I’ve seen conferences work really well for finding high user density and having a lot of experiments on messaging, set a target of the number of conversations you must have before you return home.

2. Hiring Phase

Mental Software Requirements:

• Social Interface Protocol: Ability to attract top talent with limited resources

• Value Framework: Willingness to delegate significant authority to early hires

• Feedback Processing: Open to reshaping ideas based on new team input

Here, founders must transition from individual contributors to team builders. The quality of early hires fundamentally shapes a company's trajectory. Great founders in this phase demonstrate excellent judgment in people, investing time in developing the leaders they bring on, and delegating real responsibility. They understand that hiring is not just about filling roles but about finding partners in their mission.

I look for founders who prioritize character and alignment over skills alone, who are honest about gaps in capability, and who can articulate clearly what they need in teammates.

Practical tips for founders -> Before you start hiring, sit down with your cofounder and write a list of the things both of you appreciated in people you worked with and those that you did not. That is your company culture, even if you don’t have a team. As you are hiring, evaluate which employees are doing the best and update your guide on filtering for culture in the hiring process. In my experience of seven years as an investor in the Bay Area, I’ve rarely seen a hire mismatch because of lack of technical ability, it often comes down to culture.

3. Building Phase

Mental Software Requirements:

• Belief Network: Strong technical intuition or product vision

• Attention Allocation: Balances vision with execution details

• Emotional Architecture: Handles feedback without becoming defensive and updates belief network based on data and not speculation

This is where the rubber meets the road. Founders must transform ideas into working products, often with limited resources. The strongest founders during this phase maintain a balance between vision and pragmatism. They're in the details without getting lost in them, and they can course-correct without abandoning their core mission.

I evaluate founders by assessing their understanding of technical tradeoffs, their ability to make smart scope decisions, and how they manage the tension between speed and quality.

Practical tips for founders -> if you have many passionate people who are ripe with ideas, but you lack a leader who built enterprise products before, your product will bloom in a thousand directions. Often individual contributor founders get this step wrong. Stay razor focused on the simplest version of your product to get you to the next stage - e.g. 100 users, 1000 users, a funding round. Do not build something in if its not a game changer for users early on.

4. Selling Phase

Mental Software Requirements:

• Core System Prompt: Deep empathy for customer needs

• Social Interface Protocol: Ability to build relationships with early adopters

• Emotional Architecture: Resilience in the face of frequent rejection

During this phase, founders must secure their first customers – often without a fully-baked product.

Great founders don't just sell features; they sell a vision and relationship. They understand their customers' psychology and can position their product as a crucial solution to a pressing problem. It helps if you are selling to people in the domain that you are an expert in. e.g. a doctor selling to hospital execs.

I look for founders who actively listen to prospects, who can adjust their pitch based on feedback, and who show genuine curiosity about customer needs.

Practical tips for founders -> engineer founders typically will try to postpone monetization as long as they can, they’d rather build instead of selling. Then they’ll try to hire an SDR which will often not work. Only by time pressure will they try to sell and then it might be too late. Every person can learn to sell. I am an ML engineer by background, and I know the mindset, but also that helped me develop a framework/psychology that resonates with other fellow engineers and have seen founders go from zero to closing six figure contracts and loving to sell so much. This topic requires an own blog post in itself.

5. PMF/~1M ARR Phase

Mental Software Requirements:

• Feedback Processing: Can identify patterns in customer adoption

• Value Framework: Willingness to narrow focus to double down on what works

• Belief Network: Ability to distinguish signal from noise in market feedback and update the belief network itself

This phase feels like standing at a fork in the road. One path leads to scaling; the other, to slow decay hidden behind early revenue. At ~$1M ARR, founders are often tempted to believe they've "made it." But the truth is: none of this stuff matters unless two deeper forces are working in your favor:

1. You're playing in a massive market.

2. You're driven enough to refuse giving up when it gets hard.

Even great execution can’t turn a puddle into an ocean. If early traction suggests you’re fishing in a small pond, then don’t spend years building a palace around it — jump ponds. The best founders stay loyal to solving a customer pain — not loyal to their first wedge if it points to a tiny addressable market.

I evaluate founders by their understanding of their key metrics, their iteration velocity, and their ability to make tough decisions based on market feedback.

Practical tips for founders -> if you can get to $250k/$500k, you can get to a million. Pay attention to where you’re getting the most heat with customers and going after that customer segment I’ve seen work really well. For developer tools, I’ve also seen it work well hiring a Developer Relations person, but not one who did the job before, but one who is a passionate user in your slack channel/community who kinda already behaves like a Developer Relations/Advocate for your product without being paid.

6. Founder Sells Assisted by Team <$30M ARR

Mental Software Requirements:

• Social Interface Protocol: Can build and lead a sales organization

• Attention Allocation: Shifting focus from product to distribution

• Core System Prompt: Evolution from builder to leader

Getting to $1m ARR is the stage where VCs invest more money so founders think they have the funds and expectation to hire a sales team, but it's really just wasted effort. The goal of a sales team <$30m ARR should be to amplify the founder's ability to sell, not have the team separately sell. Until $30M ARR, sales is just doing basic order taking. Exceptional founders in this phase understand that scaling sales is not just about hiring salespeople but about creating systems, processes, and culture. They codify what works and can transfer their knowledge effectively.

I assess founders by their ability to learn to sell, hire the right sales talent, implement effective sales processes, and maintain product integrity while scaling distribution.

Practical tips for founders -> The bottom line is selling is hard but learnable, and it’s even harder when you have to transition from just you selling to now you are assisted by a team selling. The typical trap is hiring sales, not monitoring for success in the first few months, letting too much time to pass before you fire them, spiraling thinking you failed, the revenue stales or you have negative growth and you start thinking of selling instead of thinking you need different people to try and replicate what you did before. Because you sold before, you know that it’s the sales person not the product that’s not working. Almost everyone gets hiring for sales wrong at first, but there are ways to succeed. You’re not broken, it’s hard for everyone. Reach out if you’re struggling with this.

7. Triple Double Phase

Mental Software Requirements:

• Attention Allocation: Balanced focus across multiple growth dimensions

• Emotional Architecture: Handling increased pressure and expectations

• Feedback Processing: Rapidly incorporating learnings from multiple channels

In this phase, founders must scale rapidly across all dimensions – team, product, and revenue. The name refers to achieving substantial growth in multiple metrics simultaneously. The most successful founders here maintain discipline and execution while scaling. They understand how to implement processes without stifling innovation and how to maintain culture through rapid growth.

I evaluate founders by their ability to manage complexity, delegate effectively while maintaining standards, and continue innovating despite organizational pressures.

Practical tips for founders -> AI has introduced new growth/churn behaviors, but the fundamentals of a healthy business have not changed. Scale Venture Partners, has great blogs on metrics for growth, efficiency and observed patterns that are really useful to founders. You don’t have to guess how you’re tracking, you can measure yourself in Scale Studio.

Why It's Never Too Early to Meet Founders

This framework explains why I believe it's never too early to meet founders – even at the chain of thought phase. By understanding a founder's mental software early on, I can:

1. Identify exceptional talent before traditional signals emerge

2. Provide targeted support based on where they are in their learning journey

3. Build authentic relationships based on mutual understanding

4. Help normalize the challenges they'll face at each phase

Great founders aren't born with perfect mental software; they continuously update and refine it.

By meeting founders early and often, I can observe not just their stated principles but their operational behaviors over time.

Like complex software systems, human minds often have both documented functions (what we say we believe) and actual implementations (how we actually operate), with fascinating discrepancies between them.

My Approach as Your VC Partner

I see my role as more than capital — it's partnership through the psychological journey of building a business. As an investor, I see multiple businesses being built, which is why I can help normalize your experience.

If you're a founder in the early stages of building, or even just starting to think about it, I'd love to connect. I invest at the pre-seed and seed stages, and I enjoy meeting founders long before the world sees what you're building. I don’t need a deck.

And if you're someone interested in the ideas I share here and how I think about investing, I always enjoy connecting with others who believe in backing extraordinary potential early.

Leave a comment

Share

If you like this essay, consider sharing with a friend or community that may enjoy it too.

More essays: Founder Mental Software, The Unfiltered Truth About Early-Stage M&A, Agentic systems: panning for gold, AI Engineer World’s Fair 2025 - Field Notes

The industry loves frameworks: Big-Five traits, pattern-recognition grids, neat archetypes that pretend to decode a person in thirty minutes. I've used them all. What I learned is simple: the actual differentiator is relational. I invest time to understand founders deeply, so they feel seen rather than analyzed.

Here's the invitation: Step into a space where you're seen rather than dissected - where no one tries to reshape you into something else.

In a world where everyone's having the same conversations at the same dinners, where conformity looks like Menlo School → Stanford → the "right" firm, your different mental software isn't a liability. It's the only real advantage left.

The venture world has gotten incredibly efficient at pattern matching. But that efficiency has created massive blind spots. While everyone chases the same AI companies, the real opportunities are being built by people whose mental software was forged outside the consensus machine - people like:

1. Second-time founders not repeating the same playbook

2. Technical builders who haven't mastered narrative polish

3. Immigrant founders who don't slot neatly into YC pitch cadence

4. People whose modest resumes hide massive upward slopes

5. People building outside the current hype map - in overlooked markets, weird categories, formats that don't yet have names

Psychology describes traits; relationship surfaces truth. When founders recognize they're finally being understood, trust compresses months into hours.

That's the edge - not a reinvention of frameworks, but a commitment to meet builders who live outside the hype map and say: "Stay exactly as weird as you are."

Mental Software: The Operating System of Great Founders

Just as computers run on software, humans operate on mental frameworks that determine how we process information and interact with the world. Drawing parallels with language models (LLMs), we can think of a founder's mental software as comprised of several key components:

1. Founder System Prompt (Foundational Identity)

This is a founder's "system prompt" - the conscious and unconscious core beliefs that shape how they see themselves, their company, and reality itself.

The best founders can articulate (or at least express) beliefs like:

• A deeply rooted sense of purpose beyond making money

• An identity built around solving important problems

• A unique perspective on what should exist in the world

I listen for recurring themes in their personal stories and watch their instinctive responses to new situations. This reveals more about their potential than any pitch deck.

Take one founder whose religious father told her from childhood: "Do good on the largest possible scale." She built software to treat hundreds of patients simultaneously. Every product decision - from day one - was made with massive scale in mind. Her system prompt was hardwired for impact.

2. Reward Model (Values & Priorities)

A founder's values are their personal reward model - governing which trade-offs feel obvious, which shortcuts feel toxic, and where every marginal hour goes. Infinite money, finite integrity.

Great founders consistently:

• Choose long-term thinking over short-term gains

• Show extreme commitment despite uncertainty and failure

• Allocate resources toward ambitious, mission-aligned goals

I watch how founders actually spend their time and how they react when values meet constraints.

One team rewrote their entire codebase in Golang on a tight deadline purely because their community requested it. Re-engineering your product mid-flight isn't rational - unless user trust is your true north. DevOps engineers loved the performance boost.

The opposite: a seed startup where each office visit revealed more expensive furniture but fewer paying customers. Their reward model prioritized appearances over substance.

3. Belief Network (Knowledge & Assumption Structure)

A founder's web of assumptions about how the world works shapes every decision - like an LLM's training data influencing its outputs.

The best founders have:

• Strong convictions about the future - clear beliefs about what's coming and how they're positioning to make it reality

• Contrarian thinking that challenges the status quo - ideally beliefs that are early and non-obvious

• Deep domain expertise, either technical or industry-specific

I evaluate this by watching their predictions, noting their authoritative sources, and understanding their explanations for why things happen.

The key question: Are they following early signals from real builders and customers, or waiting for "truth" from Gartner and McKinsey?

One creates authority by building the future. The other follows paths someone else laid down.

4. Feedback Processing System (Learning & Adaptation Mechanism)

How founders update their mental models based on new information - like fine-tuning an LLM over time.

Exceptional founders:

• Filter advice through their vision - You'll get contradictory counsel from proven experts. Without a clear vision, you can't distinguish good advice from bad.

• Learn rapidly from everything - They know which assumptions need validation next and tackle unknowns in priority order, maintaining clear line of sight to the end goal.

• Show exponential personal growth trajectories

I watch how they respond to contradictory information and track belief changes over time.

Example: I told an engineer-turned-CEO he needed to learn sales and introduced him to a similar founder who'd crossed $50M ARR. He went from avoiding sales entirely to closing six-figure deals. Months later: "I love selling, Oana. I have a hard time delegating because I love it so much."

The best founders don't just take feedback - they metabolize it.

5. Emotional Architecture (Feeling & Motivation System)

A founder's emotional framework drives behavior - like an LLM's output filtering system determining what actually gets expressed.

The best founders:

• Run on intrinsic motivation rather than external validation

• Show high resilience - your ability to survive the worst times makes your company far more likely to succeed

• Balance vision optimism with execution pragmatism

Everyone rides the startup rollercoaster. But founders must endure it for years without flaking out.

I'm wary of people with flaky career patterns - the journeymen who never stick through to the end. Emotional durability isn't just nice to have; it's the difference between building something meaningful and abandoning ship when things get hard.

6. Social Interface Protocol (Relationship Operating System)

How founders navigate relationships represents their human API.

Winners consistently:

• Build complementary founding teams with aligned vision and intensity

• Create strong cultures that reflect their mission and belief network

• Understand others' operating systems - their incentives, needs, and how you can help them succeed

Great founders have empathy - or at least map other people's motivations accurately. This shows up everywhere: customer experience design, team motivation, investor interactions.

Anti-pattern: A business co-founder joins a technical founder building open-source tools. Company success depends on the developer experience, but the CEO won't prioritize it because it's not relatable. Their reward model favors media appearances over learning their users' world.

The insight: If you're an engineer selling to engineers, you don't need a "business person." You need someone who understands your users' operating system. Treat relationship-building like an engineering problem - understand the inputs, outputs, and system requirements.

7. Attention Allocation Algorithm (Focus Management)

How founders decide what deserves attention functions like an LLM's attention mechanism - filtering the noise to focus on what actually matters.

The most successful founders:

• Stay deeply involved in product while delegating everything else appropriately

• Focus intensely on their mission instead of getting distracted by competitors

• Ruthlessly prioritize what matters most to their vision

Founders face a constant firehose: day-to-day operations, hiring, customer calls, investor meetings, conferences, vanity projects. It's easy to lose sight of the product.

But the best founders remain the master of their product - the best person to run a demo, dive into technical details, or explain why every feature exists. They treat attention like their most valuable resource and guard it accordingly.

An Invitation, Not a Diagnosis

For anyone who funds or builds companies: the edge isn't a superior psych model. It's the willingness to spend real time so founders feel understood before they're judged.

Everything else - pattern recognition, financial engineering, network maps - works better once that trust snaps into place. For people who've never quite fit the default template, that moment of recognition is often the first real "yes" they've heard.

If you're building something that doesn't fit the hype map - something technical, weird, or simply too early for its own category - let's talk.

Leave a comment

Share

If you like this essay, consider sharing with a friend or community that may enjoy it too.

Other essays: Founder Learning Phases: Normalizing the Journey, The Unfiltered Truth About Early-Stage M&A, Agentic systems: panning for gold, AI Engineer World’s Fair 2025 - Field Notes

Thanks to Nick, Sean, Dylan, Gyani, Vasin, Antti, Till, Piotr, Corneliu, Octav and other founders who read drafts of this.

Proud to be an investor in Digger, the open-source Terraform orchestrator that sits inside your existing CI and catches issues before they happen. The round was led by Initialized Capital, alongside founders like Olivier Pomel (CEO, Datadog), David Cramer (Co-founder, Sentry), Michael Grinich (CEO, WorkOS), Zeno Rocha (CEO, Resend).

Infrastructure is still a tax on creativity. Every new cloud primitive adds knobs and the AI boom only multiplies infra surface area; every manual review adds delay. We believe the best infra vanishes into the pull-request: visible only when it stops you from making a costly mistake. As a former engineer, I believe in this mission. Build infrastructure so invisible, the only thing developers notice is how fast they ship.

Developers: this post is for you. It breaks down two “super-powers” that make Digger hard to un-install, shares what users tell us, and explains why the problem space is only getting bigger.

Ship-Blocking Terraform Reviews != Friday Fun

Teams still hit apply after code is merged, hoping nothing breaks.
When incidents cost five-figure GPU hours, or your Monday deploy “Merge first, pray later” is untenable. Yet most Terraform automation:

• Duplicates CI (Terraform Cloud, Spacelift)

• Sends secrets to a third-party

• Charges per resource—right when infra is exploding

HashiCorp’s license switch and IBM’s $6.4 billion buy-out only amplified the frustration and the OSS backlash.

From Pipeline Sprawl to Pull-Request Infrastructure

Digger embeds Terraform plan/apply inside the CI you already run.
Two YAML lines add a GitHub Action; the CLI spins in your runner; credentials never leave.

Every infra change is reviewed exactly where you review code. No second pipeline, no new UI, no per-resource tax.

If Dieter Rams wrote code, he would say that Digger follows the principles of good design: less, but better.

Super-Power #1: CI-Native Execution

Like letting GitHub Actions sprout a Terraform brain:

• Re-uses on-demand runners → horizontal scale is “just run more jobs”

• Locks state, queues applies, and posts one running summary comment, no page reloads

• Parallelizes projects that don’t collide, shaving deploy time by double-digits

Result: 6 800 successful deployments per week, growing 19 % m/m, without a single new server to babysit

Super-Power #2: Open Source Freedom + AI Guardrails

Digger’s Apache-2 OSS core (4.5 k stars, 500 k downloads) drives a fast community loop.

On top, the new Infrabase agent parses every plan for cost, security, and compliance drift the moment you open a PR—and lets you write rules in plain English.

Think Checkov meets ChatGPT stitched straight into git diff.

What Users Say

• “Faster and more responsive than any comparable tool we've used—lets us iterate and catch issues earlier.” — Soumik Dey, Avoma

• “Locking forces collaboration between overlapping PRs… Life has been simpler ever since.” — Francois Leroux, NuEcho

When developers describe infra automation as “simpler” and “can’t ship without it,” you’ve crossed from nice-to-have into default.

Why the Market Will Only Swell

• AI sends infra surface area vertical—vector DBs, GPU clusters, agent fleets; every tweak is another Terraform diff.

• 3 billion+ downloads of the AWS Terraform provider prove IaC is the nerve center of cloud ops.

• Cost-watch CFOs now ask, “Why pay twice—once for CI, once again for Terraform CI?” Digger’s reuse model answers that.

• OSS momentum post-HashiCorp gives CI-native, self-hostable tools a tail-wind.

If You’re an Engineer—Kick the Tires

1. Install the Digger GitHub App on a repo with /terraform.

2. Open a dummy PR.

3. Watch the bot plan, comment, and (if you allow) apply—usually in <4 minutes.

If it saves you one outage or one sleepless Friday, star the repo and tell us what’s missing. I love to get product feedback and hear about modern day developer aches and pains. DM me, let’s talk!

If the next decade belongs to software that self-heals before it ships, Digger sits at the hinge: every merge request becomes an exercise in building robustness, not adding fragility. The optionality embedded in an OSS core, AI guardrails, and founders who iterate at the speed of their users renders this bet as timeless today as Linux felt at 1.0.

Leave a comment

Share

If you like this essay, consider sharing with a friend or community that may enjoy it too.

This week’s AI Engineer World’s Fair filled two floors of the SF Marriott Marquis with ~3 000 builders, Fortune-500 CTOs and the entire “LLM-OS” supply chain — from the biggest AI Labs to the tiniest plug-in author. I volunteered, scanned 318 badges, and got to meet the most interesting founders. With an eye on the scanner and a ear at the conference, here are my 10 takeaways from manning the keynote door.

1. Engineering Process Is the New Product Moat

Template everything. PRDs, design docs (ADRs), RCAs, quarterly roadmaps, and recurring meeting agendas should live in shared templates with automatic transcription. Standardisation keeps engineering and product aligned, accelerates onboarding, and surfaces best-practice gaps early.

Plan with AI, not by AI. Use models to mine context, surface constraints, and draft alternatives—then humans decide. Three-phase loop: Gather context → Collaborative discovery → Polish & visualise. AI cuts overhead but strategic intent still requires human judgment.

Documentation as context for agents. Up-to-date specs unlock agentic coding and automated doc-linting (detect out-of-sync docs, missing requirements, inconsistency). Coding agents perform measurably better when fed live system context.

2. Quality Economics Haven’t Changed—Only the Tooling

• “Higher quality = fewer defects.” The classic cost-of-defect curve still rules: a bug fixed in prod costs 30-100× the same bug caught at the requirements stage.

• Prevention stack for AI-generated code:

  1. Learn existing solutions & patterns

  2. Plan before you prompt

  3. Write specs & strict style guides

  4. Detect: static linters → unit/integration tests → LLM-based code review

• Testing guidance: write happy + unhappy paths, emphasise integration tests, run in sandboxes, measure coverage.

Bottom line: Rapid LLM productivity must be paired with classic software craftsmanship or you simply ship defects faster.

3. Four Moving Frontiers in the LLM Stack

Speakers framed every model decision as a live trade-off across four axes:

1. Reasoning vs Non-reasoning – deeper thinking adds ~9× latency.

2. Open weights vs Proprietary – open models have closed most of the IQ gap since late 2024; Chinese labs (DeepSeek, Alibaba) currently lead the open frontier.

3. Cost – >500× spread to run the same benchmark today.

4. Speed – output tokens per second keep climbing via sparsity, smaller models, and inference-optimised software.

Takeaway: Winning platforms will treat model choice as continuous supply-chain optimisation, not a one-off vendor bet.

4. Efficiency Gains vs Run-Time Demand

• GPT-4-level intelligence is now ~100× cheaper than its 2023 debut (smaller models ✕ FlashAttention ✕ new GPUs).

• Yet typical compute per user request is up 20× because: larger context windows, reasoning models emit ~10× more tokens, and agentic workflows chain multiple calls.

The infra opportunity: products that arbitrate price/perf trade-offs in real time and hide complexity from app teams.

5. How Builders Are Customising Models (Survey Data)

It was shocking to me, the amount of fine tuning that people do. If you want a recap of all the different methods, please see my writeup - Fine Tuning LLMs - learnings from the DeepLearning SF Meetup.

Audio models show the highest intent-to-adopt of any modality—pointing to an emerging wave of speech and voice products.

6. Autonomy ≠ Replacement — Lessons From Claude-at-Work

• One-third first-try success. Fully autonomous PRs land cleanly ≈ 33 % of the time; the rest need human nudges.

• Guard-rails, not hand-offs. Every repo ships a Claude.md (APIs + domain vocab); tests are scaffolded before generation; commits are tiny, checkpoint-heavy bursts for instant rollback.

• Practical takeaway: treat the model as a junior pair-programmer—speed comes from codified context plus fast undo, not from chasing 100 % autonomy.

Bottom line: Autonomy is a power-up, not a drop-in replacement; invest in context and recovery paths.

7. Jevons Paradox Hits AI Compute

• Unit cost plunges… GPT-4-class reasoning is ~100 × cheaper than in 2023 (smaller models ✕ FlashAttention ✕ new silicon).

• …but aggregate demand soars. Agents chain calls, context windows balloon, token outputs jump 10 ×, driving total compute per workflow up ~20 ×.

• Strategic implication: durable moats sit in semantic layers—ontologies & knowledge graphs—that turn cheap generic tokens into domain-specific value.

Bottom line: Falling token prices won’t lower bills; whoever owns the semantic context captures the surplus.

8. Evals Are the New CI/CD — and Feel Wrong at First

• Why it’s counter-intuitive. Seasoned engineers learn to avoid heavy eval suites for deterministic APIs—manual laptop tests catch almost everything, and “test-in-prod” is usually cheaper. That habit breeds an instinctive aversion to evals.

• Why LLM systems flip the logic. Generative pipelines are stochastic and high-dimensional; manual poking can’t approximate real-world variability. Evals for LLMs play the same role manual smoke-testing once did for REST endpoints: they’re the only sane gate before users see nonsense.

• Step-wise evaluators. Borrow Hex’s pattern: attach a pass/fail check to every hop—retrieval, planning, tool call, final answer—so errors localise instead of compounding (30 % slip per step becomes 90 % at the tail).

• Execution rule: if you wouldn’t merge without unit tests, don’t deploy an LLM chain without per-step evals and a drift dashboard.

Bottom line: Evals feel like overhead if you came up on deterministic software, but for generative systems they’re the unit tests of cognition—skip them and your agent is a lottery ticket.

9. Semantic Layers — Context Is the True Compute

• Why they matter. As I argued in “Are Semantic Layers the treasure map for LLMs?”, a well-curated ontology (tables, APIs, domain vocab) is the difference between token spit-out and task completion. Once open-weights IQ converges, the layer that maps model output to business truth becomes the moat.

• Signals from the floor.

  • “Template everything” & Claude.md files are mini semantic layers—they encode the functions, objects and style rules Claude must respect.

  • DeepSeek & Alibaba close the model-quality gap, proving that context beats proprietary weights.

  • Hex’s per-step evaluators work because each node in the DAG has a typed contract; without that semantic scaffold, evals would grade noise.

• Real-world stakes. In healthcare we ground prompts in RxNorm so an agent knows all statins, not just “Lipitor.” Autonomous driving teams fuse multiple low-probability detections (child, bike, box) into a single avoid class—another ontology in action.

• Investment lens. Semantic-layer tooling (version-controlled vocab, vector-friendly joins, RAG-ready graphs) and vertical apps that own proprietary context will capture more value than yet-another generic agent.

Bottom line: Cheap tokens are plentiful; structured meaning is scarce. Own the semantic layer and you set the terms for every model, eval and agent that sits above it.

10. Strategic Implications for Investors, LPs & Founders

1. Process maturity around docs, RCAs, and planning is becoming a due-diligence item for enterprise buyers.

2. Cost-engineering (latency, $$, carbon) is an investable layer: expect “FinOps for LLMs” tools to proliferate.

3. Data + workflow integration, not model IP, will anchor defensibility as open-weights intelligence converges on proprietary leaders.

4. Parameter-efficient customisation (RAG, LoRA) wins practical adoption today; bets on full-stack pre-training should factor longer payback.

5. Modal expansion (audio, video) is the next demand curve—founders building infra or primitives here look early but timely.

Building in that direction? Let’s chat. Also let me know which topic would you like to see a deep dive on. Leave in comments!

Leave a comment

Share

If you like this essay, consider sharing with a friend or community that may enjoy it too.

Early-stage M&A is not something people talk about in public, but many are thinking about it, especially in the bloodbath of AI. Last week, I hosted a candid "Founder to Founder" conversation featuring Divyansh Saini, who successfully sold his startup Houseware, to provide 50 fellow entrepreneurs with unfiltered insights into the early-stage M&A process.

Whether you're actively considering an exit or simply preparing for future possibilities, understanding the mechanics and psychology of acquisitions can help you make strategic decisions throughout your company's lifecycle. Selling your seed/Series A startup is not necessarily a bad thing. If you can’t raise another round of funding and generate enough revenue to raise money again, then it’s better to be honest with yourself and sell. The investors will be happy to recycle whatever money they get back. Here's what founders need to know about navigating the complex world of early-stage M&A:

1. Companies are bought, not sold – Focus on building novel technology, exceptional talent, or market positioning that larger companies can't easily replicate themselves.

2. Build relationships before you need them – Maintain ongoing connections with CEOs and CPOs of adjacent companies; the strongest acquisition signal comes when a CEO reaches out personally.

3. Know when it's time – Consider selling when: technology is moving faster than you can adapt, competition is developing similar solutions, customers are shifting to competitors, or fundraising is becoming challenging.

4. Ensure proper runway – Start with 9-12 months minimum runway when beginning the M&A process; deals take longer than expected and operating from desperation reduces leverage.

5. Align with co-founders early – Discuss exit scenarios with your founding team before they arise; if co-founders aren't aligned on selling, acquirers will notice during diligence and deals will likely fail.

Fundamental Principles: Companies Are Bought, Not Sold

The most important reality to understand about early-stage M&A is that companies are bought, not sold. As Divyansh emphasized, larger enterprises have priorities set at the beginning of each year or quarter, and it's extremely difficult for a smaller company to change those priorities.

What does this mean for founders?

Focus on creating unique value, not just revenue. Early-stage M&A rarely centers on Annual Recurring Revenue (ARR). For larger companies, adding a few million in ARR can be achieved simply by hiring more sales representatives. Even companies with around $10M ARR (typically Series A/B stage) don't get valued much above their revenue in acquisitions.

Instead, acquisitions typically focus on:

1. Novel technology that larger companies can't easily replicate

2. Team expertise and talent in specific domains

3. Strategic market position or technological edge

This perspective shift is critical - rather than focusing exclusively on growth metrics that appeal to investors, consider what unique capabilities your company has that would be difficult for a larger company to build internally.

Building Strategic Relationships for Future Acquisitions

Unlike fundraising, where there's a clear process and timeframe, M&A often results from long-standing relationships and strategic positioning. Successful founders maintain ongoing dialogue with potential acquirers long before considering an exit.

How to build these relationships:

1. Connect with adjacent players - Regularly meet with CEOs and CPOs of companies operating in similar or adjacent spaces

2. Exchange learnings without revealing core IP - Find ways to add value through industry insights without giving away your secret sauce

3. Understand Corporate Development signals - Learn to interpret interest levels:

   • Softest signal: Corp Dev reaching out for "partnerships"

   • Medium signal: CPO reaching out directly

   • Strongest signal: CEO reaching out personally

As one participant noted, "You cannot be part of that option or have them reaching out if they don't know you exist." This highlights the importance of visibility - whether through relevant communities, social media, or strategic partnerships with shared customers.

Remember: Corporate Development typically talks to 30+ companies simultaneously while collecting market intelligence, with only 2-3 advancing to serious discussions. Make sure you're positioning yourself to be among those select few.

Recognizing When to Sell: The Four Key Indicators

Timing is everything in M&A. While there's no one-size-fits-all formula for the perfect moment to sell, our conversation highlighted four critical indicators that suggest it might be time to explore an exit:

1. Market or technology moving faster than your company can adapt

2. Competition developing similar technology that threatens your advantage

3. Customer adoption shifting to competitors

4. Fundraising becoming challenging (unable to raise desired amount/terms)

In Divyansh's case, all four indicators became apparent in early 2024. A public competitor was preparing to launch similar technology, potential pivot directions would require significant runway, and fundraising conditions weren't ideal for achieving the best outcome.

Runway considerations are crucial. You need 9-12 months minimum runway when starting the M&A process, as deals take longer than founders typically expect. Operating from a position of desperation dramatically reduces your leverage.

Navigating the M&A Process Effectively

Once you decide to explore an exit, the process requires strategic thinking and patience:

1. Create a comprehensive target list

• Include non-traditional buyers (companies not known for technology or organizations looking to build new capabilities)

• 10-15 primary targets, 20-30 secondary options

2. Make direct outreach when possible

• Reach out directly to CPOs/CEOs when you have relationships

• For early-stage deals ($10M-100M), bankers typically add limited value

3. Understand what buyers truly value

• Be realistic about what parts of your business are most valuable

• For Houseware, despite building a comprehensive product, the acquirer was primarily interested in their warehouse query engine

4. Create leverage in negotiations

• Build urgency through competitive dynamics

• Align with the buyer's vision and strategic priorities

• Avoid contradicting their market thesis

5. Prepare for the timeline

• The process takes several months from initial discussions to close

• No deal is secure until final papers are signed

The Psychology of Selling Your Company

Beyond the mechanics, there's an important psychological dimension to selling your company. As Divyansh described it, "It's a jarring shift. You were so proactively looking to scale these things and build the product... Now you're like, 'Hey, I have to do the right thing for my team, my investors, myself.'"

This is where founder alignment becomes critical. If co-founders aren't on the same page about selling, the process is unlikely to succeed. One participant shared a cautionary tale: "I've seen founders where they didn't agree both to sell... It was very obvious that [one] doesn't want to sell. And it came across in diligence, and when the acquirer met them... If you don't both want to sell, you're not going to land the plane."

Key Takeaways for Founders

1. Start relationship-building early - Don't wait until you're considering an exit to connect with potential acquirers

2. Focus on unique value creation - Build technology and expertise that's difficult for larger companies to replicate

3. Monitor market signals - Stay alert to the four key indicators that might suggest it's time to sell

4. Maintain adequate runway - Ensure you have 9-12 months of runway before starting the process

5. Align with co-founders - Have frank discussions about exit scenarios before they arise

As one founder participant aptly put in their feedback: "What's the ideal time to determine when it's the right moment to exit? I understand it's a very subjective answer and will depend on a case-by-case basis, but how early is too early and how late is too late?"

While there's no universal answer to this question, the frameworks shared in our conversation can help you recognize the signals and make informed decisions when the time comes. My personal perspective is that when founders run out of ideas to try, then it’s time to pivot, or sell, or shut down. That’s because creativity is fueled by passion and when the passion dies, the force of the founding team and the energy that’s needed to succeed is going to end, even if there is money still left in the bank. As I share with all founders, I’m just one data point. If you have a different perspective, please comment or reach out to chat more.

And remember Divyansh's powerful metaphor: "Very few founders land the plane. A lot of founders abandon the plane." Preparing for a potential M&A scenario is about ensuring you have the skills, relationships, and runway to successfully land the plane when the time is right.

Leave a comment

Share

If you like this essay, consider sharing with a friend or community that may enjoy it too.

This blog post is based on insights from our "Founder to Founder" conversation featuring Divyansh Saini, who sold his startup Houseware. If you found this valuable, join our upcoming events where we'll continue to share transparent founder experiences on crucial but rarely discussed topics.Next on is on making at the top of the list on Hacker News, with a founder who did it more than 10 times, CEO of Lago https://lu.ma/3loq2b6e

More than a decade ago, when I studied echo state neural networks, AI was mainly in Academia and the main tool I had was Matlab. When I got a job at SAP, it was chatbots and orchestration engines, and now it’s Agents. While tempting to believe it’s the same thing with a new name, agents actually have something new, and it’s not just branding. What has changed is how good they have become. We’ve seen chatbots back in the day, and they did automate a bunch of work but now the immense productivity of these agents is unprecedented. They can do a lot of tasks a human would spend a lot of time on. Before, it was more rules-based, but now it can do a lot of steps and reasoning, and this year the output we get from AI has gotten even better. Now we think of Agents as an AI teammate. They go beyond one single workflow and automate an End-to-End business operation.

While the benefits are clear for agents, it’s not as clear how to obtain them. 80% of AI apps that are built for enterprise use cases fail and are not pushed to production, according to Harvard Review. How can you be in the 20% that make it? Ship AI that’s reliable. Earn your users’ trust.

Highlights

1. Build trust through pragmatic AI automation. It's crucial to recognize that success lies in embracing intermediate capabilities rather than chasing full autonomy. A good framework of what could be automated vs. not is customers' tolerance level on error rates. What’s the cost of the error

2. Reduce the hallucinations. The accuracy of the models is improving, but hallucinations will still be an issue. We need to ensure that the AI Agent is not hallucinating (fabricating inaccurate information) since, now that they can take action, they could do something very harmful.

3. Implement Agentic RAG. All companies must try to give users the ability to do tasks on their behalf all in one interface. An example of Agents plus RAG, is Persana Quantum Agent which reached 5m+ usage in the last 90 days. Customers love it.

4. Debias the data. Benchmark datasets for bias testing, make sure the agent is not saying anything harmful, and send the output back to an LLM to ask if it said anything harmful. However, also check the input thoroughly (in case user content contains harmful or biased content) before you feed it into an LLM.

5. Use tools. There are many tools mentioned to increase reliability. Some mentioned in this article that we recommend you check out are: LangGraph, Wordware, LlamaIndex, Okareo, Galileo, Arize, RAGAS, SuperAnnotate, Pinecone, and Helicone.

I will use examples from a YC Startup, Persana.ai that is building GTM AI Agents. I am not an investor. This is not a promotional blogpost. If your tools can provide value to AI builders, comment or DM, and I will include them, similarly, if you have any learnings to share on how you do LLM Reliability, please share, and I will include them. The CTO of Persana was the guest speaker of the ACM(Association for Computing Machinery) tech talk I moderated, and he also authored a book on LLM Reliability.

Building Trust Through Pragmatic AI Automation

We don’t have full Agentic AI today, the “ you can take your mind off” kind. It could take a decade to address long-tail failures, highlighting the necessity of realistic expectations and incremental advancements. There are no magic shortcuts. Today we have “hands off” AI, and this can generate a lot of business value. When deciding what to automate with AI, it's essential to take a pragmatic approach rather than chasing the dream of full autonomy. The key is to evaluate each task through the lens of risk and impact: can your customers tolerate occasional mistakes, and what would those mistakes cost? In customer support, for instance, having an AI help agents find relevant information is low-risk and high reward, while letting AI make final decisions about refunds or account closures could be costly. This is why personal injury law firms are successfully using AI to help draft demand packages - the AI assists lawyers rather than replacing them, and all output is reviewed by professionals who can catch and correct any errors. You can read more about it here.

Reduce the hallucinations

We need to make sure the AI Agent is not hallucinating (fabricating inaccurate information) since now that they can take action, they could do something very harmful. Causes for hallucinations are training data limitation, lack of real-time retrieval, and overconfidence in uncertain responses. How to reduce it:

• Choose a better foundation model (e.g. GPT4 has less hallucinations that GPT3.5)

• Tune model parameters

• Use prompting techniques

• Fine-tune your model

• RAG (Retrieval Augmented Generation)

• Agents and Tools

Chart: showing how models are improving over time

Takeaway: as the models are getting better and better, the accuracy is getting better, but hallucination is still going to be an issue

Reducing hallucinations with prompting

Use assertive voice (ALL CAPS), put rules at the start, be descriptive, use examples, add context in the prompt, and ask the model to act like an expert in your field as the model to substantiate claims (citations).

Tree of thought prompting

Instead of figuring out one path, it figures out all paths that could happen. For example, if you’re trying to solve a sudoku puzzle, you don’t know what the end board is, but if you try one number and then try the next number, and then you try the next number, you’ll eventually find the right path. You can get the LLM to build a tree for you which is going by each step. Another enterprise use case example is a customer telling a chatbot that his TV is malfunctioning. The LLM can evaluate three options:

1) Return it if it’s in the 30-day window

2) Manufacturer 1 year warranty if it is outside of 30-day

3) Replace it with a new one if it’s within 90 days of purchase

The ACM tech talk guest speaker said his favorite way to evaluate LLMs at the startup he’s building, Persana.ai is by calling another GPT or another LLM to check if the answer is helpful. You can also ask it to evaluate bias.

You can try to see what techniques work best for you - offer your model a tip? Source.

RAG (Retrieval Augmented Generation)

RAG combines large language models (LLMs) with real-time information retrieval. It will dynamically fetch context from external sources like your database. You have to make sure your knowledge is up to date-and grounded (from specific documents and sources). Tells the LLM to only answer the users’ question from the given data. If the question cannot be reliably answered, the model should state that it cannot answer the question.

Step by step

1. Extract and Split data into Chunks. Tools: Langchain, CharacterTextSplitter

2. Create embeddings of each of the chunks (You can use OpenAI Embeddings Ada). Embeddings capture the meaning/semantics of the text

3. Store the embeddings in a vector DB (eg. Pinecone)

4. Retrieval

   1. User enters their query

   2. We run an embedding search to find the most similar embeddings to the query

   3. Ask the LLM to answer the users query based on the documents we found in step b

RAG Best Practices

Example at Persana.ai: they keep 10-20% overlap in chunks to capture context where it is in the document. They were scraping websites and using RAG and realized links were not working, and the reason why it was giving incorrect links was that links in websites don’t include the full URL. They might include part of the link, and the rest is in HTML so including that context in the chunk, making it slightly larger helped.

The accuracy takes a huge dip in the middle. While some models support longer token limits (e.g., GPT-4's 32k tokens), the effectiveness of retrieval for context-based accuracy and RAG can decline significantly beyond approximately 2000 tokens due to model attention limitations. To mitigate this, use effective chunking strategies and semantic search to select the most relevant chunks or consider splitting prompts to better handle larger contexts.

How to reduce hallucinations:

1. Make sure the data is verified and up to date. Retrieval of verified data ensures factual accuracy.Example:

   1. Query: "What are global temperature trends?"

   2. Without RAG: "Outdated Data”

   3. With RAG: "Global temperatures rise ~0.18°C per decade (source: IPCC)."

2. Metadata Filtering & Advanced RAG Techniques

   1. Reducing Noise: Use semantic similarity filters to focus on relevant data.

   2. Metadata Filtering: Leverage document tags to refine retrieval.

   3. Hybrid Search: Combine RAG with Keyword Based Search.

Keeping domain data up to date in RAG systems requires a combination of strategies to ensure accuracy and relevance. One effective method is to implement version control, maintaining multiple versions of datasets with metadata like version numbers or timestamps, allowing for systematic updates. Delta updates can also be employed to identify and modify only the affected chunks rather than rebuilding the entire vector database, saving time and resources. Automated data ingestion pipelines can streamline this process by fetching, preprocessing, and indexing new data as it becomes available, using tools for orchestration. Additionally, hybrid search techniques can combine vector search with metadata or keyword-based retrieval to prioritize more recent information when embeddings are slightly outdated. Modular storage of embeddings, separating static foundational knowledge from frequently updated dynamic data, further simplifies updates. For data that relies on third-party sources, effective tooling should be set up to auto-update indexes, ensuring timely integration of changes. Together, these strategies create a robust system for maintaining up-to-date and reliable domain data in RAG workflows.

Implement Agentic RAG

Agents are the new apps

Last year was all about copilots, and now it’s agents. All companies try to give users the ability to do tasks on their behalf all in one interface. Agents are different from RAG because they can access tools: API, database, new application etc. One of the main frameworks is the ReAct Agent.

Example from Persana’s 5m+ usage in last 90 days: Persana Quantum Agent.

Agentic RAG is RAG plus Agents, and an agent has access to both RAG sources and tools.

Instead of buying a subscription to each of the different tools, you can integrate your own or use the Persana marketplace and the DB. If you search for a phone number, it should go to the phone number source, not the website.

How to monitor RAG and agents

Create a test data set, and with every interaction, ensure your RAG pipeline platform answers them effectively. You can monitor RAG in production with tools like Okareo and Galileo. A free tool is the RAGAS Evaluation Metrics for RAG and Agents (Python package).

For agents, it’s not just the output but also how it does it. It has three parts: the router, the execution path, and the performance. Be really descriptive in your function description, write good prompts, and make sure you’ve given your agent all the tools that it needs to answer the question.

Comprehensive Agent Evaluation:

- Beyond just skills: evaluating the complete agent pipeline

- Key areas: Router, Execution Path, and Performance

- Critical for reliable agent systems

Tools: Arize AI, Galieo, Okareo.

One has to evaluate the agent also for bias and ethics as their neglect can lead to erosion of trust as well as legal and reputation risk. One needs a diverse and inclusive training data set. As well as regular audits for bias detection. One can incorporate fairness metrics too (e.g. demographic parity). AI systems are only as fair as the data they're trained on.

1. LLM Challenges: Hallucinations and bias undermine trust and reliability.

2. Mitigation Techniques: Effective prompting, RAG, and self-checking models reduce risks.

3. AI Agents: Autonomous agents are the future—when grounded and monitored properly.

4. Ethics First: Prioritize fairness, inclusivity, and transparency in AI design.

5. Continuous Evaluation: Regular monitoring & evaluations are essential for scalable, reliable AI systems.

Use tools

LangGraph is really good for multi-step. LlamIndex is great for building simple RAG, and Wordware for quickly building agents on a web IDE.

The RAGAS framework is helpful in estimating hallucinations. Having a human is still useful but if you don’t have it, ask another LLM as a judge as a really easy way. Before sending it to the user, we ask another LLM, have we answered the user's question? Have we said anything harmful?

Cost. Even bigger companies find it expensive to use GPT4 for evaluation, so they send it to a cheaper model for evaluation. Most of the people don’t use the best models to run the evaluations. Experiment and see which models work best for your use case.

Agentic RAG. LangSmith for tracing. Okareo and Arize are also good, but there are tons. Also Helicone to keep track of the LLM calls you’re making. A lot of observability tools are coming out.

I hope you learned something from this blog post. My parting thoughts are to give users visibility into where the data comes from and what steps the model took to give them the answer. So the customer can see if this quality data is what they want. Also, they can tune it to select only data sources from where the model gives them an answer. Trust is earned, and it’s built at every step of the agent development lifecycle.

If you have additions to this post and/or want to talk about LLMs and agents, please DM.

Thanks to ACM and Rush for reading drafts of this.