Issue #22 · Ops & Om · Health of Business
I'm building an outreach agent for my own company right now. It isn't finished, and I already know it gets built at least four more times. A version that books podcast guests. A version that chases wholesale accounts. Two more I haven't met yet.
What's interesting is that I can already see the second version while I'm still building the first. That changes what I write down today.
Last issue I told you about fifty-something folders and one subject-line rule living in fourteen places. That was a cleanup story: how to fix a setup that already sprawled.
This is the other end of the same problem. The cheapest moment to never have it is the thing you're building this week. Nobody consolidates their way to a good system twice.
You don't discover the reusable part later. You write it on the way in.
Here's what we'll cover in this issue:
You Can See the Second One From Here
The tBG outreach agent is a specific build. Connected tools, a way of finding people worth talking to, rules for what a good target looks like, a follow-up cadence, and a definition of when to stop.
Sit with that list for a second, because it splits cleanly down the middle.
What's specific to my company: who we're going after, what we say to them, what we're offering, the things that would be wrong in anyone else's mouth.
What isn't specific to anything: how you qualify a target. How you sequence a follow-up. How you decide a lead is done. When to stop.
Swap the target list and the pitch and the same machine books podcast guests. Swap them again and it's chasing wholesale accounts. The plumbing doesn't care what it's pointed at.
That's the part worth noticing on day one. The reusable half is visible the first afternoon, if you're looking for it. You don't have to wait until month six to find out. I'm not guessing that it transfers. I can name two other versions right now, and I haven't finished the first.
Which makes the next question uncomfortable. If I can already see it, why would I write it somewhere only one project can reach?
Ask for the Skill While You're Asking for the Project
Here's how almost everyone sets up a new project, me very much included until recently. You write the instructions into the project. All of them. The client-specific stuff and the how-the-job-works stuff, one pile, one place.
It feels responsible. It's how you end up with fourteen copies.
So on this build I changed what I ask for. When I sit down to have Claude write the project instructions, I don't ask for the project instructions. I ask for both: the brief for this specific build, and the separate reusable pieces that fall out of it.
That's the whole move. Not a new tool or a new workflow. Just a different sentence at the start.
Try this prompt:
I'm setting up a new project: [describe the build in a few sentences].
I expect to build variations of this for other clients later,
for example [name one or two realistic variations].
Give me two things, separately:
1. PROJECT INSTRUCTIONS. Only what's true about THIS build.
The specifics: who it's for, their offer, their terminology,
their links, the one weird thing about how they operate.
2. SKILLS. Each reusable procedure as its own standalone piece,
written so a different project could use it without editing.
No names from this build inside them. Where a skill needs a
specific detail, make it a named input the project supplies.
For anything you can't confidently place, list it under UNSURE and
tell me what makes it ambiguous. Don't force it.What comes back isn't finished. It's a starting split, and it's roughly right, which is far better than one pile.
The Test, Before There's a Second One
Last issue's sort was retroactive: read a line and ask whether it's true about the client or true about the job. That works because you already have six folders to compare.
On day one you don't have anything to compare. So the test is a question about the future instead:
If I built this again for somebody else, would this line survive?
Survives untouched → it's a skill.
Survives if you swap a name or a number → it's a skill, and the name is an input the project hands it.
Doesn't survive → it belongs in the project. That's what a project is for.
Now the part that keeps this from going wrong. Run at it too hard and you'll abstract everything on day one, including steps you don't understand yet. A reusable procedure built out of a guess is worse than a duplicated one, because now the guess is installed in every project you make.
So I hold myself to one rule on a new build: I don't write a skill for a step I haven't run at least once. Anything I haven't actually done stays in the project as a note. It gets promoted after it survives real work.
Map the whole thing, build exactly one, run something real through it. Same discipline as last issue. Just earlier, and a lot cheaper.
Same payoff I was chasing when I tore fifty folders down to pointers, except I'm not paying for the teardown this time. Follow-up sequencing is the part I'm worst at. When I get better at it, I get better at it in every outreach agent I've built. Same afternoon. Without remembering where I wrote it down.
Want to see one that's already written to travel?
The free Email Triage Agent Kit is this, finished. Instructions, setup, architecture, every prompt, written so somebody who isn't me can run it without rewriting it first. Take it apart and look at where the specifics live versus where the procedure lives. That split is easier to see in something built than in something described.
Building something right now that you already know you'll build again? Reply and tell me what the second version is. That answer usually tells you what to pull out.
Baldomero Garza — Find me on X, LinkedIn, Instagram, or book a 1:1.
If you found this issue helpful, please forward it to a friend or colleague who might benefit from it. Sharing is caring!
Did someone forward you this issue? Don't miss out on future insights — subscribe to the Ops & Om newsletter here!