A person doing a job is going to end up with one thing they open every morning. Not fewer apps. One. Most of the market has gotten comfortable with that idea, which is why 75% of employee-facing application software companies are going to disappear and half the categories will go with them.
What nobody has priced is what it does to everyone else. If there’s exactly one seat at that table, every other company in this cycle has to find another way to get paid.
I’ve been pushing this on founders for six months without having a name for it. The analogy finally hit me this week, so here I am, publishing to name an anxiety that has been sitting in the room the whole time.
Take any function or vertical where humans are still doing the work, and where those humans have sensibly decided not to go vibe-code the whole thing themselves at 11pm on a Tuesday. There are three ways to make money.
You are the Horse, or
you are the Harness, or
you are the Hay.
The Horse is the LLM model: enormously powerful, fundamentally unpredictable, not something you command so much as ride.
The Harness is the application layer fitted to that animal for one rider and the entire job that rider does, holding the ontology, the interaction model, and the learning loop.
The Hay is everything the horse and harness need to stay healthy at scale: orchestration, governance, cost routing, security, observability, data infrastructure.
Almost nobody picks the wrong one. A hay company doesn’t wake up wondering whether it’s Harvey. What happens instead is that founders pick the right category and either run the wrong playbook or, worse, run the other one’s playbook: the harness maker who expands cautiously, module by module, waiting for pull, and the hay company that goes broad early and sells transformation to executives. The categories are obvious. The strategies are close to inverted, and that’s what gets people killed.
The horse is the LLM model. Enormously powerful, getting faster, unpredictable in the way anything with that much power is unpredictable. You do not command a horse. You ride it. And the difference between someone who can ride and someone who cannot isn’t strength. It’s a thousand small corrections a second that neither party can fully articulate.
Almost none of you are the horse. Four or five companies on the planet are, and if you’re asking whether you should become one, you are not one.
The more interesting question is whether the horse becomes the harness. Whether the model makers, having built the most valuable technology of our technology careers, simply walk up the stack and take the application layer too. I get some version of that every time a model provider ships something adjacent to a founder’s product.
My answer is no.
Not for lack of talent, capital, or ambition, which they have in embarrassing quantity. It’s a no for three structural reasons.
First, no smart harness maker will wed themselves to one model provider. Every good CTO I talk to has already abstracted the model away from the product. Not out of loyalty. Out of survival: which model is best changes every 60 to 90 days, and prices move by an order of magnitude.
Portability is also a margin discipline, and it’s most of the difference between the companies quietly running healthy gross margins and the ones complaining in public about COGS. A large share of what runs in production never touches a frontier model: classification, extraction, routing, summarization, retrieval. Reserve the frontier for the hard, ambiguous, high-stakes judgment and send everything else to a pony. Run every call to the biggest model because it’s easier and your gross margin belongs to somebody else’s price list.
Push that far enough and some of the larger harness providers have started training narrow models for the slices the labs will never optimize. That isn’t becoming the horse; nobody is breeding a racehorse, they’re buying a pony for the short hauls. I’m not yet wedded to it, since the labs keep eating specialized capability on a schedule nobody controls. But do it because the unit economics of a step demand it, never because owning a model feels like a moat. The moat is still the harness.
Second, the specialization required to win a harness market is not a game the horse wants to play. Learning the eleven ways a personal injury firm handles a lien is the easy half. The hard half is sitting with paralegals and adjusters and shop owners until you know what they’ll tolerate, what they’ll quietly work around, and what makes them trust the thing enough to hand it the next job. None of it generalizes. Meanwhile the providers are selling tokens hand over fist at a scale that makes vertical software revenue look like a rounding error. When you’re printing money on the substrate, the will to grind out the ontology of the fire-and-water restoration industry does not materialize. It just doesn’t.
Third, and this settles it: no serious organization will, over time, hand its embedded intelligence back to the model provider. The loop, the corrections, the accumulated judgment about how this company works is its differentiated DNA. Handing it to a platform that also serves its competitors isn’t a procurement decision, it’s an act of self-harm.
One boundary, and it cuts the other way: all three hold where the ontology is thick. Where it’s thin, the horse is already the harness. Nobody is building a vertical harness for the person who writes internal memos, and the general assistant wins those by default. So before anything else: if a frontier model with a decent prompt gets most of the way to your rider’s job, you’re not early to a market, you’re competing with the default, and the default is free, already installed, and improving on somebody else’s roadmap. The thin end is being eaten from above by the assistants and from below by the vibe-coding tools. You can vibe-code an interface and a workflow; you cannot vibe-code a loop or an ontology. What survives in the middle is thick ontology, real judgment, and enough market to pay for the grind.
So the horse gets more powerful, faster than any of us expect, forever. And the horse stays the horse.
“AI application” has become a phrase that means nothing. A harness does four things, and if you’re missing one you don’t have a harness, you have a demo.
It carries the ontology. People hear that word and think schema. Schema is boxes, and anyone can copy your boxes off a competitor’s API docs in an afternoon. The ontology is what the boxes mean to each other. In a personal injury matter the record isn’t a row; it’s a scanned police report, medical charts, a recorded call with an adjuster, and a spreadsheet some paralegal keeps privately. The ontology knows those are one matter, that the photo contradicts the report, and that these facts settle for one number in Texas and another in Florida. It’s the meaning running between the assets, most of it multimodal, almost none of it in a shape a database was designed to hold. Schema can be copied. Meaning has to be earned.
It owns the interaction model for that role. Not a chat box, and not necessarily a UI at all. What the rider is asked, what they approve, what they never have to look at again, what escalates and how. Which doesn’t require pixels: upmarket this increasingly gets consumed headless, rendered inside Claude or something the customer built on Vercel. Serve that, but treat headless demand as a scoreboard rather than an architecture, because yours is the surface holding the ontology and the loop and the memory of this rider, so its ceiling should be higher than a general assistant’s at your rider’s own job. The test is what survives a change of surface. Swap the front end next year: if everything they taught the system is still there, you were the harness. If not, you were endpoints with good docs.
It owns the eval and RL platform. The dividing line is whether a graded outcome changes future behavior without an engineer deciding what to change. Everybody has dashboards, and a human reading one and then writing code is a feedback process, not a loop. The test: can you point at a behavior your product has today that nobody on your team designed?
And it is singular. One rider, one harness. Nobody runs three of these at once any more than they drive to work in two cars. Not “fewer apps,” but one, per rider, per job.
Put those together and what you’re building isn’t a suite of features, and it isn’t a collection of agents either. It’s one master agent for that rider, with skills it can call, memory of that person and that company, the ontology underneath, and the loop wrapped around all of it. Ship an agent per job and you’ve rebuilt app sprawl inside your own product. Done right, this is the smartest thought partner that person has ever had: it has read everything in their world, remembers every decision they’ve made, never gets bored by the tedious part, and is there at 6pm on a Friday. That’s what earns the context handover, and nothing less does. Nobody has solved the interface for it yet, either. Pure chat loses the artifacts, pure app loses the agent, and whoever gets that split right for a given role first will be very hard to catch.
Cursor is a harness. Harvey is a harness. Legora is a harness. Many of our investments are harnesses: Supio, Top Line Pro, Ranger, Sante, TireTutor. Here’s the consequence founders keep trying to negotiate their way out of:
There is no partial harness.
Build one job-to-be-done for a role, or three, standing next to someone building all fifteen, and you’re not a smaller competitor. You’re a feature they’ll ship in a sprint once their customers ask.
Most founders haven’t sat with what that means, because they hear “all the jobs” and picture a bigger feature list. Take Sante’s rider, the owner of a liquor store. The job is ordering and replenishment, vendor rebates, pricing by SKU against the store down the street, shrink, scheduling, payroll, the liquor license and age verification and state excise filings, shelf layout, loyalty, the delivery marketplaces, the point of sale, payments, cash, the monthly close, insurance, working capital, hiring, and the customer who is unhappy about something at 6pm on a Friday. That is not a roadmap. That is a person’s entire life. All-in-one means that in the end, they open you and nothing else.
Two things follow that founders get wrong. It doesn’t mean you build every piece yourself; nobody cares that your payments are Stripe underneath, they care that they never leave. And it doesn’t mean building in order of market size, which is the instinct that produces a shallow suite.
There’s a clean test. Draw your rider’s week, hour by hour, and mark the hours you own. If your roadmap is organized by feature category rather than by that week, you’re building a product and somebody else is building the harness. The boundary differs by type, too: for a functional role it’s the job, and for a business type it’s the P&L, which lands you at business-in-a-box, the top of the staircase.
Yes, you have to be a bit bat-shit crazy to believe you can pull this off. That’s the entry fee. But the hard part isn’t the ambition, it’s the refusals: turning down the adjacent enterprise logo that pulls you off your rider, declining horizontal expansion that looks like free TAM, spending two years on unglamorous jobs nobody will write up. The chutzpah isn’t in the vision slide. It’s in a long sequence of saying no to revenue.
And founders hear “do everything” and go build a shallow suite, which is the fastest way to die here. So: the ambition has to be total on day one. The scope absolutely cannot be.
You win by doing one job so preposterously well that the rider decides, on their own, to give you access to everything: their systems, their documents, their history, their exceptions, the ugly spreadsheet the whole department actually runs on. That handover is the real conversion event, not the contract. The contract just gets you in the barn.
Which turns the hardest question in this business into a sequencing question: what do you build next, and how fast can you ship it? Four rules.
• Build the job that widens the context, not the invoice, because context compounds and revenue doesn’t.
• Build adjacent in time rather than adjacent in category, because the handoff friction lives next door and your context gives you a start nobody else has.
• Prefer jobs you can grade, because an ungraded job just adds surface area to maintain.
• And the tiebreaker: does owning the next job make the last job better? If it feeds back, it’s the next rung. If not, it’s a feature, and features are how a harness turns into a suite without anyone noticing.
The good news is you don’t have to guess. The customers tell you, out loud, usually within 60 days, and this is the part I didn’t anticipate two years ago. The harness gets access to some adjacent system the customer already pays for, and within 30 to 60 days of users seeing their data inside the harness, somebody asks the question. “Why don’t you just build that?”
Not “can you integrate with that.” Build that.
These are systems representing billions of dollars of established SaaS TAM, and the customer is volunteering to hand it over, because that data inside a working harness makes the old application feel like a car with stone wheels. The harness maker didn’t displace the incumbent. The user did it for them, unprompted, in month two.
That’s the prize, and it’s available only to companies playing for all of it. There are no halfsies in the harness. Which is why you aren’t selling a tool to a department, you’re capturing the imagination of the exec who owns the function and getting them to the promised land fast, because the window between “I believe you” and “someone else showed me the same thing” is measured in weeks.
If you’re not the horse and you’re not the harness, you had better be the hay. This is generally the least understood opportunity in this cycle.
A horse that isn’t fed properly doesn’t run. Hay is everything the horse and harness need to operate at scale, safely, affordably, and legally, roughly following the path of the work:
• Ingestion and extraction: the police report, the chart, and the recorded call becoming something a system can reason over. Reducto, Unstructured, LlamaParse. No ontology exists until this works.
• The substrate: where the bytes live. Databricks, Snowflake, ClickHouse, Supabase, Neon, MotherDuck.
• Memory and context: what an agent knows across sessions, and what gets retrieved. The most underbuilt layer in the stack.
• Serving and routing: the right horse at the right price. OpenRouter, Fireworks, Baseten, Together, Modal.
• Execution and access: sandboxes for agent-written code (E2B, Daytona, Modal), and machine-speed access to a web that doesn’t want to be read by machines (Browserbase, Firecrawl, Exa).
• Evals and observability: Langfuse, LangSmith, Braintrust, Arize. Hold that thought.
• Graded data operations: somebody has to produce the corrections your loop runs on. Surge, Mercor, the human-in-the-loop layer under every eval.
• Guardrails and runtime safety: prompt injection defense, action-level policy, the thing that stops an agent wiring money. None of it existed before agents.
• Identity, authorization, settlement, and audit: the least built-out and the most inevitable.
The existence proof sits one cycle back: Datadog, MongoDB, Confluent, Cloudflare, Twilio, Stripe. Hay is not a consolation prize. But it is a completely different game, and founders who drift into it running a harness playbook get killed. The harness sells a transformation to an executive. The hay sells a primitive to a builder. Everything downstream of that changes.
1. Your buyer is a builder, and you win by being assumed. Nobody sits through your deck. The evaluation is whether an engineer gets to a working thing in fifteen minutes, alone, at night, without talking to you. Then win the reference architecture rather than the bake-off: the starter template, the framework integration, the model provider’s docs, the diagram somebody screenshots and posts. When a harness team stands up its stack in week one, the goal is that you’re already in it and nobody remembered to evaluate you.
And assume the evaluator stops being human. Increasingly an agent picks its own tools at runtime, on measured latency, success rate, and cost, which is brutally meritocratic: wonderful if you’re the best, fatal if you’re merely the best marketed. It also commoditizes anything where an agent can measure equivalence, because if two stores return the same results it takes the cheaper one, every time, forever. Which is rule 3 arriving from a different direction: you want to be somewhere an agent can’t measure you as interchangeable.
2. Sell the instrument that produces judgment. Never sell the judgment. The rule I see violated most. Own the trace store, the eval runner, the diffing, the whole apparatus that shows a customer where their system is failing and what’s decaying. You cannot own the answer. The definition of correct is the customer’s, permanently, and the moment your product holds an opinion about it you’ve become the thing they take back in-house. Langfuse tells an engineering team where the agent broke. It doesn’t tell them what good looks like.
3. Pool something no single customer can pool. The hay version of the compounding loop, and the gate I’d apply hardest. Serving 400 customers has to make your product better than serving 4: cross-provider price and latency, failure signatures across thousands of deployments, attack patterns, regulatory precedent. If you can’t articulate what you pool, you’re a component, and components get absorbed, from below by the platform you sit on and from above by the harness maker who decides it’s core. Watch the standalone vector database, a useful primitive that pooled nothing and has largely collapsed back into Postgres. One layer up, Snowflake is buying Observe for roughly a billion. Same rule, opposite directions.
4. Your customer is never a rider. It’s always somebody building a harness, and there are two populations. Commercial harness makers are few, sophisticated, and entirely capable of building you. Worse, they’ll abstract you on the day they adopt you, for the same reason they abstract the model underneath, because their whole job is hiding this complexity from their rider. Internal builders are the mirror image: they can’t afford the engineering to abstract, so they wire straight into you and stay. Smaller, slower, far stickier per dollar, and there are thousands of them.
Win only the first and your revenue can evaporate on somebody’s architecture review. Win only the second and you have a durable base with a slow curve, which most founders underweight badly. And notice what neither population is: an end user. The rider never sees the hay, which is why builder-to-builder distribution isn’t a preference here, it’s the only channel that exists.
5. Price the agent, not the seat, and land while the stack is molten. Your unit of value has to grow with autonomy: tokens, traces, runs, evaluated interactions. Price per seat and every successful customer makes your revenue smaller. And land now, because in eighteen to thirty-six months the harness winners will have scaled, their stacks will have ossified, and the switching decisions stop getting made. Enter on pain, usually a cost shock or an outage or an audit. Stay on governance, which is what makes you impossible to cancel later.
6. Second place is a real company here, for a while, and then gravity decides. In the harness market, being #2 is a slow-motion obituary. In hay it’s different, because builders deliberately multi-source, and #2 and #3 can build large, durable businesses. But that protection has a shelf life. The same fatigue that collapses eight applications into one harness eventually collapses twenty-seven infrastructure vendors into a platform, because nobody wants to buy their hay in twenty-seven bales. It just runs on a slower clock, driven by procurement and security review rather than by the rider’s cognition.
And it happens by acquisition far more than displacement. Nobody rips out ClickHouse because a platform shipped something adjacent; they get one invoice because the platform bought the company. Which produces the asymmetry that is the real argument for this category: the downside case in hay is a sale. The downside case in a partial harness is a zero, with the exception of a strategic buyer picking you up to increase their AI mojo.
If you’d rather be the acquirer, know what that takes. Databricks consolidated from the data, because once the customer’s bytes live with you, everything touching those bytes is cheaper for you to add than for anyone to sell. Datadog from the agent on the box. Stripe from the money. So the question is whether you sit on something with gravity, and I count four candidates: the data, the traces, the token path, and the runtime where agent code executes. If you’re not on one of those, you’re one of the twenty-seven, and the way founders waste the long clock is panicking early and bolting on modules, which leaves you mediocre at six things exactly when the bundle arrives. Databricks earned the right to consolidate by being undeniable at Spark first.
Which gives the two strategies their symmetry:
The harness has to be everything on day one, in ambition if not in scope. The hay has to be undeniable at one thing first, and only then gets to decide whether to become everything.
Agent infrastructure is the most consensus-heavy area in AI, the valuations reflect it, and much of what gets pitched as a new primitive is an old primitive with “for agents” appended. The bar is whether the technical problem didn’t exist before agents. Agent-to-agent settlement, machine-speed authorization, evaluating non-deterministic systems at scale: those are new. A queue is not new.
There’s a sharper version of that bar, too, because the labs are already shipping memory, retrieval, sandboxes, and eval tooling into the platform. Would a model provider building this make them tokens or cost them tokens? Anything that gets the median developer working faster increases inference, so they’ll ship a free version and thank you for the roadmap. Anything that reduces inference, makes the customer portable, or makes somebody accountable outside the relationship, they’ll never build well. Which is why everything cross-provider is structurally safe, and why competing on ease of getting started is competing for the one thing the horse will always take.
Everything above assumes you’re selling to riders or to the people who serve them. But there’s a buyer who fits neither, and I think it’s the most underrated customer in this cycle: the company that decided to build its own harness, which is the return of the custom build.
Not rare and not going away. For every function with a great vertical winner, there are three without one, or where the data can never leave the building, or where the company believes its particular way of doing the job is the differentiator. Add the much larger population who haven’t decided anything at all, holding four tools they’re not sure they’ll renew, quietly wiring things together, discovering as they go that they’ve become software builders by accident, learning words like mono repo and shared governance along the way.
Call them the self-assemblers. They buy hay. They also buy something that isn’t hay, and here I’d rather admit the analogy strains than force it, because horses eat and harnesses don’t.
Harness parts are not hay. Hay feeds the horse regardless of who built the harness. Harness parts are pieces of the harness itself, sold to somebody fitting their own: the ontology and context layer, the memory architecture, the instrumentation that closes the loop, the orchestration spine. A saddler sells you a finished harness. A tack shop sells you the pieces and you do the fitting.
And the hardest piece to buy is the fit. Anyone can wire an agent to send an email. What kills the self-assembler is that the agent doesn’t know who they sell to, why they win, or what good sounds like in their voice, because that knowledge is spread across a positioning doc from two years ago, a handful of call recordings, and a page nobody has touched since the last reorg. Every tool they’ve stitched together holds a different fragment, and none of them agree.
So the most valuable harness part is the one that carries that knowledge and keeps it honest. Not a document store. Something that encodes the company’s truth in a form every downstream system can read, then surfaces what’s landing and what’s rotting so the team can decide what to change. It holds no opinion about the customer’s market; it holds the instrument that lets the customer form one. It’s the compounding loop sold to functions that never had one. Sales and marketing have always run on judgment nobody instrumented: who we sell to, why we win, what to say. You could always measure whether a campaign got opened. You could never measure whether the belief underneath it was still true. Same gap in underwriting, claims, procurement.
Now the part I’d want any founder building harness parts to sit with. Is self-assembly a permanent market or a transitional one?
Both, and the boundary isn’t time, it’s whether anyone will ever be funded to build the harness at all. There’s an enormous long tail of jobs, horizontal and vertical, where the market is one team or one region or one weird workflow, and no investor is writing that check no matter how real the pain is. There’s also usually not enough specific context in those jobs for a vendor to beat a competent self-assembler anyway. That tail is permanent, and it’s most of why Lovable exists. Where a great harness does win, self-assembly shrinks, and you don’t get to sell your ontology layer to that harness maker as consolation, because ontology is precisely what they cannot outsource. So the durable market is the tail, the enterprises whose data means they’ll always build, and the very large middle holding a handful of tools that need something to make them cohere.
Which is why harness parts aren’t a destination. They’re a starting position with two doors out. Down, into hay: become such a real primitive that self-assemblers and harness makers alike adopt you as infrastructure. Or up, which is available to almost nobody else, because a context and instrumentation layer already holds the ontology and the loop, the two properties that can’t be shortcut, and what it lacks is the role UX and the singularity, which are hard but buildable in a way that “acquire ten years of domain ontology” is not. Nobody walks from observability up into being an application. An ontology holder can.
So the real question for a company standing here isn’t which kind of hay it is. It’s whether it’s a harness that hasn’t picked its rider yet, and the founders who know which door they’re walking through before their Series B will look very different in five years from the ones who let the market decide.
That’s the core of it. But the analogy keeps giving, and two more businesses are hiding inside it.
Here’s the thing about owning a horse: it has to be ridden. Every day. Whether or not you feel like riding it. Sometimes the owner can’t, sometimes they have more horses than riders, so they hire someone to come ride.
That’s the labor business, and every serious harness company will eventually be offered it by their own customers: your riders can use our harness, or you can just buy the riding from us. Priced on outcomes, out of the labor line rather than the software line, which is the categorically bigger budget I keep going on about.
The first rule is the one people skip: you cannot sell the ride without owning the harness. Anyone selling outcomes on a harness they don’t own, wrapping a model and staffing the gaps with humans and calling it AI labor, is a services company with services margins. The margin lives in the loop, not in the labor arbitrage.
Which is also where the AI-native services companies sit, the ones buying a traditional services business and running it on their own agents. They don’t break the rule, they take it to its conclusion: they’re harness makers who decided to keep the harness and sell the work instead. Different financial sport, though. Returns come from margin expansion on acquired revenue rather than multiples on ARR, which is closer to private equity with a technology thesis than to venture software. You capture all of the value in one business instead of a slice of it across a thousand.
Sierra and Decagon are renting rider and the sequence matters. They look like an extension of the harness, but they didn’t extend into labor, they started there. Nobody bought Decagon to make their support reps more fulfilled. They bought deflection, and the pricing tells you everything: per resolution, not per rider. That’s a ride, not a seat. They built a harness because you can’t sell rides without one.
Which raises the useful question for predicting what converts next. Why did support go first? Not because those founders are smarter. Because the rides that get sold first are the ones you can grade. A support resolution is the most evaluable unit of work in the enterprise: did it escalate, did the customer come back, did they churn. Collections, claims intake, prior auth, and coding against a test suite are close behind. Org design, executive hiring, and the M&A call are a long way off.
And a lot of people are wildly early here. Everything I’ve experienced battling with Codex and Claude Code says judgment still matters enormously, so the riders you can actually sell today are the ones at the other end of that list: the rides nobody wants, the horse that has to be exercised regardless, the work that exists because somebody has to do it and nobody has ever enjoyed doing it. Start there.
The last one isn’t where we invest, but I don’t want to be glib about it, because it’s going to be one of the largest pools of money in this cycle.
Most of the economy is not early adopters. It’s normies: people and businesses who are never getting on the horse because a vendor sent them a launch email. They need somebody standing next to them saying it’s safe, wiring it into how they actually work, and staying until it sticks. That is a services market measured in billions, the consulting firms and regional SIs are already harvesting it, and it’s real work rather than a tax. A great harness deployed by nobody changes nothing. Harness makers should want that layer to exist, because trainers are distribution that reaches customers you’ll never sell directly.
What you shouldn’t do is become one, which brings me to forward-deployed engineers. FDEs are free services delivered ahead of a sale. They work. They close deals, get first customers live, teach you things about the domain you couldn’t have learned otherwise. As a bridge between what your product does today and what your customer needs today, they’re fine.
But run that at scale and the FDE isn’t a go-to-market motion, it’s a product deficiency with a headcount line. The whole promise of the harness is that it absorbs the ontology so the rider doesn’t need a trainer standing next to them. Every quarter your FDE count grows in lockstep with your customer count is a quarter you should be asking whether you’re building a harness or a consultancy that ships software.
Now that the vocabulary is on the table, look at what Salesforce did this week, because it’s the whole framework being argued out in public.
Claudeforce puts the CRM inside Claude. Thirty-seven prebuilt sales skills, sellers querying and updating live records without opening Salesforce. On its face that looks like the horse taking the application layer. It isn’t. Read what each side kept. Salesforce provides the data, the metadata, the workflows, the business logic, the governance, and the MCP servers. Anthropic provides the model and the surface. Salesforce even calls its half “the AIforce harness.”
So this is a company conceding rendering while keeping the ontology, and saying so out loud: the value was never the UI, it was the data and the metadata and the years of encoded workflows. Which is the headless argument from earlier, executed by the largest application company on earth.
But run Salesforce against the four properties for a seller. Ontology: it’s a container for each customer’s ontology, built by their admins and their SI, not one Salesforce owns. Interaction model: sellers have hated CRM data entry for twenty years. Loop: Salesforce doesn’t get better because you corrected it. Singular: that seller also lives in Gong, Nooks, LinkedIn, and a spreadsheet.
Three of four fail. So Salesforce didn’t cede the harness for salespeople. It admitted it never had one, and repositioned as hay, priced on API consumption rather than seats, which is the pricing rule above executed correctly.
The risk is the one this framework predicts. If the seller’s day happens inside Claude, the corrections and the memory of how that rep works accumulate there. Records to Salesforce, loop to the assistant. And they’ve done the one thing so far my first reason says not to do, which is wed themselves to a single model provider ( I assume GPTforce is coming).
I don’t know how it turns out. I do know which layer to watch, and it isn’t the interface. It’s whoever ends up holding the loop.
The consolidation is happening faster than almost anyone expected. One rider, one harness, one horse. Which means very few companies can win the application layer in any function or vertical, and the ones that do will win something much larger than the software budget they started with, because their customers will hand them adjacent categories voluntarily, in month two.
If that’s your game, there’s no partial version of it. Go for all of it or go do something else with the next eight years of your life.
And if it isn’t your game, that’s not a demotion. The hay market is enormous, it tolerates more than one winner in a way the harness market never will, and it demands a completely different playbook from the one everybody is copying off the application companies. Sell the instrument, never the judgment. Pool what nobody else can pool. Get picked while the stack is still molten. Be undeniable at one thing long enough that the bundle can’t dislodge you, and if you’re standing on gravity, go take the whole barn.
And if you’re selling parts to the people assembling their own, know that you’re standing somewhere temporary. That’s not an insult, it’s the most interesting real estate in this cycle. But there are two doors out and they lead to completely different companies.
Almost none of you are the horse. And most of you already know whether you’re the harness or the hay. You knew before you started reading.
So the question that actually matters isn’t the one in the title. It’s this: whose playbook have you been running?
If you’re the harness and your roadmap is a series of reasonable expansions, shipped carefully, waiting for pull, you’re running the hay playbook and somebody less reasonable is going to take your rider. If you’re the hay and you’re three modules wide before you’re undeniable at one, you’re running the harness playbook and the bundle is going to show up before you’re ready.
Pick the one you are. Then go run its playbook all the way, and be completely unreasonable about it.
Brett