For ninety percent of people outside software engineering teams, AI at work still starts and ends in a blank chat box. You open a tab, paste in a bit of text, hope for the best, and get a passable, slightly beige answer back. Gallup's 2026 polling still puts daily AI use across the broader US workforce at around twelve percent.
Look across at software engineering over the last eighteen months, though, and they have been going hammer and tongs in a completely different direction.
Engineers didn't stop at chat windows. As Gergely Orosz has documented in The Pragmatic Engineer, engineering organisations moved rapidly down a clear curve: first autocomplete, then chat inside the editor, then single agents, and finally into harnesses that orchestrate whole fleets of agents across a codebase. At Uber, eighty-four percent of developers now use agentic coding tools. At Ramp, seventy-five percent of merged code changes come through their internal agent, Inspect. Stripe's Minions merge more than 1,300 pull requests a week, and Spotify's Honk ships 1,000 agent-made changes every ten days.
My bet is pretty simple: commercial and enterprise knowledge work is on the exact same curve as software engineering, just eighteen to twenty-four months behind. And the defining shift won't be a smarter model or another thirty point-solution "agents" bolted onto existing software. It will be the agentic harness becoming the primary workspace where knowledge workers spend their day.
What an agentic harness actually is
Earlier this year, Vivek Trivedy at LangChain wrote a great breakdown on the anatomy of an agent harness using a simple formula: Agent = Model + Harness.
A raw model sitting in a chat window is not an agent. It becomes useful when you wrap it in a harness: the runtime infrastructure that handles persistent state, tool and API execution, curated skills, sub-agent orchestration, and feedback loops. In a follow-up experiment on improving deep agents with harness engineering, the LangChain team held the underlying model completely fixed (gpt-5.2-codex) and only tuned the harness around it. Their agent jumped from outside the top thirty to the top five on Terminal Bench 2.0.
OpenAI's Codex team saw the same thing when they ran a five-month experiment shipping a million-line internal product with zero manually-written code. When their agents failed on complex tasks, the fix was almost never waiting around for a smarter model. It was fixing the environment, the context, and the verification loops around the model.
Up to now, most people have treated harnesses as an engineering concept. They aren't.
When Anthropic launched Claude Cowork and rolled out enterprise admin and workspace controls, they described it explicitly as bringing Claude Code's engineering harness to knowledge work. Intercom didn't even wait for a dedicated knowledge-work product: they gave Claude Code directly to more than 1,000 non-engineers, including their customer success and GTM teams, and saw roughly a third of them using it every week.
The quiet collapse of the eight-tab workday
To understand why the harness matters so much for roles in sales, customer success, consulting, and operations, look at what the big systems of record are doing.
In April 2026, Salesforce announced Headless 360, exposing twenty-five years of platform infrastructure as APIs, CLI commands, and more than sixty MCP tools that inherit a user's existing identity and permissions. On stage, co-founder Parker Harris put the direction as a blunt question: "Why should you ever log into Salesforce again?"
Look, the systems of record aren't going away, and nobody is migrating off them. What is collapsing is the working real estate on our screens.
For the last decade, enterprise work has meant acting as the human copy-paste layer across eight browser tabs: a CRM, a call recorder, a support queue, a slide deck, a wiki, email, calendar, and Slack. Over time, it felt like half the job in customer-facing roles had become feeding data into Salesforce so someone else could read a dashboard.
When every system of record exposes itself through the Model Context Protocol (MCP), the work moves out of those individual interfaces and into whatever surface you are already sitting in. Your day converges on two places instead of eight: a shared reporting cockpit for visibility, and the harness where the actual work gets done.
Workslop, and why most enterprise AI roadmaps have this backwards
We all know what bad AI output looks like now. Researchers at Stanford and BetterUp Labs recently coined the term workslop in Harvard Business Review to describe AI-generated content that looks polished at a glance, lacks any real substance, and quietly shifts the burden of thinking and clean-up onto the poor colleague or customer who receives it.
Honestly, you can spot default AI slop from a mile off now: way too many bold subheadings, tiny explanatory text under every bullet, and a breezy, over-eager tone that sounds nothing like a real human. If you send recognisable Claude or ChatGPT slop to an enterprise buyer today, you actively devalue yourself.
And yet, when I look at the internal AI roadmaps being pitched to commercial teams right now, most of them are designed to industrialise workslop.
Instead of giving people a single connected workspace with deep context, companies are building dozens of narrow, unconditional agents: a bot that fires after every call to draft a follow-up email, a bot that flags usage drops and creates a CRM task, or a bot that summarises every meeting transcript onto a record.
If you run forty customer calls a fortnight, unconditional agents don't remove work. They just create heaps of noise. An agent that spots a risk and drops a task into your queue has automated the cheapest five percent of the job and handed you another item to triage. Worse, when teams are told to use one point solution in their browser bar, another inside their CRM, and a third in chat, people get overwhelmed and adoption dies.
Choosing and designing a harness is much closer to picking a CRM or an IDE than rolling out a browser plugin.
What a knowledge-worker harness needs to actually work
Borrowing Birgitta Boeckeler's framing on Martin Fowler's blog, a good harness does two things: it uses feedforward guides to help the agent get the work right on the first pass, and feedback sensors so mistakes get caught before they reach human eyes.
In software engineering, your codebase is the ground truth, and your compiler and test suite are the sensors. In commercial and customer-facing work, you don't have a compiler to tell you that a strategy deck misses the mark or that an email will annoy an executive sponsor.
If you are building or adopting a harness for knowledge work, I reckon three layers underneath the interface decide whether it delivers real value or just faster slop.
First, it needs a centralized context layer that captures what isn't in the CRM. A harness reasoning over thin CRM fields will always give you generic answers. You need a living context layer that combines the objective data from your systems of record with the unwritten reality of an account or project: who actually holds political capital, what went sideways a year ago, and what the buyer really cares about. Because I'm a bit ADHD-brained and genuinely terrible at typing up admin notes, I just get out of my chair after a call, hit a hotkey for a voice tool, and ramble for three minutes about the real flavour of the meeting. Once that context sits in one place, the value snowballs: every layer you add makes the next answer sharper, which means you trust the harness with bigger pieces of work.
Second, it needs curated skills and a real human review gate. A harness with no skill library is just a chat box with connectors. You get good output when you treat the agent like a junior team member: you don't tell it "build me a deck" and let it guess. You point it at specific assets that already worked, give it a maintained playbook, and iterate back and forth. And nothing should ever write back to a system of record or go out to a customer without a human approval step where you check the facts and make sure the writing still sounds like you.
Third, it has to be portable at the foundation. Frontier models leapfrog each other almost monthly, and the harness market is moving just as fast. Any strategy built around a single vendor's current lead has a ninety-day shelf life. The smart bet is keeping your connectors on open standards like MCP (now backed by AWS, Google, Microsoft, OpenAI, and Anthropic under the Linux Foundation), your playbooks in open formats like Agent Skills, and your context layer in plain-text Markdown (.md) files you own outright.
If you switch harness vendors in eighteen months, the only thing you should lose is the user interface and a week of re-tuning. Not your context, not your integrations, and not your playbooks.
The biggest asset you build in the meantime isn't technical anyway. It is the skill of delegating real work to an agentic team: knowing how to feed the harness context, how to direct it against existing work rather than letting it guess, and how to edit what comes back so it never reads like slop. Engineering teams have already made that jump. The rest of enterprise work is next.
