For a while I tried to keep everything in one place. I build software for Teachfluence, an education platform, and I had all my skills, every command I had taught the AI, every convention worth remembering, piled into one setup I used for every project. It worked until it didn't. Past a certain size I couldn't hold it in my head, and the skills started drifting away from the projects they were meant to serve: the right one wouldn't fire, the wrong one would, and I'd spend the start of every task working out which was which. The work was never the hard part. Managing the thing I had built to help me do the work was.
But the tangle was only the visible problem. Underneath it was a quieter one. The work the AI handed back was only ever as good as what I gave it, and giving it good input every time depended on me being sharp that day. Because of the way I work, I kept doing similar things over and over, and in that repetition I got sloppy: I'd under-specify the task, forget to point it at the right files, skip the convention that mattered. Nothing dramatic. Just a slow tax on every result, paid in the moments I was tired, or distracted, or moving too fast.
So the harness I actually wanted was never about speed. It was about making the quality of what I handed over stop depending on my energy that day.
The fix was to stop keeping one setup for everything. I gave each project its own harness: only the skills that project needs, its own conventions, its own review gate, bound to that repo and nothing else. That is really all a harness is, once you strip the word down. Not a pile of clever commands. A set of skills split by concern and tied to the one project they serve, so the right one is the only one in the room.
Which quietly solved the handover problem too. When a harness only knows one project, it can hold that project's context for me: what the conventions are, where things live, what the review will check. The careful setup I used to skip on a bad day is simply part of the harness now. It doesn't get tired.
The last thing a change passes through before I look at it is a review gate: a check the work has to clear on its own first. What clears it isn't a linter. It's a separate agent, a subagent spun up with one job and none of the history, that reads the diff as a stranger. It has no memory of having written the code and no stake in defending it, and it comes back with a verdict instead of a shrug.
The part I am most careful about is a restriction I put on that reviewer: it can't fix anything. It holds no power to edit the code at all. Give a reviewer the ability to patch what it finds and it will quietly soften its own findings, because fixing is easier than reporting, and before long it is grading its own homework. So I split the roles down the middle. One subagent writes the code. A different one, with no editing power, tears it apart. Neither is allowed to become the other.
For everything the harness does, there is a line it doesn't cross. It can run the work, but it can't decide what the work should be. It can't tell me what is worth building, or who it is for, or which capability actually matters to that audience. Those are judgment calls, and judgment was the one thing I never handed over.
There is also not a single time I let it merge on its own. It opens the pull request and stops there. When it gets stuck it doesn't loop, it freezes and asks me. I read every diff, doubt it out of habit, and iterate before anything lands. For a while I thought of that as a safety feature I had bolted on. It isn't. It is just my own habit written into the machine: the double-check I was always going to do anyway.
Deciding what to build, and looking hard at it before it ships. Those are the parts that are mine, and they are the parts I built the whole harness to protect, not to replace.
I built all of this to make my own work faster, and for a while that is all it was: a personal tool, scoped to me. What I didn't expect is where its real value showed up. It wasn't in my own speed. It was the moment the team started working through the same harness. When the conventions, the review gate, and the shared vocabulary live in one place everyone runs through, the work stays coherent without anyone having to independently remember the same twenty things. The harness turned out to be less a productivity trick and more a way for a group of people to hold a single shape.
Which is also why you couldn't just take it. Lift the whole thing into another team and it wouldn't fit: it is shaped around how we work, the mistakes we keep making, the reviews we keep needing. Most engineers I meet don't have a setup like this at all. They prompt blind, and never find out how good the output gets once the harness is tuned to them. The value was never the configuration. It was the fit.
Making that starting point less brutal is what I am working on next. I am building another agentic harness, one I plan to open up once it holds its shape: not to hand anyone my setup, but to give them a scaffold to grow their own. The fit still has to be yours. The start doesn't have to be from scratch.