What are vertical AI agents?

Vertical AI agents are agents built to run one job inside one industry end to end, with that industry's workflow, permissioned data access, and accountability built in: a claims adjuster for a specialty insurer, a chart abstractor for a hospital, a lien search for a title company. They use the same frontier models a general agent uses. The difference is where the advantage is stored. A horizontal agent stores it in the harness, the prompts, tools, and orchestration around the model. A vertical agent stores it in the domain: the rules nobody wrote down, the integrations into systems of record, its own definition of a correct outcome, and a named party who is answerable when the agent is wrong. That distinction decides what a model release does to you.

What are the key differences between horizontal and vertical AI agents?

A horizontal agent optimizes for surface area, so the widest set of users can point it at the widest set of tasks, and its quality comes mostly from the model plus a general harness. Coding agents are the clearest example. A vertical agent optimizes for depth in one workflow: it is wired into the industry's systems of record, it runs inside a compliance regime, and it is graded by whether the filing was accepted or the claim was paid rather than by a general benchmark. The practical test is what happens on release day. When a better model ships, a horizontal agent can lose a share of the engineering that differentiated it, because the model absorbs the scaffolding. A vertical agent gains, because a better model makes assets the release never touched more useful.

Will foundation models make vertical AI agents obsolete?

No. Foundation models are absorbing the agent harness, not domain depth, so the layer at risk for a vertical AI agent company is the scaffolding it built rather than the vertical itself. Logan Kilpatrick of Google DeepMind argues that models are absorbing agent scaffolding and will run it natively, and puts a rough 12 month horizon on the current harness race. Boris Cherny, who created Claude Code at Anthropic, describes the same effect from the other side: scaffolding buys maybe 10 to 20 percent in a domain and then the gain is wiped out by the next model. Neither of those absorbs domain depth. Kilpatrick's own conclusion is that there is enormous value in verticalized domains, and that a big company cannot chase you into one because it has an obligation to do many things at once. The risk to a vertical agent company is building a general agent with an industry logo on it, not the model getting better.

How do you choose which vertical to build an AI agent for?

Choose the vertical by verifiability: pick the workflow where a correct outcome is checkable without a human debate. Kilpatrick's rule for where capability improves fastest is that domains with better verifiability see the gains first, which is why he names math, finance, and science. He separately expects capability to arrive unevenly rather than all at once. Verifiability is a property of the workflow and you can assess it before writing code: ask whether a correct outcome is checkable without a human debate. A tax return reconciles, a claim gets paid, a medical code survives the payer's edit. Those workflows let you build real evaluation sets, automate safely, and prove value with a number instead of a demo. Open ended judgment work fails all three tests, so pick the verifiable slice first even when it is the smaller one.

Vertical AI Agents: What the Model Can't Eat

A vertical AI agent is an agent built to do one job inside one industry, end to end, with that industry's rules, data, and accountability built in. A claims adjuster for a specialty insurer. A chart abstractor for a hospital revenue cycle team. A lien search for a title company. A horizontal agent is the general one: a coding agent, a research agent, a support agent that any company can point at anything.

The distinction matters right now for one reason, and it is not taxonomy. One of these two categories is about to have its technical differentiation absorbed by the models themselves. The other is not.

That is the argument Logan Kilpatrick, who leads Google AI Studio and the Gemini API at Google DeepMind, made on Sequoia's Training Data podcast in an episode titled Why the Model Eats the Harness. Sequoia's own summary of his position puts a clock on it: the ecosystem-wide race to build agent harnesses has "a roughly 12-month shelf life."

If you are building agents, that is a claim with your roadmap attached to it. Here is what it actually says, why the person who built Claude Code arrived at the same conclusion from the opposite side of the industry, and what is left to own once the scaffolding is gone.

What a vertical AI agent is

Strip the marketing and there are only two design choices underneath the label.

A horizontal agent optimizes for surface area. It is built so that the widest possible set of users can point it at the widest possible set of tasks. Its quality comes almost entirely from the model plus a general harness: tool calling, memory, retries, a loop. Coding agents are the canonical example, and the category enterprise buyers most often say is working, though as you will see that claim depends heavily on the bar.

A vertical agent optimizes for depth in one workflow. It knows that in this industry a claim under a certain dollar threshold routes differently, that this state's filing deadline moves when the first of the month is a Sunday, that this customer's ERP has a custom field the last integrator added in 2019 and nobody documented. It is wired into the systems of record, it runs inside the compliance regime, and somebody has decided who is responsible when it is wrong.

Both use the same frontier models. That is the point. The difference is not model access, it is what you built around the model and whether that thing has a shelf life.

The harness is not the moat

Kilpatrick's starting point is that what the industry still calls a model has quietly stopped being one. As he puts it, "what we have historically thought of as the model is not the model anymore." Two years ago a model was a set of weights: send tokens in, get tokens out. Now it arrives with tool calling, hosted search, code execution, containers, and an agent harness wrapped around it.

The pattern he describes is a ratchet. Scaffolding runs a few steps ahead of what is baked into the weights, and then the weights catch up: "the model eats that scaffolding and it becomes part of the native model system."

He names the agent harness as the current, most quintessential example, and this is the part with the deadline on it. "everyone's like, we got to go build a harness, and the harness is where the alpha is," he says, and then: "I think that perhaps won't be true, at least in the way that we think of the harness today, in 12 months." The models will have digested it, "the model just does it natively," and the alpha moves somewhere else.

The obvious objection is the one Sequoia's Sonya Huang put to him directly: application companies build their own harnesses precisely to avoid getting locked into one model provider. Kilpatrick's answer is that portability is a model capability, not a harness feature. "you don't have a generalized model if it can't use another harness," he says, and adds that the industry should be measuring exactly this: "we need something like harness bench, which is actually measuring how good are all these different models at adapting to all the different harnesses."

Hold this the right way. It is a forecast, not a finding, and a Google product lead predicting that harness work has a short shelf life is not a neutral observer. Google shipped its own agent harness, Antigravity, and Kilpatrick describes it in the same conversation as the through line that will power agent features across search, the Gemini app, Cloud, and AI Studio. He has a reason to want the harness layer to be commodity.

The person who built Claude Code says the same thing

Which is why the corroboration is worth more than the claim.

Boris Cherny, the creator and head of Claude Code at Anthropic, described the identical dynamic on Y Combinator's channel, from a company with every commercial incentive to tell you its harness is the moat:

"you can build scaffolding around the model in order to improve performance a little bit and depending on the domain you can improve performance maybe 10 20% something like that and then essentially the gain is wiped out with the next model."

His framing of the trade is that you can build the scaffolding and capture the gain now and rebuild it later, or you can wait for the next model and get it free. We used that same bet as a feature filter in our post on latent demand, which is built on the same interview.

That belief shaped a shipping decision, which is the part founders should notice. Claude Code stayed in the terminal, and the reason was not aesthetics: "there is no UI we could build that would still be relevant in 6 months because the model was improving so quickly."

Two labs, opposite sides of the competitive map, same conclusion. Engineering that exists to compensate for a model's current weakness has a depreciation schedule, and the schedule is measured in months. We wrote about the founder-side version of this in build for the next AI model, not this one. The harness argument is the same idea with a specific casualty named.

Horizontal vs vertical AI agents: the real difference

The usual answer is that horizontal agents serve many industries and vertical agents serve one. True and not useful.

The difference that decides whether you have a business is where your advantage is stored.

Dimension	Horizontal agent	Vertical AI agent
Advantage stored in	The harness: prompts, tools, orchestration, retries	The domain: workflow, permissioned data, definition of correct
What happens on the next model release	A share of your engineering is absorbed	The model gets better and your advantage gets more usable
Who you compete with	The incumbents' general tools, directly	Whoever else knows this industry, which is a much shorter list
Buyer's question	Is this better than the general tool	Does this survive my audit
How you win	Be ahead on capability	Be the only one who has done the unglamorous integration work

Kilpatrick's version of the second row is that models absorbing the scaffolding is not a threat to a domain-deep company, because domain depth was never the thing being absorbed. His version of the third row is that a company with Google's surface area structurally cannot come for you the way you fear: "we actually can't focus in one domain. we have an obligation to do a bunch of things as a big company."

What the model does not eat

His answer to where value goes after the harness is absorbed is, almost word for word, the case for vertical agents: "there's just so much value in these verticalized domains." The reason is ownership of context that was never in the training data. "if you have expertise in that domain you sort of know the customers, you know the ecosystem," he says, which is why a focused team "can really run laps around even the best model labs." His compressed version: "focus is the superpower of startups."

Four things specifically survive, and they are worth naming because they are also your build list.

1. The judgment nobody wrote down. Every industry runs on rules that exist only in the heads of the ten people who have done the job for a decade. Which exceptions are fine and which get you fined. When to escalate to a human and when escalating annoys the customer. A frontier model has read the regulations. It has not sat with your adjuster on a Tuesday.

2. Permissioned access to systems of record. Read and write access to the ERP, the EHR, the claims platform, the title plant. This is the least glamorous asset in AI and one of the most durable, because it is bought with security reviews, vendor onboarding, and integration work no model release makes unnecessary. Our post on the forward deployed engineer is about the role that actually does this work.

3. Your definition of correct. A general agent is graded by a general benchmark. A vertical agent is graded by whether the filing was accepted, the claim was paid, the code was reimbursed. Owning that evaluation set is the asset that compounds fastest, because every model upgrade is a free improvement you can measure and nobody else can. If you have not built one, LLM evals is the place to start.

4. Accountability. Somebody has to be answerable when the agent is wrong. In regulated verticals that is not a support policy, it is a contractual and sometimes statutory position. Labs sell capability. They do not sign up to be liable for your customer's audit finding.

None of the four gets cheaper when the model gets better. All four get more valuable, because a better model makes the surrounding asset more usable. That asymmetry is the whole thesis, and it is the same one behind vertical SaaS: when the cost of generic software collapses, what does not collapse is knowing exactly how one industry works.

Follow the verifiability

If you are choosing a vertical rather than defending one, Kilpatrick offers a selection rule worth taking literally. Asked which domains reach superhuman capability next, he goes to verifiability: "things that have better verifiability obviously are the ones where you'll see the gains happen more quickly." He names math, finance, and science. Earlier in the same conversation he had already predicted the arrival would be uneven: "it's almost like jagged super intelligence I think is what we'll end up with."

Verifiability is a property of your workflow, not of the model, and it is knowable before you write code. Ask whether a correct outcome is checkable without a human debate. A tax return reconciles or it does not. A claim gets paid or it gets denied. A medical code survives the payer's edit or it comes back. Compare that to judging whether a strategy memo was any good, where you cannot build a reliable eval, cannot safely automate, and cannot prove value to the buyer.

Pick the verifiable slice first even when it is the smaller one. It is where the model improves fastest, where your evals are cheapest to build, and where the sale is easiest to close, because you can show a number instead of a demo.

He is also honest about the current state of things outside coding, and it is a useful sentence to bring into your own planning: "it depends what your bar for working is." When enterprises say agents only work for coding, they often mean fully autonomous on complicated tasks. That bar is not the only bar, and it is not the one your first product has to clear.

The security work you are actually signing up for

Depth in a vertical is bought with access, and access is where the risk sits. This is the part of the vertical agent pitch that founders underprice, and the part your buyer's security team will find in week two.

An agent that can write to a system of record is an authenticated actor with standing permissions, driven by natural language, from an untrusted input surface. Treat it as one:

Scope credentials to the task, not to the agent. Separate read from write, and put the writes that carry consequences behind their own permission and their own log.
Assume the input is hostile. The document your agent ingests came from outside. In a vertical workflow, that is the norm rather than the edge case: claims come from claimants, invoices come from vendors, records come from other institutions.
Log for the auditor, not for yourself. In a regulated vertical, why did the agent do that is a question you will be asked formally. An answer you have to reconstruct from application logs is not an answer.
Decide the human checkpoint before you need it. Which actions never execute without a person, in writing, agreed with the customer.

Done properly, this is not overhead. It is the same set of artifacts your buyer's procurement process asks for, which means the security work and the sales work are the same work, and it is one more thing the model release does not do for you.

Is your vertical agent actually defensible

Three questions, answered honestly.

If your model provider shipped every feature in your harness natively tomorrow, what is left? If the answer is a thinner version of your product, you have a horizontal agent with a vertical logo on it. If the answer is the integrations, the data access, the evals, and the customer relationships, you are fine.

Can a competent generalist rebuild your product in a weekend with a frontier model? For the demo, usually yes. For the version that survives a real customer's data, an audit, and an exception at 2am, the answer tells you whether your depth is real.

What gets better for you when the next model ships? This is the one that separates the two categories. For a harness-differentiated company, a model release is a threat and a rewrite. For a domain-differentiated company, it is free capability applied to an asset the release did not touch. If you cannot name what improves for you on release day, you have not built the asset yet.

Kilpatrick's read on the overall picture is more optimistic than the labs-eat-everything narrative suggests: he says "there's never been more opportunity to go and build something," at the same moment the models are doing more than they ever have. Both are true. The models are absorbing a layer, and the layer they are absorbing is the one that was never going to be yours.

What to do this week

List your scaffolding and mark each item. For every piece of orchestration you maintain, write down whether it exists to compensate for a current model weakness, or because your domain requires it. The first list is your depreciation schedule. Put a date on revisiting it.
Pick the verifiable slice. Find the one workflow in your vertical where correct is checkable without a human argument, and make that your wedge, even if it is smaller than the one you wanted.
Build 50 real evals from customer outcomes. Not benchmark tasks. Real cases with known correct answers from your own customers. This is the asset that turns every future model release into free progress you can prove.
Write down three rules that are not in any manual. Get them from the person in your customer's org who has done the job longest. If you cannot produce three, you do not yet have domain depth, you have a domain interest.
Draft the access and audit story before the security review. Credential scope, write permissions, human checkpoints, and the log an auditor would accept. You are going to be asked. Answering from a document is cheaper than answering from memory in the meeting.
Run the release-day test. Name exactly what improves in your product the next time your provider ships a better model. If nothing does, that is the roadmap gap.

If you want the full picture of how these decisions fit together, from product to pricing to team, that is what the AI Operating System for Startups course is built to give you. The broader map of the shift sits in our pillar on AI for startups, and the strategy-level version of this argument is in where a competitive moat comes from in AI.

Sources

Google DeepMind's Logan Kilpatrick: Why the Model Eats the Harness on Sequoia's Training Data, hosted by Sonya Huang, the interview this article distills. Watch the full episode on YouTube.
Inside Claude Code With Its Creator Boris Cherny on Y Combinator's channel, for the scaffolding depreciation argument and the bitter lesson framing.
Background on Logan Kilpatrick: Wikipedia and his author page at Google. Background on Boris Cherny: Wikipedia and Anthropic, which lists him as head of Claude Code.
Rich Sutton's The Bitter Lesson, the essay behind Anthropic's never bet against the model principle.