Nobody on My Team Is Human

Chinese version: 中文版

A practical field guide to moving from one helpful chatbot to a dependable AI team—through bounded roles, workflows, parallel crews, recovery rules, and human accountability.

The title of this episode sounds like a boast: Nobody on My Team Is Human. The important truth is almost the opposite. Software can handle research, drafting, fact-checking, design, production, and validation, but one person still chooses the purpose, sets the boundaries, reviews the result, and owns the decision to publish. The breakthrough is not removing the human. It is stopping one human from doing every job personally.

A chatbot answers. An agent pursues a result.

An AI agent is not merely a chatbot with a grander label. A chatbot mainly responds to a prompt. An agent is placed inside a job: it receives instructions, gains access to selected tools and information, takes actions toward an outcome, and returns evidence of what it did. OpenAI’s practical guide to building agents describes the core pieces as a model, tools, and instructions. The workflow around those pieces supplies the role, the constraints, and the definition of done.

That distinction changes how you manage the system. If the instruction is simply “help me,” every missing detail becomes an invitation to guess. If the role is “verify these factual claims against primary sources, record the evidence, and stop when a source cannot be found,” the model has a bounded job that can be inspected.

The construction-site model

The episode uses a construction site as its central model. Agents are specialized crews. Workflows are the site plans. Acceptance tests are inspections. The human owner decides what should be built, where the machinery may operate, and which decisions require approval. Tokens are the fuel meter—but that last analogy needs a boundary.

A token is a unit in the representation a model processes or generates. Services often count input and output tokens for usage and billing; OpenAI’s token guide explains the main categories. Tokens therefore make a useful activity gauge, but they are not a productivity score. A machine can burn fuel while moving the project forward or while spinning in mud. The better metric is verified output per unit of money, time, and human attention.

More activity is not automatically more value. The work counts when the result survives inspection.

Four stages from assistant to operating system

The four stages in the episode are a teaching model, not an industry law. They describe a useful progression for a one-person operator building a reliable team of machines.

1. The helpful apprentice

Give one model one task, inspect the output, and ask for revisions. This is powerful for a page, an image, a document summary, or a contained code change. It becomes fragile when the job outgrows the conversation: earlier decisions disappear, ambiguous gaps invite confident guesses, and the human becomes a full-time error courier.

2. The workflow

Define the route before requesting the output. Which files may change? Which sources count as evidence? What format must be returned? Which checks must pass? What happens if an input is missing? A workflow turns repeated decisions into rules, repeated procedures into tools, and quality expectations into gates. The model still uses judgment, but it judges inside a shape.

3. The parallel crew

Independent work can be divided. One agent gathers sources while another inspects a project; after a script is approved, separate image workers can own different scenes. Current agent systems can run work in parallel—the Codex app announcement, for example, describes multiple agents operating in separate threads—but speed still depends on architecture. Two workers editing the same source of truth can create more rework than one careful worker.

Parallelism works when each worker has clear territory, shared truth sources, explicit handoffs, and outputs that can be verified independently. Dependency comes first; concurrency comes second.

4. The overnight machine

The final stage is not simply “let the AI work while you sleep.” It is a workflow with exception policies. If one image fails, should the system retry, skip, or stop? If two sources disagree, who decides? If a tool reports success but produces an empty file, what evidence catches it? If a public action could create harm, where is the approval gate?

The failed-image story in the episode exposes the real lesson: autonomy is mostly recovery design. A happy-path workflow demonstrates a task. A dependable workflow also knows how to pause, preserve state, surface the problem, and resume without pretending the failure never happened.

What the human keeps

The useful boundary is not “humans decide, machines execute.” Models already make many bounded judgments. A better rule is: delegate decisions that can be constrained and checked; retain decisions that define purpose, taste, risk, and accountability.

• Purpose: Is this problem worth solving?
• Taste: Is the technically valid result clear, honest, and alive?
• Risk: Which errors are reversible, and which require a stop?
• Accountability: Who owns the consequences when the system is wrong?

An agent can perform a role. It cannot absorb the owner’s accountability. That is why a one-person AI company is not a company without management. It is a company in which management—the design of roles, evidence, handoffs, decision rights, and recovery—becomes the highest-leverage work.

Design the first role

Start with one role that is narrow enough to verify. Write down its required inputs, permitted tools, output format, acceptance test, evidence requirement, and exception policy. Then name one decision that the role must always return to a human. If those fields are vague, adding more agents will multiply ambiguity. If they are clear, even one agent begins to feel less like a chat window and more like a dependable colleague.

So which bounded AI role would you hire first—and which decision would you refuse to delegate?

Watch more first-principles field guides on Wiki4What, or read the essays at blog.wiki4what.com.