Day 37 of 365.
I've written a few times about the thin harness, fat skills idea Garry Tan of Y Combinator put a name to. Until this weekend it was a framework I believed in and I have been using for myself. At 5:21am on Saturday morning it walked into my inbox in three documents.
An enterprise client I've been working with for several weeks sent a feasibility memo, an implementation manual, and a mockup deck. Together they laid out the full system we had been discussing on Friday's call. I had been planning to spend my weekend writing the proposal myself. He had already written one that worked. The concepts were in place and he was keen to take on the fat-skills part himself.
I read it twice over coffee. By the time I closed the laptop I knew exactly why his version was the right direction to take. He'd done the part I shouldn't have been doing in the first place.
The reason his version was better is the same reason I'll never want to write the fat skills myself. The fat skills are the markdown rules of domain expertise. The domain experts always need to own those skills, and write them. Any time I'm involved in that, the system gets worse. The experts know their styles, they can tweak their skills daily, codify them and commit them. If he's sending in support tickets for me to change or manage that, I'm failing as a platform-agnostic chief AI officer they can rely on.
I had been working on a long-term plan with this client. The concept was simple. They needed a pristine dataset they could research off of, instead of feeding their work into the public-facing LLMs and trusting whatever came back. Or even worse, having the public LLMs train off of their data.
It was clear there was frustration with using even the best models on the max plans. Session memory drifted, hallucinations crept into the answers, and the analysts stopped trusting them. If you're a fund manager or an analyst whose job depends on the 100% accuracy of the data you're querying, anything even a shade dubious is not acceptable.
They recognised that themselves, which is why I'm involved with them at all. These are domain experts, very good at what they do. Over the weekend they broke down the problem, researched the platform options, and sent me a proposed architecture. All of it is work they can do on their own, and most of it is work they can do better than I can. The best thing for the system, and for the relationship, is for me to get out of their way on writing the fat skills. This is not work I should be doing. If they ever ask me to get involved with it, I will push back. I never want to be the bottleneck on things they can do better than me. The fat skills are how they put their domain expertise on paper, and how we keep ideas going together. The system loses something the moment I start touching them.
Where I come in. Managing the thin harness, which is the technical part. The part fund managers don't want to do, and shouldn't be doing. Managing how the harness is accessed and how it grows. Managing the security posture and making the system behave the way they want it to. If there's a RAG pipeline to be built, finding the right person to build it and making sure it ships safely. This is where my twenty years of software background does the work. The technical expertise sits next to their domain expertise, not on top of it.
Three layers, not two. The platform vendor compounded ten years of engineering into a sandbox with connectors and a browser. The client compounded fifteen years of investing into a philosophy with letters and case studies. Both ends are fat. The middle layer is small, and it's the only thing my job actually is. A markdown file that loads the philosophy on every task. A folder convention. A calibration CSV. A feedback loop that gets smarter every week. That's the harness. It's nothing. It's everything, but managing it securely and safely is not something a client should be doing.
The handshake is simple enough that I can put it in one paragraph. They never tell me how to wire an OAuth scope. I never tell them how to read a 10-K. The golden dataset is where our jobs meet. They declare what it is. I load it. The day either of us crosses that line, the system gets worse.
Day 18 was the post about the framework. Day 37 is the post about the proof. I had been hoping for an example to put alongside the theory. I didn't expect it to arrive at 5:21am, written by the client himself.
Scoreboard. Day 37 of 365. One enterprise client running the architecture live. Proposal due Monday end of day. The fat skill at the top is theirs. The fat skill at the bottom is the platform's. The thin harness in the middle is mine.
Revenues $11,800 Clients 2 Prospects 1 Employees me