Every company AI project starts with the same wrong question: "which model should we use?"
That's like starting a hiring decision with "which college did they go to." It matters a little. It's not the decision.
The decision is architecture. Specifically, what does the AI think with, and what does it act with? Get this split right and you can swap models for years without rebuilding anything. Get it wrong and you've welded your business to whatever API was trendy the month you started.
I run my entire marketing operation on an AI system I built. Posting, outreach, follow-up, measurement, reporting. It runs while I sleep. This track is the honest write-up of how, including the parts that took three tries. Chapter one is the shape of the thing.
The brain and the body
Here's the model I have convinced myself is right, after running it in production:
The brain is rented. The body is owned.
The brain is a frontier model. The thing that writes, reasons, plans, and makes judgment calls. I use Claude, through a consumer subscription. Not the API. A subscription is a fixed monthly cost; an API is a taxi meter attached to your most talkative employee. For a one-operator business, the subscription does the same reasoning work at a price that never surprises you.
The body is everything else, and the body is the actual asset:
- A scheduler that runs ~40 jobs a day whether or not anyone's paying attention
- Databases for contacts, content, telemetry, memory. Ours is 21 separate SQLite files, one per domain
- Tools, meaning small Python programs that do exactly one thing each: post to LinkedIn, read an inbox, score a lead, collect engagement numbers
- Memory, episodic records of every contact and every action. That gets its own chapter because it's the part everyone gets wrong
- Guardrails: approval queues, rate envelopes, kill switches. Also its own chapter, because we earned that one the hard way
The body doesn't think. The body executes, records, and enforces. The brain thinks, and the brain is replaceable. When a better model ships next year, I swap the brain and the body doesn't notice. My data never moves. My tools never change. The thing I own compounds. The thing I rent stays current.
Why not just use an agent framework?
If you've researched this at all, you've hit the framework aisle. LangChain, LlamaIndex, CrewAI, AutoGen. Multi-agent swarms. "Crews" of AI employees with job titles.
I think frameworks are how engineers procrastinate on understanding their own problem. That's an opinion, so here's the fair version of each:
LangChain / LlamaIndex are libraries for chaining model calls and retrieval. Genuinely useful if you're building a product with RAG at its core. For a company AI, they hand you abstraction layers you'll spend weeks debugging through. When something misbehaves at 2am, you want a stack trace that ends in your own code, not in someone's Chain.
CrewAI / AutoGen sell the multi-agent dream, where a researcher agent talks to a writer agent who reports to a manager agent. It demos beautifully. In production, you've built a meeting. The failure mode of one agent becomes the input of another, and nobody can tell you why the system did what it did. I run one brain with many tools, not many brains with one hope.
n8n / Zapier with a model node is real glue and I'd recommend it for workflows that are genuinely linear. Form comes in, summary goes out. It gets ugly when state matters, when today's action depends on what happened to this specific contact over the last ninety days. Workflow tools don't want to own state. A company AI is mostly state.
All-local (Ollama everything) deserves respect because it's the only option where nothing leaves your building. We run local models for bulk work, drafts and classification and summaries, because the marginal cost is zero plus electricity. But we learned in public that local models at this size will invent things and sound completely sure of them. One of ours fabricated client case studies and published two of them before the system caught it. The fix wasn't a better prompt. It was a mechanical gate that checks every number in generated content against source material. Local models are labor. They are not judgment.
The pattern under all four: every alternative either rents the body along with the brain, like the frameworks and the no-code glue, or promotes labor to a judgment job, like all-local. The split keeps you on the right side of both mistakes. Rented judgment, owned execution.
What this looks like on an actual Tuesday
06:15, the body exports its own state to flat files so the brain can read everything instantly when it wakes up.
07:30, contact sync pulls new people into the CRM, in resumable batches, because the full walk is 157,000 contacts.
07:55, the drip engine researches a shortlist of prospects, drafts personal emails in my voice, sends within a daily cap, and bumps anyone who didn't reply to the last one. Politely. Twice, max.
08:00 to 09:45 is the content cycle. The day's posts move through generation, a fabrication check, an approval queue, and envelope-checked dispatch.
16:10, inbox triage reads replies, matches them to CRM records, and turns "interested" into a hot lead before I've seen the email.
18:30, the collector pulls engagement numbers on everything posted, so tomorrow's plan starts from yesterday's evidence.
Sunday, the system reviews its own week, scores the hypotheses it was running, and adjusts within hard limits.
None of that is the brain being clever. It's the body being reliable. The brain's job shows up in the gaps. What to write, who's worth a follow-up, which hypothesis to run next week. Call it ninety minutes of actual judgment a day, which is the point: judgment is the expensive part, so the architecture spends it carefully.
The test before you build anything
Write down your answer to one question. If your model provider doubled prices or halved quality tomorrow, what would you keep?
If the answer is "nothing," you were about to build on the wrong side of the line. If the answer is "the schedule, the data, the tools, the memory, the guardrails," you understood the assignment.
The rest of this track builds the body one system at a time. The stack, the scheduler, memory, the training loop, guardrails, and the build-vs-buy math. Real configs, real failures, real costs. Bring an engineer or be one.
