How I would start today

One procedure. Written down properly. Verified every single run. The second one only after the first survives a week without me rescuing it.

If I lost everything tomorrow and started this again, I would not start with a platform, a stack, or an org chart of twelve agents with job titles. I would start with one procedure, and I would be almost embarrassingly slow about the second one.

Here is the sequence, in the order I would actually do it.

Do not start with the architecture

The temptation at the beginning is to design the whole company: the roles, the handoffs, the diagram with boxes for marketing and support and finance. It feels like progress because it produces artifacts. It is not progress, because you are designing a system for work you have never once run this way.

Every part of my architecture that survived was discovered by running something and watching it break. Every part I designed in advance got deleted.

Pick the first procedure

The right first candidate has four properties. Insist on all four, because the whole point of the first one is that it teaches you the loop without punishing you.

• It repeats. Weekly at least. A one time task teaches you nothing about running a company on procedures.
• You already know how to do it. You cannot document a process you have not performed. If it is fuzzy in your head, it will be fuzzy in the file, and the agent will fill the gaps with invention.
• Failure is visible and cheap. Something you would notice immediately and could fix in an hour. Not billing. Not anything that reaches a customer unreviewed on day one.
• Checking is faster than doing. This is the one people skip. If verifying the output takes as long as producing it, you have not saved anything and you will quietly stop verifying, which is worse than not starting.

A weekly report you assemble by hand. A recurring research pull. A publishing routine. Something boring you have done thirty times and would rather never do again.

Write it down properly

This is the actual work, and it takes longer than doing the task once by hand. That is fine. You are not writing instructions for today, you are writing the thing the company keeps.

A procedure that an agent can run has to answer all of this, in writing:

• What starts it. A schedule, an event, a request. Say when it should run and when it should not.
• What it needs. Inputs, sources, access, where each thing lives. Assume the reader has never seen your setup, because it has not.
• The steps. In order, in plain language, with the decisions made explicit. Where you would use judgment, write down the rule you actually apply, and if you cannot articulate it, that step stays yours for now.
• What done looks like. A description of a correct finished output, specific enough to compare against.
• The checks. What must be true before this counts as complete. Ranges numbers should fall in. Things that must never appear.
• What to do when it fails. Stop and report, or retry once, or fall back. Say which. Silence on failure is the default otherwise, and silence is the expensive one.
• What not to do. The boundaries. Nothing spent, nothing sent, nothing deleted without a person.

Write it for a reader that is capable, literal, tireless, and has no memory of yesterday. Every unstated assumption in your head is a place where it will invent something plausible and wrong.

Verify every run, at first completely

For the first stretch, read all of it. Not a sample. The entire output, every run, alongside the procedure, asking one question: is this what I would have produced?

This feels like it defeats the purpose. It does not. You are not saving time yet, you are calibrating. You are finding out where your document was vague, where the model filled a gap, and where your own standard was never written down anywhere.

Keep a running log of corrections. Two columns is enough: what was wrong, and what should have happened. That log is the raw material for everything that comes next, and it is the artifact I most regret not keeping from day one.

Turn corrections into rules

Here is the loop that makes this compound.

A correction that happens once is noise. A correction that happens twice is a missing sentence in the procedure. So the second time you fix the same thing, do not fix the output. Fix the document, and then, when you can, move the rule into a check the system runs on itself.

Prose advises. Code constrains. Anything that must never happen belongs in a check, because your attention will eventually be somewhere else, and a check will not be.

Do this consistently and the procedure gets quieter every week. The corrections get rarer and more specific. That curve is the signal you are looking for, and it is more informative than any single run.

The survival test before you add the second one

The rule I hold myself to: the first procedure runs for a full week, on schedule, without me stepping in to rescue it. Not one save. If I have to fix an output mid week, the clock resets.

Only after a clean week do I write the second procedure.

This is the discipline everyone skips, including me, more than once. It is tempting to have five things half working because five feels like a company and one feels like a hobby. Five half working procedures is not a company. It is five sources of silent failure and no capacity to notice any of them. One that genuinely runs without you is worth more than all five, because it is the first piece of the thing that keeps producing when you are not there.

What the first month looks like

Roughly this, and slower than you want.

• Week one. Pick the procedure. Write it. Run it. Read everything. Correct a lot.
• Week two. Rewrite the procedure using what week one taught you. Most of the corrections were your document being unclear, not the agent being careless.
• Week three. Add the checks. Make failure loud. Try to break it deliberately: bad input, missing source, empty result. An empty result that looks like a success is the classic quiet killer.
• Week four. If it survived a clean week, start the second procedure, and write it faster because you now have a template. If it did not, you are still on the first one, and that is the correct place to be.

One good procedure at the end of a month sounds like nothing. It is the whole method in miniature, and the second one takes a fraction of the time.

What I would avoid

• Twelve agents on day one. Handoffs multiply failure. Small chances of failure compound fast when you chain them, and you cannot debug a chain you never verified a link of.
• Tool sprawl. Every new tool is another thing that breaks, expires, and changes shape. Fewer things working reliably beats many things working sometimes.
• The undocumented prompt. The clever instruction living in someone's head or scroll history is exactly the knowledge loss you were trying to escape. If it is not in a file, it does not exist.
• Judging by vibes. "It seems to be working" is not a check. Decide in advance what correct looks like, and compare against that.
• Skipping the boring documentation to get to the interesting automation. The documentation is the automation. Everything else is a runtime detail.

Where it goes

After a while you have a folder of procedures that run, checks that shout, and a log of everything the company has learned about doing its own work. That folder is the company. Sessions end, tools change, models get replaced. The folder stays, and the next thing you plug in reads it and gets to work.

At that point the interesting question becomes how much of the work would actually stop if you turned the agents off, which is the removal test, and what you should never hand over in the first place, which is judgment, taste, direction, and the final gate.