Building a knowledge-work harness: notes from GOSIM Shenzhen

In May I moderated a panel on AI and education at GOSIM in Paris. In October GOSIM invited me back, this time to Shenzhen, to speak at the Agentic AI Summit. For a cultural researcher it is a privilege to talk about this work in a country that is this far ahead in building AI and leaning this hard into open source, and it is a fitting one, because my own practice runs more and more on open-weight models and open tools. This is the talk as given on 16 October, slide by slide, with what I said over each one. The slides are adapted from the conference deck.

I am not a developer. I run a strategy practice, and for about a year now that practice has run on an agent harness, day to day. So this is a field report. A report from someone who took the coding harness idea and tried it on a job it was not designed for.

Where this comes from, briefly. Twenty years in advisory and strategy, across the US, Europe and Asia. Since 2020 my focus has been AI; I published one of the first reports in Germany on generative AI in 2021. And this year I co-founded the Make It So program with the Chiba Institute of Technology in Tokyo and Flinders University in Adelaide. It is a program for executives who learn about AI by using it, and by working out what it means for their own organization. That is why harnesses and strategy end up in the same twenty minutes.

The room had discussed harnesses all day, so I did not define the word from scratch. But I wanted to say which definition I lean on. Sydney Runkle at LangChain puts it like this: agent equals model plus harness. The harness is the scaffolding around the model that connects it to the real world.

I like that because it says something people forget. The model by itself does not talk to the world. The harness decides how work reaches the model, and it decides how the result reaches you. Skills, memory, tools, context. Everything around the model in that picture is a decision somebody made about how work should run.

Which brings me to a man who never saw a language model. “We shape our buildings, and afterwards our buildings shape us.” Churchill said it in 1943, when Parliament was deciding how to rebuild the chamber after the bombing. He wanted the old shape back, small and cramped, because he believed the room makes the politics.

I think this is exactly where we are. A lot of people have picked a harness. Most of them did not experience it as picking a harness. They signed up for a service, ChatGPT, Claude Code, whatever the company gave them. And that service is now shaping what they think AI can do, and what kind of work they do with it. They are living in a building they did not choose.

So here are three buildings.

Claude Code. You hand it the work, then you steer and review. It is a complete opinion about how you should work with Anthropic’s model. It is a very good opinion. But it is theirs.

The DeepSeek Harness, released this summer. Everything is a plugin, including the model. A lab shipped it, but the opinion is yours to replace. You can shape it.

And Pi. Primitives, not features. It comes almost blank. For people who already know how they want to work, that is the point, and it is why so many coders are moving to it. They have understood that in 2026 the harness matters more than the model. The harness is what tells the model what the job is.

Three opinions about how work should run. Knowledge work has one too. It is a little more implicit, and it is rarely written down.

Two things were true in the same week.

On the left, Steve Yegge writes that all harnesses will soon be bespoke. Every team will build its own. In coding, the gains are so large that people are building their own buildings.

On the right, a story from the day before the talk. Accenture told its employees they could now spend twenty-nine dollars a month on Claude. Twenty-nine. Some of those people had been spending a thousand a month at the peak.

Individuals are getting faster. Organizations are rationing. That is not Accenture being stupid. It is what an organization does when it cannot see where the money goes.

This is not new. Ethan Mollick has been saying it for a year: the gains are not being captured by companies. And Harvard Business Review published the mechanism. Rosani and Farri looked at one energy company, two hundred senior managers. Almost all of them used AI several times a day. Almost none of them used it with their teams. Everyone is getting better alone.

So for professional work, this is not an engineering problem. The engineering works. It is a management problem.

This is what it looks like from the inside. Everyone has their own setup. What works stays with whoever found it. AI is used alone, rarely together. Nobody decides what is worth sharing. And the access rules that decide what a team can even build were set years ago, for other reasons.

When everyone has their own setup, the gains stay with the individual. The gains exist. They are just in the wrong place.

My answer to that was an essay I called Strategy as Protocol. The idea is simple. Write down how you actually work, as plain-text rules. Rules that people can read and that machines can execute. The firm’s strategy as the operating instructions of the harness.

Simple to say. Quite hard to do.

One reason it is hard: coding has agreed protocols. Not because all coders agree on everything. They don’t. But a lot of things are settled, and nobody has to discuss them. Git gives you a history of every change. Tests tell you whether it works. Lint enforces style for free. The pull request is review as a protocol.

Knowledge work has, well, organizations call it culture. What it actually looks like is version seven of the deck for client XYZ. The last version someone emailed. A brand guideline nobody opens. In coding you can teach the agent what is correct. In knowledge work, correct depends on whoever is reading.

A friend of mine, Martin Spindler, objected to this when I first wrote it. He said knowledge work does have a standard. It is informal and low quality, and it is called management. He is right. The protocol exists. It lives in habit.

This is why everyone is talking about taste right now. Taste is a good word. If you have it, you can exercise it. But here is the problem with taste. Unless you can articulate it, you cannot delegate it. Not to a colleague. Not to an agent.

What comes out of this work is not a culture program. It is a folder of files. Taste, written down.

Brand, as rules a machine can follow. A deck goes to a client only after a person has read the last page. Headlines describe, they never dramatize. Two typefaces, nowhere a third.

One of these files every company already has, in some form. The other three, sales, culture, decisions, almost nobody has written. At least not in a way a machine can execute. It is stuck in a hundred PowerPoint documents, and nobody knows which one is the correct one. That is why an agent never knows what the job is on a Tuesday.

To show what it looks like when you actually build it: this is my design file. One file. From it comes my website, my decks, my diagrams, my animations. Everything I publish, including this page. For someone who works mostly alone, that is a big deal. It is not about speed. It is about consistency and meaning. That is how one person works like a team.

And writing it down changed how I work. I thought I was documenting my process. I found out what my process actually was. Then the file started shaping what I do. Churchill again.

There are four reasons I still stay in the loop on some things: consequence, judgment, relationship, learning. Habit is not on the list.

But that is me. I know what I want, and I can articulate it. This is one inner loop. One person, one harness, what their work needs. Now imagine two hundred of these in one company.

This is the framework I use for it. Two loops.

The inner loop is a team working out what AI does for their own work. Writing their own skills. Writing down rules that were never documented. Trying harnesses and models until the agents work the way they work. A lot of organizations already have this. That is where the gains are.

The outer loop is the organization capturing what worked, curating it, and giving it back. In most companies this loop does not exist. There are AI initiatives in every department. Everybody is spending. Nothing comes back. That is why the gains stay where they are.

Someone has to read what comes back and decide what to improve. That is the outer loop, and it needs an owner. And the outer loop is not just a memo.

When I say management problem, I do not mean management decides top-down how everyone should use AI. That is the memo. The memo does not work.

The outer loop has two jobs. First, make writing it down worth the trouble. What a team writes has to travel and get reused, and the team has to see it being used. Otherwise nobody writes anything. Second, set the interface. So what the sales team writes can run for the brand team. Not identical. Interoperable.

Open source works because publishing is cheap and gets you users. The outer loop has to reproduce that inside a company. Or it is a registry with nothing in it.

Stripe did this. Everybody there was building their own skills and their own connectors, often for the same tools, and nobody could see it. So they built a platform where teams build their own skills and agents, and the organization can see all of it. A thousand skills from a hundred teams, and fewer than ten people run it. The inner and outer loop are my words for it, not theirs. And Stripe built the first version in a week, on an open-source harness.

Because the parts are becoming open.

On the left, bb, which I use every day. At first glance it is an IDE that looks like any chat interface. But everything about it can be changed with one prompt. You can build your own views and end up with a working interface that is tailored to your team and your organization.

On the right, pi-Forge, a very young open-source repository. It interviews you about your work, a set of questions you have to answer, and if you can say what you do, it builds you a version of Pi with the tools and skills for exactly that. It strips out the things that only make sense in a coding environment and gives a knowledge worker something that fits their work. Because we do not have Git.

I do not care about the tools. I care about what they point at. Everything in the stack is becoming something you can download. The model. The harness. The interface.

Except the one folder that makes the difference. The answers. What does this organization want to delegate, and under which rules. Nobody can download that. And nobody can ask it for you. A tool can interview a person. It cannot interview a company.

That is the work I do with organizations.

Building your own harness is how you find out how you actually work. And then it starts shaping how you work. The only question is who in your organization is watching.

If that question is open in your organization, write to me.