I run OnePersonCoHQ with a team of AI employees. That phrase can sound like marketing, so this article describes what it means in practice: who does what, how work is handed over, and where the human stays in charge.
The most useful change I made was to stop treating AI as a question box and start treating it as a set of roles. A role has a job, a boundary, context, and someone who checks the result.
The team
- ChatGPT, Strategy & Research Advisor. Positioning, product direction, pricing questions, SEO and indexing analysis, competitor research, and first drafts of long-form copy.
- Claude Code, Senior Product Engineer. Reads existing code before changing it, builds features, diagnoses production problems, and refreshes product records.
- Codex, Engineering & Operations Agent. Built much of this headquarters, audits product records for missing or stale evidence, and runs checks before and after releases.
- DeepSeek, Website QA & Review Agent. Reviews finished pages from a visitor’s point of view: layout, unclear copy, awkward flows.
A few other assistants are available for occasional research or Chinese-language work. Every role and its cost is listed on the HR floor.
No AI on this list is pretending to be a person. The titles are a way to give each kind of work an owner.
Rule 1: every task starts with a brief
“Improve my website” can produce almost anything. A useful brief answers six questions:
- What is the goal, in one sentence?
- What is the context: the product, the audience, the current state?
- What evidence do we have, and what is only an assumption?
- What may the AI change?
- What must it not change?
- What does “done” look like, and how will it be checked?
The fifth question does more work than the others. My briefs often end with a short list of things not to do: don’t redesign the homepage, don’t touch other products, don’t change the database, don’t add libraries, don’t publish anything yet.
Rule 2: one thing at a time
A capable AI will happily suggest five more improvements while it works on the first. Many of them are good ideas, and that is exactly the problem. Large, bundled changes are hard to review and hard to undo.
So I ask for one change, review it, and only then decide on the next. When an AI proposes a big overhaul, I usually break it into small steps and schedule them one at a time, or not at all. For a low-priority project, controlling the amount of work is part of the job.
Rule 3: the builder is not the only judge
The AI that builds something should not be the only AI that judges it. It tends to check what it meant to build, not what a visitor actually sees.
The flow is Build → Test → Review independently → Fix → Ship. Automated tests cover the logic. A real browser check covers desktop and mobile. A different AI then looks at the finished page with fresh eyes. This catches surprisingly ordinary problems: a table that pushes a phone screen sideways, a label that only makes sense to the person who wrote it.
Rule 4: checks before anything reaches production
AI writes code fast, and it can make mistakes just as fast. It can edit the wrong file, misread a requirement, or sound confident while working from incomplete information.
So every release goes through the same gate: linting, type checks, automated tests, a build, and a release check that has to pass before anything ships. After a release, the live pages are checked again. Changes are committed in small, reversible steps, and I decide when something goes live. When something does break, the first priority is to stop the damage and get back to a known-good state, then find the cause.
Rule 5: write down what AI must never publish
AI is helpful by default, and that includes being helpful with detail. Early drafts of this site sometimes described more of how things work behind the scenes than a public page should.
The fix was a written rule that every AI employee works under: build in public covers products, decisions, experiments, results, costs, failures, and lessons, but never credentials, infrastructure, configuration, security gaps, or anything that would make the company easier to attack. A rule written once is much more reliable than a correction repeated in every conversation.
Rule 6: the company keeps the memory
AI employees do not remember last week the way colleagues do. Each session starts mostly fresh. If the company’s memory lives only in chat history, it is effectively lost.
So the memory lives in the company record instead: project notes that every AI reads before starting work, a private log of what each AI actually did and whether it helped, the Weekly Review, and the daily Growth Calendar. When an AI starts a task, it starts from that record, not from a blank page.
What AI is good at, and where it goes wrong
AI employees are very good at continuing work once a direction is clear: researching a question, drafting, writing and refactoring code, writing tests, and checking work against a written standard. They are fast, patient, and willing to redo a task many times.
They are weaker at knowing what matters. They tend to do more than asked, treat a passing test as proof that the product is right, and fill gaps in information with plausible guesses. None of this is a reason to avoid them. It is a reason to give them a narrow brief and check the result.
What stays with me
Some decisions are never delegated: what the company builds, what it stops, how money is spent, what is published, and what reaches production. The AI employees can recommend any of these, and often their recommendations are good. The decision, and the responsibility for it, stays with the one human in the company.
That is the trade I am testing. I am not trying to remove myself from the company. I am trying to see how much one person can do when AI is part of the organization rather than just another tool. The structure that makes this possible is described in How the Company Works.