People hear "AI-powered business" and picture some kind of science fiction dashboard. Robots doing everything. Or they picture the opposite: someone typing into ChatGPT all day and calling it a system.
What I've actually built is closer to what a well-run construction office looks like. There's a filing system. There are job folders. There's a superintendent who checks on every active site each morning. There are standard operating procedures for how new projects start, how work gets scoped, and how things get handed off. The difference is that most of those roles are played by AI — and the filing cabinets are plain-text files on my computer.
I want to walk through what this looks like in practice. Not to sell anything, but because I think the shape of this system is useful for anyone running a multi-project operation — whether you're managing construction sites, client accounts, or rental properties.
The job folders
Every client gets a workspace. Think of it like a job folder in a general contractor's office: everything related to that project lives inside it. Scope documents, deliverables, meeting notes, project context. Nine clients, nine folders. Internal projects get their own separate folders too.
At the top level, there's a routing table — a single document that tells any AI tool exactly where to go and what to read before touching anything. If someone says "work on the Fio project," the AI knows to go to the Fio folder and read the context file first. If someone says "draft a proposal," it knows to grab the template and customize it in the right client folder.
This sounds simple. It is simple. But it solves an enormous problem: context bleeding. Without this structure, AI tools mix up clients. They use one client's voice in another client's work. They reference the wrong project history. The routing table is a one-page document that prevents all of that.
Imagine if your superintendent showed up to a job site and couldn't tell which set of plans belonged to which project. That's what it's like when AI tools don't have workspace separation. The routing table is the labeled plan rack.
The superintendent
His name is Gabe. He's an AI executive assistant, and he runs on a schedule — not when I remember to ask him something, but automatically, four times a day.
Morning briefing at 8:03 AM. Gabe scans my email from the last 30 days, checks all nine client workspaces for recent activity, and reviews every open task. He assembles a briefing: what's due, what's waiting on someone, what changed overnight, what I should prioritize today. He sends it to me by email, text, and our internal channel. I read it with coffee.
Hourly check-ins, 9 AM to 5 PM. This is the part people find surprising. Every hour, Gabe checks whether I've been working — did I send any emails, push any updates, close any tasks? If yes, he logs what he sees and stays quiet. He trusts me to do my work. If nothing's happened in the last hour and there's a priority item he hasn't asked about yet today, he sends one short question: "What are you working on right now?" Not nagging. Not a surveillance system. More like a superintendent walking the site once an hour and only flagging you if the crew's been idle.
Evening wrap-up at 5:32 PM. Gabe reviews what got done that day, archives completed tasks, and refreshes the live task list for tomorrow.
Daily audit. Separately from the check-ins, Gabe audits each client workspace for anything that's changed significantly — a new email from the client, major project updates, shifted timelines. If something contradicts what we had on file, he updates the context. If not, he leaves it alone.
Gabe doesn't decide things. He surfaces information, asks questions, and keeps the filing system current. The judgment calls are still mine. That's not a limitation — that's the design.
Why the schedule matters
Most people use AI reactively. They open a chat when they have a question. That's the equivalent of only calling your superintendent when there's already a problem on site.
The scheduled routines flip that. Gabe doesn't wait for me to remember to check on a client. He does it every morning regardless. He doesn't wait for me to realize I've been stuck on something for three hours. He notices after one hour and asks. He doesn't wait for me to review the day. He wraps it up at 5:32 whether I'm paying attention or not.
This is the difference between an AI assistant and an AI system. An assistant answers when asked. A system operates whether you're watching it or not. The scheduled routines turn AI from a reactive tool into operational infrastructure.
How new work gets scoped
When a new project comes in — whether it's a client engagement or an internal tool I want to build — it goes through a structured discovery process I call the spec workflow. Four phases, each with a clear input and output.
Phase 1: The big picture. I write a rough description of what we're trying to build and why. The system researches comparable products, identifies risks, and produces a one-page summary: what the project is, who it's for, what the major pieces are, and what could go wrong. Think of this as the feasibility study.
Phase 2: How it works. For each major piece identified in phase one, the system maps out the step-by-step workflows. What does a user actually do? What screens do they see? What happens when something goes wrong? This is the equivalent of a detailed set of construction drawings — not just "build a kitchen," but "cabinet layout, plumbing runs, electrical placement, appliance specs."
Phase 3: The technical plan. Now it gets specific. What tools will we use? How long will each piece take? What depends on what? What's the order of operations? This is the construction schedule — foundations before framing, framing before mechanical, mechanical before drywall.
Phase 4: The task list. Phase three's plan gets broken into individual tasks, each one specific enough that someone (or some AI agent) can pick it up and execute it without asking clarifying questions. This is the punch list — but written before the work starts, not after.
Every phase has a human checkpoint. I review the output, make corrections, and sign off before the next phase runs. The system proposes; I decide.
Without the spec workflow
- Scoping is ad-hoc, inconsistent across clients
- Important requirements surface mid-build
- Estimates are gut-feel, hard to defend
- Scope creep starts on day one
With the spec workflow
- Every project follows the same four-phase discovery
- Risks and requirements surface before a line of work ships
- Estimates are grounded in a written technical plan
- Client sees exactly what they're getting, in writing, before it starts
The task runner
Once the spec workflow produces a task list, something has to execute those tasks. I built a tool called Strider for this — a lightweight system that lets AI agents pick up tasks, work on them in isolation, and deliver results without stepping on each other's work.
Think of it like a job board on a construction site. Each task is a card on the board. An agent takes a card, does the work in its own space (so it can't accidentally mess up someone else's work), and puts the result back when it's done. I review the result, approve or reject it, and the board updates.
The whole thing runs on plain-text files. No special software. No database. No subscription. The task board is a set of folders. The task descriptions are documents. Moving a task from "to do" to "in progress" is literally moving a file from one folder to another. It's the simplest thing that could possibly work, and that simplicity is the point — I can see everything, change anything, and nothing breaks if a tool goes offline.
Skills: the SOPs
In any well-run operation, you have standard operating procedures. The new hire doesn't figure out how to do an inspection from scratch — there's a checklist. The estimator doesn't reinvent the bid format every time — there's a template.
I've built the equivalent for AI. They're called skills — reusable procedures that encode how specific tasks should be done. Some are client-specific: how to capture compliance screenshots for a property management client, how to export billing reports from a particular system. Some are general: how to run a morning briefing, how to execute a spec phase, how to break down a project into tasks.
When I say "run the morning briefing," the AI doesn't improvise. It follows the morning briefing procedure — the same steps, the same checks, the same output format, every time. Consistency isn't a nice-to-have in operations. It's the whole game.
Proposals, contracts, and estimates
If you've ever run a contracting business, you know the paperwork problem. Every new client needs a master agreement. Every project needs a scope of work. Every scope needs a fee schedule, a timeline, deliverables, acceptance criteria, and an out-of-scope section that protects you from creep. Writing all of that from scratch every time is slow, inconsistent, and error-prone.
I solved this the same way a good GC solves it: standard forms. I have a master services agreement template and a statement of work template. They cover everything — payment terms, liability caps, IP ownership, warranty periods, termination clauses, governing law. All the boilerplate that needs to be right every time but shouldn't require a lawyer every time.
When a new client comes on, the AI copies the master agreement template into that client's folder and fills in the blanks: client name, contact info, effective date. When we scope a project, it copies the statement of work template and populates it with the deliverables, timeline, and fee structure from the discovery work we already did in the spec workflow. The spec phases feed directly into the estimate — if phase three produced a technical plan with time estimates for each piece, those numbers flow right into the scope of work.
The templates themselves never get modified. They're the master copies. Every client gets their own filled-in version, stored in their own folder. If I need to update the standard terms — say, I change my warranty period or add a new clause — I update the template once, and every future engagement picks it up automatically. Existing contracts are untouched.
Before this system, a proposal took me most of a day: researching the client, writing scope, drafting terms, formatting the document, reviewing for mistakes. Now the discovery-to-proposal pipeline takes about an hour. The spec workflow handles research and scoping. The templates handle legal structure. The AI handles assembly. I handle judgment calls — what to include, what to price, what to flag as risky.
One master agreement gets signed at the start of the relationship. After that, each new project is just a new statement of work — a shorter document that references the master agreement and defines the specific engagement. A client I've worked with for a year might have one master agreement and four or five statements of work underneath it. Clean, organized, and every one built from the same standard form.
This matters more than people think. Inconsistent contracts create confusion. Forgotten clauses create liability. Starting from scratch every time means every proposal is a chance to make a new mistake. The templates eliminate that entire category of risk — not by being clever, but by being consistent.
What this actually looks like in a day
Here's a typical Tuesday.
7:45 AM. I'm making coffee. My phone buzzes with Gabe's morning briefing. Two clients have emails waiting for responses. One project has a deadline this week. One task from yesterday didn't get finished. There's a payment notification I need to acknowledge.
8:15 AM. I sit down and work through the priority list. I respond to the client emails. The responses are drafted in each client's workspace, so the AI already knows the project context, the client's communication style, and what we discussed last time. I'm editing, not writing from scratch.
10:07 AM. Gabe's hourly check-in runs. I've been sending emails and updating tasks. He logs the activity and stays quiet.
11:07 AM. Another check-in. I've been heads-down on development work for the past hour — Gabe sees the activity and logs it. No interruption.
1:07 PM. I got pulled into lunch and errands. Nothing happened in the last hour. Gabe asks: "The Alive in You deadline is Thursday — are you blocked on anything?" One question. Specific. Useful. I reply and get back to work.
3:00 PM. A new lead comes in. I start the spec workflow. Twenty minutes later I have a one-page project summary and a risk assessment. I tell the AI to draft a proposal — it pulls the master agreement template, fills in the client's info, generates a statement of work from the spec output, and hands me a complete package to review. What used to take most of a day takes about an hour, and the terms are consistent every time.
5:32 PM. Gabe wraps the day. Three tasks completed, one rolled to tomorrow, client context files updated where needed. The task list is clean for tomorrow morning.
What I'm not claiming
I'm not claiming this replaces hiring people. When a project needs a specialist — a designer, a domain expert, a second pair of hands — I bring them in. AI doesn't replace expertise. It replaces the operational overhead that keeps me from using my expertise efficiently.
I'm not claiming this is easy to set up. It took months of iteration to get the routines, the workspace structure, and the SOPs to a place where they run reliably. The first version of Gabe was annoying. The first version of the spec workflow produced documents I had to rewrite entirely. The current versions are the result of continuous refinement.
And I'm not claiming this is the only way to do it. This is one person's system, built for one person's business. The specific tools will change. The specific routines might not fit your operation. What I think is transferable is the shape: structured workspaces, scheduled routines, standardized procedures, and human checkpoints.
This system makes me fast, organized, and consistent across nine clients. What it doesn't do is think for me. Every client decision, every creative judgment, every "should we do this?" still requires a human sitting in the chair. The system surfaces information and executes procedures. The strategy is mine.
Why plain text
People ask why the whole system runs on plain-text files instead of some kind of app or database. The answer is durability.
Apps get acquired. Databases need hosting. Subscriptions get discontinued. File formats go obsolete. But a folder full of text files? That works today, it worked twenty years ago, and it'll work twenty years from now. Any tool can read them. Any person can read them. If every AI tool I use disappeared tomorrow, I'd still have a perfectly organized filing system with every client's context, every project's history, and every procedure documented.
That's not an accident. When your entire operation depends on a system, the last thing you want is for that system to depend on a single vendor.
What this means for you
You probably don't need my specific system. But if you're running a multi-project operation — managing job sites, client accounts, properties, whatever — and you're either not using AI or using it in the vending-machine way I wrote about before, the gap between where you are and where you could be isn't a technology gap. It's a structure gap.
The model is already good enough. What it needs from you is the same thing a new superintendent needs on their first day: a tour of the office, a set of labeled job folders, the standard procedures, and a clear understanding of when to act and when to ask.
Give it that, and you'd be surprised how much of the operational weight it can carry.
Field notes
I've been running this system in production — real clients, real deadlines, real money — for about eight months now. The things that work are the things I described above. The things I'm still figuring out are the edge cases: what happens when two clients need urgent attention simultaneously, how to handle context that changes faster than the daily audit catches it, and how to onboard a collaborator into a system this idiosyncratic. It's a work in progress. The best systems always are.
R.P.