Every SaaS business will become a harness around a model, whether or not it has realized it yet. That is the claim in a new essay by Shrivu Shankar, published August 24, 2026, and it is the most useful framing of the agent era to land in months. Shankar, who writes the Shrivu’s Substack newsletter, defines a harness broadly: all the infra, interfaces, context, and state that surround a stateless LLM. Not just LangGraph or Claude Code or Codex, but the orchestration, permissions, review loops, and institutional knowledge that turn a raw model API into work that ships.
The argument is that the trajectory is already visible. Companies start selling software the traditional SaaS way. Then engineers pair with agents, and product and sales start doing the same. Then individuals operate harnesses. Then individuals orchestrate harnesses. Then harnesses orchestrate individuals, and at that point the company has become a harness. The work to produce the software service has moved from people to the orchestration layer. What is left is the context, integrations, and human review interfaces.
The inversion nobody has priced in
The sharpest line in the essay is that the relationship between software and org structure inverts. In the old model, you built software to fit your org chart. In the harness model, the org chart becomes a question of where to put people so the harness gets the most taste and judgment out of them. Humans are part of the harness.
That is a real change, not a rebranding. It means headcount planning, performance review, and even hiring become functions of harness design. A company that gets this right routes every ambiguous decision to a human with relevant taste and routes every verifiable decision to an agent. A company that gets it wrong either drowns reviewers in agent output or ships agent output unreviewed.
Shankar anticipates the obvious objection: this sounds like an AI slop factory. His answer is that a good harness picks where human inputs matter most. A product decision could come from an agent fanning out questions to reps in customer meetings, then synthesizing a demo for a product lead to review. A feature suggestion pulled from a customer call becomes an architectural decision presented to an engineering taste-holder. A UI redesign kicks off after aggregating feedback, testing variants, and presenting the top options to a design taste-holder. The harness maximizes customer value by spending human attention only where it is needed.
He is honest that this is hard today. Even with frontier models and a well-crafted harness, trusting agents to handle the outer loop is difficult. He notes his team has spent a lot of time trying. But he does not think it is worth betting that models will not eventually do this, especially as planning-and-review work gets broken into tasks with verifiable rewards that labs can train on.
What this means for the moat
The second half of the essay is where it gets uncomfortable for anyone running a SaaS company. Differentiation in software has historically come from trust, distribution, efficacy, and domain context. In a proactive background agent world, Shankar argues, your ability to construct the harness is how you maintain all four. The harness shapes what must be true for work to ship (trust), how fast products land (distribution), the speed and context of feedback loops (efficacy), and how institutional knowledge is ingested (domain context).
The consequence is that harnesses stop being internal tooling you would happily buy and become something you would no more outsource than your product-eng org or your go-to-market team. That is a direct threat to the entire devtools and vertical SaaS category. If the harness is the company, then buying a harness is buying the company.
Shankar points to in-house AI developer tools at Ramp, Stripe, and DoorDash as the leading edge. For AI-pilled companies, waiting for an SDLC tool vendor to add an integration or reach a level of cost-efficacy increasingly bottlenecks their ability to build and maintain their product. The tech stack is too bespoke, governance too restrictive, critical feature support too slow, or the cost model is wrong.
If the entire outer loop can be done by a third-party harness, then the business has been commoditized.
He does not expect everything to be built in-house. The recommendation is to own the top-level harness, the one that decides what to build and reviews what comes back, and plug vendor products into specific workflows. Eventually a third party will get good at an enterprise-level spec-to-tested-pull-request pipeline, and at that point a company can swap out that part of the loop while keeping the agents that write the input spec and handle the output. But if the entire outer loop can be done by a third-party harness, then the business has been commoditized.
The headless requirement
The most concrete prediction in the essay is buried near the end: all software a software company uses, on or tied to the core build or sell paths, will need to be headless so the outer harness can run it. That is a specification, not a vibe. It means APIs over UIs, structured outputs over dashboards, and machine-readable state over screenshots. Vendors that cannot offer this will be routed around.
Shankar also predicts an unusual amount of in-house harness building on both the build and sell sides, org structures reshaped around their place in the business harness, and AI-native startups beating incumbents in domains where the moat can be easily harness-ified.
The essay builds on his earlier piece, The Transposed Organization, which sketches what an org of taste-holders could look like. Read together, the two posts are a coherent thesis about how AI changes the shape of a company, not just the productivity of its engineers.
What to watch
The testable claims are the headless one and the in-house tooling one. If Shankar is right, the next twelve months should bring a wave of enterprise software vendors shipping agent-first APIs, and a wave of mid-size software companies publishing engineering blog posts about harnesses they built instead of bought. The counter-signal would be vertical SaaS incumbents holding their accounts by shipping harnesses of their own. Either way, the question for every software company is the same one Shankar poses: what is the part of your business that a customer would pay for even if the model underneath were swapped out tomorrow? If the answer is nothing, you are already a harness. You just have not moved the people yet.