What is a shared AI harness?

A harness does two jobs. The first is visibility. Work done inside it, against the team's real systems, is work AI can read: the account record, the positioning, the campaign in flight. Work done in a spreadsheet on one laptop is invisible to it.

The second job follows from the first. Once AI can see the work, it can help do it, and one person's skill becomes the next person's starting point instead of staying in their chat history. A repository of skill files, checks and connections is how the harness is stored. It isn't what the harness is. Sam shows ours in The Squeeze 01.

When an AI output is wrong, the fast move is to rewrite it. That fixes one page. Fixing the skill, the check or the context that produced it fixes every page after it. The loop has five steps:

1. Use. Someone runs a skill in their own work.
2. Notice. The output is wrong, slow or off-brand.
3. Tell a builder, the same day, in the flow of work.
4. Fix upstream. The builder changes the skill, the check or the context.
5. Ship. Reviewed, released, and on every machine by the next session.

Many of those fixes become rules the harness enforces, and a rule that runs beats a rule people remember. Nobody breaks a brand guide on purpose. The PDF just isn't in the room when the draft gets written, and a check is.

Cycle time is the number: days from "this is wrong" to "fixed for everyone". The old way to improve a tool was to wait for the vendor's next release. In a harness, every task is a chance to make the next one better. Two loops, run on camera.

A harness has two populations. Runners use it: the rep who asks for ten good accounts today should never have to think about which system holds what. Builders keep it improving. They take the second manual run of any task and write it down as a skill, and they answer for the harness the way a product owner answers for a product.

Most builders are not new hires. They are the semi-technical people already doing configuration and systems work, and many are already building skills in pockets. Nobody has given them a map, a home for the work or the time. The shortest loop is the one where the user is the builder: a person tired of copying between four tools fixes the task for themselves, and the fix reaches everyone.

The product needs a lifecycle sized to its users. Two AI-fluent people supporting each other need no ticket queue. Two hundred people need intake, a release rule and a named approver. The risk at any size is sprawl: five versions of the same skill, because five people each took their own swing. Collecting the twenty best skills on the team isn't the job. Somebody has to draw the boundaries and merge the duplicates. Owning the harness this way is GTM product thinking.

Connecting AI to a system through MCP tells the agent what that system can do. A CRM or a GTM platform may expose fifty actions. Without instructions, the agent reads all fifty, guesses, tries one, and tries another when that fails. Ask twice and it may take two different paths.

The other half is a skill that says how this team uses the system: which question to ask it, in what form, and what not to ask it for. That half is where the team's judgment lives, and it is what makes the same request come back the same way. The two halves side by side.

A harness built for engineers carries engineering's tools, and loading it into every marketer's session buries the request under noise. Curate one per group instead: campaigns, BDRs, product marketing. Many harnesses can live in one repository, so the extra ones cost almost nothing.

A shared setup drifts unless something checks it. Ours checks itself when a session starts, stays silent while everything is healthy, and names the broken part when something isn't. The harness reads the team's knowledge rather than holding it. What it reads is shared context, and that's the next entry.

Sam, Charles and Kaitlin work in one harness across three laptops. These are examples, and they change as the setup does. The Squeeze 01 walks through two of them.

IT already knows how to ship a laptop with an image, approved tools and policies that install themselves. The rollout that ships an approved AI tool can also ship the brand rules, the connections to the account and customer systems, and the checks. That is the parts. A large company needs three roles to run the loop on top of them:

• A product owner who uses AI every day in the GTM work the harness serves. You can't own a product for a user whose workflow you don't know.
• A program owner who runs the cohort, the protected time, the cadence and the budget, and reports what is in the harness and what isn't.
• A builder cohort of three to five people with protected time, writing the skills their own teams use.

The hard call is who gets write access. One end is a tight enterprise release, with security and legal sign-off on every skill. The other is a handful of builders who already write skills, meet every other week, and merge what overlaps. Start with the small group of fluent people, prove the habit, then formalize. Train the runners on the skills, not on the repository. They need different enablement from the builders, and they should never need the systems map.