Method / operating doctrine
AI in production: it's a matter of method.
The right stack is People → Workflows → Agents → Infrastructure, in that order. Every principle below comes from a real case, told in the runs and the essays.
Spend the strongest model on decisions
Every day I orchestrate Claude Code and cheaper agents. When a delegation leaves a gap, the worker fills it with an architecture choice nobody made. So I delegate only work where every decision is already made, and I use the most capable model to decide and for the final review.
Start from what experts don't ask for
Condominium managers asked for accounting. Faced with concrete problems, they chose repairs, suppliers and communications. People who have done a job for years ask to automate the steps they can see, and the most expensive ones are those that became habit. At every first meeting I ask: what would change your life that we treat as impossible?
Knowledge becomes true when a person approves it
Three attempts to collect client knowledge in hand-filled presentations stalled for the same reason: nobody owned keeping them current. In the company brain Yempik runs on, agents, emails and meetings propose, and a person approves. Every item says how certain it is and who decided it.
Redesign the work around one person and their tools
Turning the org chart into software produces the same steps, faster. I start from one person who knows the work and today's AI tools, keep their quality standard and rebuild the steps from scratch. It's the difference between a system of record, which records, and a system of action, which moves the work forward.
The expert's standard lives in tests
A review after the fact tells you whether today's output was good. Tests on real cases, repeated several times, tell you whether tomorrow's will be. When a model assesses people, the model prepares and explains, and the outcome is computed by rules the trainer knows, so every outcome can be rebuilt step by step.
I own the harness and the checks; the model gets swapped
Tools, rules, tests and observability are mine. Rules that must always hold live in the code that runs each action, where the model can't interpret them: in a WhatsApp job-application agent, an action that looked like account maintenance actually opened access to the account. I switch models when my tests say it pays off.
Start from work that matters, and measure what leaves the old system
The first project is a task that costs weeks today and has a clear way to tell whether it's done well. Then I measure how much work actually leaves the old system: an email the agent handled that still sits unread in the firm's inbox is doubled work.
AI is worth most on work nobody used to do
A colleague who doesn't write code built small skills for her repetitive tasks. The biggest value was an anomaly the skills flagged, a partly returned order, that nobody would have looked for by hand. Used only to cut costs, AI squeezes the margin. Used to do new work, it widens it.