CampeloLabs

Guide

AI for startups: the founder's guide

Cicero Campelo

Cicero Campelo, CISSP
Updated August 2026 · 13 min read

A founder building a startup at the dawn of the AI cognitive revolution
Table of contents

The biggest opportunity in software is no longer software. At Sequoia's AI Ascent 2026, the firm's partners opened with a reframe every founder should sit with: AI is not another revolution in how information is distributed, the way the internet, cloud, and mobile were. It is a revolution in how information is processed. "AI is a revolution in computation," as Pat Grady put it. That changes the shape of the wave, and for a founder it changes what AI for startups even means.

This guide turns that shift into six operating decisions: what product to build, how to engineer it, where agents belong, how to take it to market, how to price it, and what kind of team can run it. It draws on the Sequoia keynote and the people building the frontier, then links each decision to a practical article, founder playbook, or book review on this site.

Why AI changes startup economics

By a test founders can act on, AGI has functionally arrived: if you can dispatch an agent to do a job and it can recover from failure and persist until the job is done, that feels like AGI. The Sequoia partners are careful not to propose a technical definition. Commercially, their point is that the useful threshold has already been crossed. The last few years gave us applications that made a person 10 to 40 percent more productive. Agents can make a workflow 10 to 40 times more productive and change who, or what, performs the work.

The prize is bigger than software has ever been because this wave is both software and services. Legal services in the US alone is a 400 billion dollar market, roughly the size of all software, and that is one vertical in one country. When intelligence can complete the work rather than only help a person use a tool, the addressable market expands from software budgets into labor and service budgets.

The technology foundation also moves every day. Sequoia's phrase is "no lead is safe." Models improve faster than most companies can absorb them, so the gap between available capability and real adoption gets wider. That diffusion gap is where an application startup can win, provided it wraps the capability around a specific customer instead of treating access to a model as the product.

The cognitive shift is real, but founders should treat it as engineering and economics, not mystery. Nvidia's Jensen Huang describes AI as computer and software that can be understood and improved. The practical question is not whether intelligence becomes abundant. It is where abundant intelligence changes the unit economics of a customer job enough to support a new company.

Product: choose the job, not the model

The first product decision is not which model to use. It is which customer job becomes materially better when intelligence gets cheap. The most reliable way to find that job is to look for latent demand: something people already do by hand, at a cost they absorb quietly, that no product has taken over yet. Start with a painful workflow where speed, judgment, or timing changes the outcome. AI prototyping should help you answer that question, not turn an untested idea into production software faster. OpenAI co-founder Greg Brockman's founder playbook makes the constraint explicit: building is cheap, but the founder's attention and judgment are not.

Give the first prototype one question to answer, get it in front of the workflow, and discard the code if the evidence says the idea is wrong. Use AI to synthesize evidence and draft the specification, but keep the judgment about what is worth building.

The strongest AI products also create an advantage the base model cannot supply. They capture workflow data, learn from real outcomes, and become more useful inside one specific customer context. That is how a startup can turn proprietary data into a durable AI advantage. It also fits Zero to One's advice to dominate a small market first: own a narrow job deeply enough that direct competition matters less.

Timing matters as much as the idea. Demis Hassabis's founder playbook frames the useful window as being years ahead, not decades ahead, and pairs AI with another deep discipline to create defensibility. A capability that cannot become reliable and affordable inside your runway is a research direction, not yet a startup product. The clearest current test of that judgment is physical AI, where the model layer has become buyable while the data and deployment economics still decide which vertical is a company this year and which is a research bet.

The next interface is not necessarily another chat box. Products become more valuable when they recognize the right moment to help, prepare a bounded action, and keep the user in control. The practical design rules are in the guide to building proactive AI products people can trust. Amjad Masad's founder playbook shows the adjacent opportunity: a real interface shift can bring creators into the market whom incumbent tools never served well.

Engineering: build a system that survives model churn

Treat the model as a replaceable dependency. The durable system is the layer around it: your data, context, tools, permissions, observability, and feedback loops. A startup should build for the next AI model, because every meaningful model release should make the product stronger instead of forcing a rewrite.

Keep the model behind a thin seam and choose it by task, not by leaderboard. The best LLM for a founder is the one that meets the quality, latency, cost, and privacy requirements of that workflow. If swapping it requires a quarter of refactoring, the product is coupled to a vendor advantage it does not control.

Agents fail when they receive the wrong information as often as they fail because the model is weak. Capture how good work actually happens, route agents through a shared source of truth, and build a context layer instead of isolated prompts. Context should reflect real tickets, calls, documents, and decisions, not an idealized description of how the company wishes it worked. Context that started out right also decays as a session runs long, so teams should know how to spot context rot and when to reset rather than push a degraded session further.

Quality also needs a definition that can be tested. Before changing a prompt or swapping a model, founders should define and run LLM evals against real customer cases. Francois Chollet's founder playbook is a useful companion because his operating advantage was not only model design. It was usability, an open ecosystem, and owning the measuring stick. Evals turn model churn from a risk into an engineering advantage only when the metric represents what customers call good.

The new build loop is agentic engineering: a human writes the specification, agents implement, tests and reviewers check the work, and a human owns the release. That preserves the professional quality bar while building gets faster. The safety version is the same discipline. Scope access, keep secrets out of prompts, label and log actions, and keep a person on every irreversible call. Safety should become the condition that permits speed rather than a review added at the end.

Agents: earn autonomy one workflow at a time

An agent is more than a model call. It needs a goal, context, tools, memory, and a harness that can recover from failure. Start with one bounded workflow and a result a person can inspect. Then learn how to orchestrate a fleet of agents without making review the new bottleneck.

Memory is part of that operating layer. An agent needs to know what happened, what the customer prefers, and which past result matters now. Decide what to store, what to retrieve, and where privacy becomes a product constraint. Memory should make the next action more accurate, not quietly become an unlimited record that nobody can govern.

At company level, agents should share infrastructure instead of becoming a pile of disconnected bots. A common context store and tool registry form the internal AI infrastructure a startup can reuse across workflows. That plumbing is what lets an AI-native company run as a closed loop, with artifacts from the work becoming context for the next run. Where the agent runs is its own decision, and a self-hosted AI agent inherits the whole machine, which is the capability argument and the security argument at once.

Roles and review make the system reliable. Garry Tan's founder playbook treats agents like a team with a plan, specialist roles, review, and a ship gate. The point is not to launch more agents. It is to give each one a clear job and make the handoff observable.

Autonomy should rise only after trust in that exact workflow rises. Voice makes the boundary easy to see because a mistake reaches a customer immediately. Mati Staniszewski's founder playbook combines an overlooked interface bet with a human quality bar. Start agents at suggest or draft, move to approval, and allow automatic action only inside limits the user understands.

Go-to-market: narrow the customer before you scale

The diffusion gap is the startup opportunity, but a broad market is not a strategy. Start by defining the ideal customer profile you are willing to serve deeply, then wrap the product around that customer's workflow. The moat is not access to intelligence. It is how much better you understand and serve one group whose behavior changes slowly while models change quickly.

Two founder playbooks reinforce that discipline from different angles. Paul Graham's playbook starts with making something people want and doing the manual work that reveals the real problem. Michael Seibel's playbook turns it into a feedback loop: solve one specific problem for one specific customer, launch, talk to users, and follow the pull. Those habits keep cheap building from producing a wide product nobody needs.

Distribution is still half the company. Traction's Bullseye Framework gives founders a way to test channels cheaply before concentrating resources on the one that works. Once the channel is visible, choose a top-down or bottom-up sales motion based on who feels the pain and who controls the budget. That choice shapes pricing, onboarding, hiring, and the roadmap whether you make it deliberately or not.

Narrowing the customer eventually becomes a decision about the business model itself. Vertical SaaS, where you own one industry's workflow rather than one function across every industry, is the shape that benefits most from cheap intelligence, because the domain depth and the permitted data access are exactly what a model provider will not supply to your competitors. Some of the largest AI opportunities go further and look more like services than traditional SaaS. In a service-as-software company, the customer buys the completed outcome while software and agents run most of the operation behind it. The winning founder combines domain fluency, model fluency, and operational rigor, then prices the outcome against the labor or delay it replaces. Selling into large enterprises adds a cost most plans miss, because someone has to make the product work inside each customer: budget the forward deployed engineer before you promise the logo.

Incumbents often leave the opening themselves. Aravind Srinivas's founder playbook is built around shipping what the incumbent refuses to build because it would threaten the current business. The Innovator's Dilemma explains why that delay can be rational: the new segment starts too small or unattractive for the incumbent's economics. For a startup, that rejected beachhead can be exactly the right place to begin.

For live examples, study YC startups using AI across sales, customer support, coding, and other functions. Do not copy the feature list. Look for the narrow customer, the job being completed, the distribution path, and the reason an incumbent did not already own it.

Pricing: charge for value and protect the margin

AI weakens the default per-seat model because usage costs move with every inference while the product may remove the need for seats. The right structure depends on what the customer can measure: usage, completed work, business outcome, or a hybrid of those units. The guide to pricing an AI product compares the main models and the margin risk behind each one.

Track the economics at workflow level. Measure inference cost, human intervention, completion rate, and the value of the result. A product can grow revenue while hiding a workflow that loses money every time a heavy customer uses it. Outcome pricing captures more of the value, but it works only when the outcome is attributable and both sides trust the measurement.

Pricing and operating design are connected. If agents let a small team serve more customers without matching headcount growth, revenue per employee becomes a useful test of whether the leverage is real. Henrique Dubugras's founder playbook adds the leadership condition: the CEO has to own the AI rebuild and the accountability that comes with it, not delegate a company redesign as a tool rollout.

Capital strategy should match the growth mechanism. Venture Deals explains the economics and control inside a term sheet, while Blitzscaling supplies the go or no-go test for sacrificing efficiency in the name of speed. Raise and spend aggressively only when a real first-scaler advantage rewards it. Cheap building is not, by itself, evidence that the market requires expensive growth.

Career and team: move from execution to judgment

AI compresses execution, but it increases the value of deciding what should be built, writing a specification precise enough for an agent to build against, reviewing the result, and owning the consequence. The future of software engineering points toward smaller teams of people who can move from customer problem to architecture to verification without handing the work across layers.

That does not mean technical work disappears. The useful question is whether AI replaces software engineers or changes the job they perform. Routine implementation gets cheaper while judgment, systems thinking, security, and taste become more important. The title may change. The responsibility for knowing whether the system is right does not.

For founders, the same leverage changes company formation. One experienced operator can now build like a team as a solo founder, provided they remain responsible for the market choice, specification, and final review. A model multiplies an existing edge. It does not create customer insight or taste for someone who has neither.

Small teams still need operating discipline. Ben Horowitz's founder playbook is a reminder that category leadership, concentrated conviction, and clear accountability matter more as the company grows. The toolset changes faster than the human work of telling the truth, making the hard call, and giving one person ownership of an outcome.

Mark Pincus describes founder mode as a weekly habit in Life at the Speed of Play: stay close enough to the product and the market to feel when the conditions change. AI can do more of the work, but only a person can decide which result matters and why anyone should care. Adaptability, judgment, and human connection are not the leftovers after automation. They are the part that points the company.

What to do this week

  1. Pick one customer job where AI changes the result 10 times, not 10 percent, and prototype only the riskiest assumption.
  2. Put the model behind a thin seam, capture the context the workflow really uses, and define one eval before the next model change.
  3. Give one agent a bounded job with a visible result, minimum access, an audit log, and human approval for every irreversible action.
  4. Name one narrow ICP, one distribution channel to test, and whether the first motion is top-down or bottom-up.
  5. Price one workflow against the value it delivers, then measure model cost and human intervention on that workflow.
  6. Decide what only you should do this week. Hand the mechanical work to agents and keep the specification, judgment, and review.

The cars have arrived, and no lead is safe. That cuts both ways: the incumbents' leads are not safe either. What a time to build.

If you want this as a system rather than a stack of talks, that is what we teach in the AI Operating System for Startups.

Sources

Frequently asked questions

What does AI for startups actually mean?

It means building your company for a revolution in computation, not just adding AI features. At Sequoia's AI Ascent, the partners framed AI as different from the internet, cloud, and mobile: those changed how information is distributed, while AI changes how it is processed. For founders the practical test of where we are is simple, in their words: if you can dispatch an agent to do a job and it recovers from failure and persists until the job is done, that already feels like AGI. So AI for startups means designing the product, the team, and the workflows around agents that do real work, not bolting a chatbot onto an old process.

What is the biggest AI opportunity for founders right now?

Services. Sequoia's partners call it the first wave that is both software and services, and Sonya Huang's line is that services is the new software. Some of the biggest companies of the next decade will not be software businesses at all; they will be law firms, insurance carriers, and accounting practices rebuilt from scratch with AI doing most of the work. Legal services in the US alone is a 400 billion dollar market, the same size as all of software. The opening is the diffusion gap: capabilities are being created far faster than the average enterprise adopts them, and that gap is where application founders win.

How do startups build a moat in AI?

By wrapping around the customer, not the capability. Sequoia's MAD framework (moats, affordance, diffusion) starts from a counterintuitive point: in a revolution of computation the technology you build on changes daily, but your customers change slowly, so the durable advantage is how tightly you wrap yourself around them. a16z's Benedict Evans makes the same point about where value accrues: not in the foundation models themselves, but further up the stack in the applications built around real customer problems. The moat is whether you deliver compounding advantages to a specific customer.

How should a startup adopt AI safely?

Aggressively, but with guardrails first: scope what agents can access, keep secrets out of prompts, log what they do, and keep a human approving anything irreversible. The mindset from operators like Brex's Pedro Franceschi is to focus on what only you can do and hand the rest to agents, and Nvidia's Jensen Huang puts it as you will not lose your job to an AI, but to someone who uses AI. The reason guardrails come first is that the same autonomy that makes agents powerful makes them a new attack surface, including autonomous AI-powered attackers.

Do AI-native startups still need people?

Yes, but the work changes. The durable human trait is adaptability, and as the Sequoia keynote closed, AI can do the work but only the human connection gives a reason to care. YC's framing is that AI changes the unit of production to humans in concert with agents, with memory, evals, and a customer loop. Teams get smaller and a handful of people ship what used to take hundreds, but a founder still owns the vision, the taste, and the calls that matter.

Build your AI Operating System

A practical course to grow with AI, build internal tools, and operate safely. v1.0 launches August 31, join the waitlist.