The Only-Me List.

Earlier this year I wrote up how I'd automated the administrative half of my job. Reading it back now, I can see what I actually described: a small municipality, with a ledger.

All of it is still true. I dictated my whole job into a chat window, ums included, and three hours later had eighteen small written instructions working over a handful of markdown files. A compass for the quarter. A commitments list for the month. An append-only log for the day. A register of every decision we'd settled, including what we'd ruled out. And a meta-skill whose only job was to design future skills against a maintained map of the system. I designed it with a frontier model in one morning and ran it on a modest one. I was pleased with it.

“Pleased” undersells it a little. I drew three architecture diagrams.

I've come to think it was the wrong place to start. It was too complicated and too advanced, and the problem wasn't that readers can't handle a markdown file. The piece answered the how before it had asked the what. It explained in some detail how to build the engine and never asked where you wanted to drive.

That's a little embarrassing, because the lesson I lean on most is exactly that one: hold people accountable for the what, and let them own the how. I'd skipped your what and handed you my how.

So this is the rewrite. It keeps the machinery, but only a fraction of it, and the first page is different. The first page is about you.

Now the machinery, and only now. I'll keep it light. This is the third of three pieces: The Open Hood was about why understanding the gears beats speed, and The Agentic Nephew goes properly under the hood of the systems. Here you need three parts and a key ring.

The manual, the clock and the log

A skill is your steps, written down as a manual. The model reads the same instructions every time it does that job, so it doesn't reinvent your way of thinking from scratch on every run. The one rule I'd carry over from the old piece is to write each skill as a clerk, not a thinker. It gathers, sorts, tags and formats. It doesn't decide. The prompt can say so in as many words: you are a clerk; you do not interpret. The interpreting is the swing, and the swing stays with you.

A loop is your recurring question, on a clock. It's the thing you'd ask every Monday if you weren't in back-to-back meetings every Monday. A schedule fires, the model rereads its memo (what you're working on, what to look for) and runs the skill against whatever is new. A good question you ask when you happen to remember is one thing. A good question that reliably gets asked is another.

A log is the running record of what was found and decided. It's one file. Every run appends what it saw, dated and tagged with the item on your list it belongs to. That tag does more work than it looks: a modest model rolls up tagged entries reliably, and where it stumbles is inferring connections across untagged free text. The log is also what makes the loop a loop. Next week's run reads last week's findings, so the question gets sharper each time instead of starting from zero.

The key ring is your workspaces and connectors. They decide where the work happens and what it's allowed to open: the mail, the CRM export, the meeting transcripts, the dashboard. Hand over the keys the job needs and not one more. A folder per job is a perfectly respectable workspace.

If I could keep only one sentence from the old article, it would be this one: the files are the API. The skill, the loop's memo and the log are plain documents you can read from start to finish. The parts never talk to each other directly. They read and write those files. That keeps the whole thing checkable, and it makes it portable. I designed my first version with a frontier model in one morning and ran it on a modest one, because once the thinking is written down, the daily work is clerk-sized. When the system prioritizes the wrong thing, you don't engineer a prompt. You correct a file with a pencil.

That's the whole kit. There's no compass, no commitments register, and no meta-skill designing other skills. I built all of those, and for most people reading this, they're the municipality. Start without them.

Do better before you do more

This next part interests me more than the plumbing, and it's what happens once the kit works. You get an overflow. Questions that used to take a week and an analyst come back by Tuesday morning. You can see more of the business, in more detail, than you could before, and the obvious temptation is to do more with it: more questions, more initiatives, more dashboards about the dashboards.

My rule for that moment is do better before you do more. Spend the overflow on depth first, on the quality of the decisions you already make and on a strategy that's actually informed by what's going on. Only then spend it on volume. It's the multiplier argument turned on yourself: spend the new capacity on what compounds, not on doing the same things more often.

To see why depth is now on the table, it helps to look at why it wasn't.

As an organization grows, its executives get distillates. Each time a piece of information travels up, it passes through another layer of abstraction. The account becomes a segment, the segment becomes a region, the region becomes a slide, and the slide becomes a traffic light. Those layers exist for one reason, and it isn't vanity: no executive can make decisions on that many detailed elements. Compression was the price of scale.

Now look at what many leaders are doing with AI. They're building new intermediary layers: summaries of the summaries, a digest of the weekly reports, which were already digests of the team updates, which were digests of the work. It's genuinely faster. It's also the old shape, automated.

So here's my challenge, and I'll own that it's a provocation: why keep those layers at all? They were compensation for a limit, the executive's bandwidth for detail, and that is precisely the limit the tools now lift. If your models and connectors are set up properly, the detail is at your disposal. You can ask a spot question about one customer segment. You can ask what was actually said in this meeting, and in that one, rather than reading the three bullets someone remembered.

I want to be precise about what removing a layer means here, because it's easy to hear something else. I mean removing a reporting layer: the summary, and the distillation it exists for. I don't mean the people who write it. Those people were never valuable because they could compress forty accounts into one traffic light. That compression was the beat, and a machine keeps a steadier beat. They were valuable because they knew which account was about to go quiet, and why. That's the swing. It's also the first thing you lose when the people closest to the work spend their week reformatting what they know into something you can skim.

The pricing question

The clearest example I have is pricing.

The old question is does our pricing strategy work? Look at what it assumes: one strategy, held across thousands of customers, judged on an average. That question is a product of the layers. It's the shape a question takes once the detail has already been compressed out of it.

The new question is for which customers is my price not working, and should I change it for them?

The intent is the same, but the resolution is different. The abstraction collapses and the question gets sharper. A sharper question also leads somewhere. It ends in a decision about specific customers, based on evidence about those customers, instead of a debate about an average that none of them actually pays.

Meetings work the same way. How did the quarterly reviews go? becomes in which reviews did a customer raise the same objection, and what did we say back? You aren't asking more questions. You're asking the same question at a higher resolution.

“Here is a question I ask at the level of the whole business: [your question]. Rewrite it so it can be answered for specific customers, accounts, segments or meetings. Then tell me which data you'd need to answer it, and which of those sources you can actually reach.”

One honest caveat, because this section could easily read like a brochure. Detail isn't free. Without a good question, it's just noise at a higher resolution. A confident spot answer about one segment can also be wrong in ways a summary would have smoothed over, so check the sources before you reprice anyone. Not every layer is pure compression, either: some carry judgment, shared language and accountability, and those are worth keeping. And there's a sharper risk, the one I watch most closely in myself. An executive who can see everything is an executive tempted to manage everything.

Which brings us to the people.