The capability boundary: what to automate vs. keep human
Before you build a single AI worker, there is a decision that matters more than which model you use, how clever your prompts are, or which framework you pick: where does this task belong? Some work AI can do reliably. Some it can only assist with. Some must stay human. Draw that line in the wrong place and everything downstream — the reliability, the economics, the trust — is built on sand. Draw it well and the rest of the job gets dramatically easier. This is the capability boundary, and placing tasks on it correctly is the most valuable skill in building a one-person AI company.
Placement is the skill; the model is the commodity
Almost everyone spends their attention on the wrong layer. They compare models, chase prompt tricks, argue about frameworks — the parts that change every few months. Meanwhile the decision that actually determines whether their company compounds or quietly fails gets made by reflex, in a sentence, with no rigor: "I'll automate this." The models are a commodity now, roughly interchangeable and improving on their own. The durable skill is knowing what to point them at. Most production disasters in AI are not a model failure. They are a placement failure — a task sitting in a column it never belonged in.
The three regions
Every task lands in one of three regions. The whole discipline is figuring out which — honestly, before you build.
- Reliably automatable. High-volume, well-specified work where a good answer is cheaply checkable and being wrong is cheap and self-correcting. Extracting fields from a message, categorizing a ticket, drafting a first pass. Build a worker; keep a light check.
- Assistable. The model drafts fast and a human decides. The output is useful but the stakes or the ambiguity mean a person must own the final call. AI as a force-multiplier on a human's judgment, not a replacement for it.
- Human judgment. Ambiguous, high-stakes, or accountability-bearing work where one confident mistake costs more than everything the automation saved. Firing a customer, a legal commitment, a sensitive apology, a five-figure refund. Keep a human at the gate; AI can prepare the ground, but it does not decide.
Notice the boundary is drawn per task, not per role or per industry. "Support" is not a region; the specific act of drafting a routine reply and the specific act of deciding a goodwill refund sit in different ones.
Four tests that place any task
You do not need intuition or a maturity model. Four fast questions place almost any task, and you can answer them in under a minute.
- 1Is a good answer cheaply checkable?Can you look at the output and quickly tell right from wrong — by eye or by code? If yes, you can safely automate it and catch the misses. If you cannot verify it without redoing the work, you cannot safely automate it, no matter how easy it looks.
- 2What does being confidently wrong cost?Not the average case — the bad case. A wrong subject line is cheap and self-correcting. A wrong bank detail, a wrong medical suggestion, a wrongly-cancelled account is not. The cost of the confident error, not the frequency, decides the region.
- 3Is it well-specified, or ambiguous?Clear inputs, a clear definition of "done", and a task that lives in the ordinary middle of the distribution can be automated. Genuinely ambiguous work — where reasonable people would disagree on the right answer — needs a human, because there is no fixed target to check against.
- 4Does it carry accountability or a relationship?If someone must own the outcome — a customer's trust, a legal obligation, a person's livelihood — that ownership cannot be delegated to a probabilistic system. The model can draft; a human signs.
The rule that resolves conflicts: the lowest answer wins
The tests will often disagree — a task looks cheaply checkable and well-specified, but carries real accountability. When they conflict, do not average them. The lowest answer wins. One "irreversible and unverifiable" beats three "seems easy." This single rule is what keeps the boundary honest, because the whole point is to protect against the confident, plausible error — and that error only needs one open door. If any test says "human," the task is at most assistable until you have evidence to move it.
There is an asymmetry underneath this rule worth internalizing. The cost of under-automating — a human doing a task a machine could have handled — is a bit of wasted time. The cost of over-automating — a confident wrong decision reaching a customer — can be a lost account, a legal problem, or a reputation you don't get back. The downside is not symmetric, so when you are genuinely unsure, place the task conservatively. You can always move it outward later; you cannot un-send the mistake.
Placing real tasks
The framework only means something applied. Here is the same solo business — take work in, do it, support the customer, keep the books — sorted honestly:
- Extract the structured details from an incoming request → reliably automatable. Cheaply checkable, well-specified, low cost to be wrong once. Build the worker.
- Categorize and route a support ticket → reliably automatable, with a light check. Wrong routing is cheap and self-correcting.
- Draft a reply to a routine question → assistable. Fast draft, human glances and sends — because tone and edge cases carry the relationship.
- Decide and issue a goodwill refund → human judgment. Accountability-bearing, and a confident wrong call is expensive. AI assembles the context; a person decides.
- Respond to an angry public one-star review → human judgment. Ambiguous, relationship-bearing, and the downside of a tone-deaf automated reply is severe.
- Reconcile the month's transactions → assistable at most. Checkable in principle, but errors are quiet and expensive; a human owns the final numbers.
Run your own list this way and something clarifies immediately: the reliably-automatable column is where your leverage is, the human column is where your risk is, and the fastest way to a company that compounds is to automate the first ruthlessly while refusing to automate the last.
The two ways people get it wrong
Misplacement runs in both directions, and both are costly.
Automating judgment. The dangerous error. Seduced by a good demo, someone hands a probabilistic system a decision that carries accountability — and it is confidently, plausibly wrong just often enough to do real damage. This is the error that makes the news: the agent that cancelled the accounts, the bot that promised the refund policy that didn't exist.
Refusing to automate the checkable. The quiet error, and more common than it looks. Out of caution or habit, someone keeps doing by hand the high-volume, well-specified, cheaply-checkable work that a worker would handle perfectly — leaving all the leverage on the table and staying the bottleneck in their own company. Under-automation doesn't make headlines, but it is why a lot of solo founders stay stuck doing a machine's job.
The boundary moves — but only on evidence
The line is not fixed. As you measure a worker and prove it handles a task reliably, you can move that task from assisted toward automated — narrowing the human's involvement to the genuine edge cases. But the direction of travel matters: the boundary moves outward on evidence, never outward on optimism. Start a task in the more conservative region, instrument it, and let measured reliability earn it a promotion. When in doubt, keep the human — and let data, not hope, be what eventually removes them.
Get this one skill right and the rest of building an AI company gets much easier, because you are only ever automating things you can trust and check, and only ever spending human attention where it actually changes the outcome. Get it wrong and no amount of model quality, prompting, or tooling will save you — you will have built something impressive that fails exactly where it matters most.
Going deeper
Placement is the first move in building a company on software; the disciplines that come after it — turning a placed task into a reliable worker, keeping it honest in production, and proving its economics — are what The Durable Operating Manual works through end to end on a single build-along company. For the bigger picture of how this fits together, start with how to build a one-person AI company; for what happens when a task is placed wrong and ships anyway, see why AI demos die in production.