The $143 Billion Reason to Own Your AI Infrastructure
The Harness Manifesto, Part 10
The edge AI market is worth $25 billion today. By 2034, it hits $143 billion, according to Precedence Research. That's not a forecast from an AI startup trying to juice its Series B. It's a number tracking what happens when companies stop renting intelligence and start owning it.
Here's the part nobody's connecting. Only 18% of developers are actively building AI integrations, according to JetBrains' 2024 developer survey. Fewer still can deploy and manage local AI infrastructure. The market is exploding. The talent pool isn't. And between those two lines on the graph sits either your greatest opportunity or the vulnerability that puts you out of the game.
This post is about which side you end up on. Not because of which model you pick. Because of whether you own the infrastructure that runs it.
Two Frameworks That Changed How I Think About This
Two ideas from completely unrelated sources have been rattling around in my head for weeks. Neither person was talking about harnesses. Both were talking about harnesses.
The Gravity Shift
Vinay Hiremath, the founder of Loom, published a piece earlier this year that reframed something I'd been feeling but hadn't named. For decades, software gravity pulled in one direction: organizations adapted to software. You bought Salesforce, then you spent six months configuring your sales process to match what Salesforce expected. You bought SAP, then you restructured your operations to fit their data model. The software was heavy. The org was light. Gravity won.
AI coding flipped that. When building custom software costs 90% less and takes 90% less time, the economics of buy-and-adapt collapse. Why reshape your workflow to match a CRM when you can build a CRM that matches your workflow? Why force your team into a vendor's mental model when you can build a project tracker that thinks the way your team thinks?
Bespoke is the new default. Not because custom software became fashionable. Because it became cheap. The gravity shifted. Software now adapts to the organization.
This matters for the harness thesis in a way that's hard to overstate. If bespoke is the default, then the companies winning over the next decade won't be the ones running the most popular tools. They'll be the ones running tools built specifically for how they operate. And the infrastructure that enables all of it, the skills, the context, the orchestration, the deployment pipeline, that's the harness.
When I built our first custom skill for a client engagement, it took about 40 minutes. A markdown file encoding their specific methodology for qualifying inbound leads. Not the Salesforce methodology. Not the HubSpot framework. Theirs. The skill referenced their ICP, their deal stages, their disqualification criteria, their language. It ran inside their harness, on their infrastructure, with their context loaded.
That 40-minute skill replaced a $2,400/year software subscription they'd been configuring for two years and still hadn't gotten right. Because the subscription was designed to serve everybody. The skill was designed to serve them.
Multiply that by every workflow in every department. That's the gravity shift in practice.
Non-Code Moats
Rich Mironov, one of the sharpest product thinkers I follow, made a point recently that landed differently after nine posts of writing about harnesses. His argument: code-based advantages are now AI-cloneable within weeks. Maybe days. If your competitive advantage lives in your codebase, you don't have a competitive advantage. You have a head start, and it's shrinking.
Real moats are structural. Proprietary data that nobody else has. Trust and community that took years to build. Network effects that compound with every user. Regulatory positioning that requires relationships, not just code. Brand equity that lives in the market's head, not in a repository.
I'd been thinking about this in the context of skills. Any individual skill can be copied. I've said that since Post 1. But Mironov's framework sharpens something: it's not just that individual skills are copyable. It's that any code artifact is now copyable. The agent that writes your competitor's version of your best feature doesn't need to be better than yours. It just needs to be fast. And it's fast.
So where's the moat?
Your harness encodes proprietary judgment. Not just code. When our harness-audit skill evaluates a client's setup, it's not running a checklist that someone could reverse-engineer from the output. It's applying a scoring methodology refined across dozens of engagements, weighted by failure patterns we've observed in production, calibrated against outcomes we've measured. The code is the easy part. The judgment baked into the methodology is the part that took months of client work to develop.
That judgment lives in the skill descriptions that route agents to the right task. In the error handling that knows which failures are acceptable and which are catastrophic. In the output formats designed to feed into the next skill in the chain. In the context files that teach the agent what "good" looks like for this specific organization.
Code is commodity. Judgment is moat. And the harness is where judgment gets encoded.
Owners vs. Tenants
The $143 billion edge AI market isn't one market. It's two markets wearing the same name, and they couldn't be more different.
Owners build and control their AI infrastructure. They run models on their hardware or in their cloud tenancy. They own the skills, the context, the orchestration. When they need to change something, they change it. When a model improves, they swap it in. When a vendor raises prices, they have options. Their harness is an asset on their balance sheet, even if accounting hasn't figured out how to categorize it yet.
Tenants rent AI capability from platforms. They configure tools they didn't build. They run on infrastructure they don't control. Their "AI strategy" is a line item on an invoice. When the platform changes direction, they adapt or lose functionality. When the platform raises prices, they pay or migrate. When the platform goes down, their workflows stop.
This isn't a judgment call about which is better in every situation. Small teams with limited engineering capacity might correctly choose to rent. But it is a statement about where value accrues.
Of that $143 billion, owners capture margin. Tenants capture dependency.
Google is already shipping air-gapped AI appliances for healthcare, defense, and financial services, with Siemens pursuing similar architecture for industrial AI workloads. Not because those industries are paranoid. Because those industries did the math. When patient data, classified intelligence, or trading strategies flow through third-party infrastructure, the risk isn't hypothetical. It's quantifiable. And the insurance premiums, compliance costs, and breach exposure that come with renting AI infrastructure often exceed the cost of owning it.
But the ownership question goes beyond regulated industries. Any company where institutional knowledge is a competitive advantage, and that's most companies, faces the same calculus. When your AI learns how your business operates, who benefits from that learning? If the answer is "our AI vendor, who can aggregate patterns across all their customers," you're not building a moat. You're contributing training data to someone else's.
The Hybrid Reality
Nobody runs entirely on-premise anymore. That's not the argument. The argument is about control.
The hybrid model emerging looks like this: cloud for frontier intelligence, local for privacy-sensitive workloads and high-volume processing. Same skills. Same orchestration. Different compute layer.
This is where the harness architecture from Post 2 pays off in ways that aren't obvious until you try to deploy across environments. If your skills are markdown files, they run anywhere. If your skills are configurations inside a vendor's web UI, they run on that vendor's web UI. If your context is a set of portable files served via MCP, any model can access it. If your context is an accumulated conversation history inside one vendor's platform, it dies when you switch.
The harness is what makes hybrid deployment possible. Not the model. The model doesn't care where it runs. It processes tokens. The harness determines which tokens, in what order, with what constraints, under what security model, and what happens with the output. That layer has to work across environments or you don't have hybrid deployment. You have two separate, uncoordinated AI setups.
We run this ourselves. Our production skills execute against Claude's API for complex reasoning tasks. The same skills execute against local models via Ollama for high-volume, privacy-sensitive workloads. The harness doesn't change. The compute layer swaps. If Claude doubles their pricing tomorrow, our skills still work. If a better model launches on a competing platform, our skills still work. Because the skills don't belong to the model layer. They belong to us.
That portability isn't theoretical. We've tested it. Same skill, same input, different models. The output quality varies depending on the model's capability. The structure, the routing, the error handling, the composability? Identical. Because those properties live in the harness, not in the model.
The 18% Problem
Only 18% of developers are actively building AI integrations, according to JetBrains' 2024 developer survey. That number has been floating around the industry for months, usually cited as a talent shortage. It is. But it's also something else.
It's a pricing signal.
When supply is constrained and demand is exponential, the people who can do the work command premium rates. We've seen this firsthand. Harness engineering engagements, the kind where we design, build, and deploy a custom AI infrastructure for a client, command rates that would have seemed absurd two years ago. They don't seem absurd to the clients because they've done the alternative math. Hire a full-time AI engineer (if you can find one), spend six months building internal capability (if you're lucky), and maybe end up with something that works (if everything goes right). Or hire a firm that's already built 175+ skills and deployed across dozens of clients, and have something running in weeks.
The 18% number also means something for the companies on the other side of the table. If you're a company that needs AI infrastructure and you can't build it yourself, you're choosing between owning (via consultants or contractors who build it for you on your infrastructure) and renting (via platforms that host it for you on theirs).
Renting is easier. Renting is faster. Renting means you don't need to find that 18%. But renting means the infrastructure belongs to someone else. And when that infrastructure encodes your institutional knowledge, your methodologies, your competitive intelligence, renting starts to look less like convenience and more like a strategic concession.
The companies that invest in ownership now, whether they build in-house or hire specialists, will have infrastructure that compounds. The skills get better with use. The context gets richer over time. The orchestration patterns get refined through production experience. Six months of owned infrastructure creates capabilities that take a new entrant six months to replicate. Twelve months creates a gap that's extremely hard to close.
The companies that rent will have access to the same capability floor as everyone else who rents from the same platform. Which is fine, until they realize that "same as everyone else" isn't a competitive position.
What Ownership Actually Looks Like
Let me be concrete about what "own your AI infrastructure" means in practice, because it's not "build your own LLM." That's a different argument for a different post (and for 99% of companies, the answer is don't).
Ownership means four things.
Own your skills. Your methodology, encoded as portable files, versioned in a repo you control. Not prompt templates in a vendor's UI. Not configurations in Claude's project settings. Files. Markdown. Yours. When a model improves and your skills suddenly produce better output, you capture that improvement. When a vendor changes their interface and your configurations disappear, your skills survive.
Own your context. Your Personal Context Portfolio from Post 7. Your organizational knowledge base. Your decision logs. Your project state. All of it on your infrastructure, in formats that any AI tool can read. Conway wants to own this layer for you. Let it read from your layer instead.
Own your orchestration. How your agents coordinate, what approval gates exist, what happens when something fails, how costs get managed. Post 9 covered why we moved away from n8n to coded orchestration. The principle is the same: if your workflow logic lives inside a platform you don't control, you don't own your operations. You subscribe to them.
Own your deployment pipeline. The ability to deploy the same harness across different compute environments. Cloud. Local. Hybrid. Air-gapped. The harness should be environment-agnostic. The compute layer is a variable. If changing your model provider requires rebuilding your harness, you don't own a harness. You own a vendor-specific configuration.
None of this requires massive engineering investment. Our entire harness, 175+ skills, context architecture, orchestration layer, deployment pipeline, runs on a homelab server and a handful of cloud services. The total infrastructure cost is less than what most companies spend on their Slack subscription. The value isn't in expensive hardware. It's in the accumulated judgment encoded in the skills and context.
The Math Nobody Is Doing
Here's the calculation I keep running for clients, and it keeps producing the same answer.
Take the monthly cost of your current AI platform subscriptions. Add the hours your team spends re-explaining context every session (Post 7 showed this is typically 8-12 minutes per session, which compounds to 250+ hours per year per person). Add the cost of output that needs rework because the AI didn't have your methodology encoded (most teams estimate 30-40% rework rate). Add the switching cost if your vendor raises prices by 50% next quarter.
That total is the cost of not owning your infrastructure.
Now price the alternative. A set of markdown files encoding your methodology. A context architecture that loads automatically. An orchestration layer that coordinates your agents. A deployment pipeline that works across environments. The build cost is measured in days and weeks, not months and years. And the maintenance cost is near zero because the files are just text.
Every client I've run through this math has reached the same conclusion: the ownership investment pays for itself within the first quarter. Not because the build is cheap (though it is). Because the cost of renting, measured honestly, is staggering. People just don't add it up because the costs are distributed across wasted hours, rework, and vendor lock-in that hasn't triggered yet.
The Window
We're in a window right now. The models are good enough for production work. The tooling for building harnesses exists and is accessible. The market hasn't yet sorted itself into owners and tenants in a way that's hard to reverse.
That window is closing. Not because the technology is going away, but because the compounding effects of ownership create gaps that widen every month. A company that starts building its harness today will have six months of accumulated skills, context, and orchestration refinement by October. A company that starts in October will be starting from zero while their competitors are on their hundredth iteration.
This is the same dynamic that played out with websites in the late 1990s, with mobile in the early 2010s, with cloud in the mid-2010s. The companies that built early didn't just get a head start. They got compounding returns that made the gap impossible to close without massive investment. The companies that waited didn't fail because the technology was unavailable. They failed because the market leaders had already captured the structural advantages.
$143 billion is flowing into edge AI infrastructure over the next decade. That money goes to owners, not tenants. The question isn't whether your company will use AI. Every company will use AI. The question is whether you'll own the infrastructure that makes AI useful for your specific business, or rent generic capability from a platform that serves your competitors with the same tools.
Build the harness. Own the infrastructure. Capture the value.
Or pay rent forever and hope the landlord doesn't raise the rates.
What's Next
Nine posts of what to build and why to build it. Post 11 is the one I've been building toward: the full case study of how we built ours. The Robot Friends harness, 175+ skills, multi-agent orchestration, homelab infrastructure, the whole system. What we built first. What we built wrong. The three mistakes that cost us weeks and the one decision that saved us months. No theory. Just the build log.
Post 11: "How We Built Ours (And What We'd Do Differently)"
Richard Vaughn is the founder of Robot Friends. He has built 175+ production skills, designed multi-agent systems, and helps companies turn their accidental AI setups into defensible business assets. He writes The Harness Manifesto on Substack.
Frankie404 is the AI co-author of this series. It runs partially on local inference behind its own walls, which means portions of this post were written at zero cost, zero latency, and zero data leaving the garden.