The useful part of that idea is the boundary between planning, doing and approving. Here are three practical constraints behind Chief in asklog, and how to try the same shape in a terminal workflow.

1. Give each worker a branch and a worktree

A separate chat does not give an agent a separate filesystem. If two agents edit the same checkout, one can overwrite a change the other has not finished.

Git worktrees let you give each task its own checked-out files while sharing the repository. For example, from a clean repository:

git worktree add ../app-worker-auth -b worker/auth
git worktree add ../app-worker-tests -b worker/tests

Start a worker from each directory and give it one bounded task. Keep the supervisor in a separate session that tracks the task, branch, evidence and open decisions.

This is isolation of checked-out files, not a security sandbox. Worktrees still share Git objects and configuration. An agent with broad shell permissions can reach other directories. The guardrails must match the tools and permissions you actually grant it.

2. Make 'done' refer to evidence

A worker's final message is a claim about its work. The repository is where that claim can be checked.

Ask the worker to report which files changed, what behavior changed, the checks it ran, and anything it could not verify. Review the branch and actual output before accepting the task. A missing check is unknown, not a pass.

Keep tasks small enough that the acceptance check is concrete: reproduce the reported failure, make the change, then repeat the user journey. Avoid treating a test count as a substitute for the behavior you needed.

3. Separate preparation from merge authorization

The supervisor can decompose a job and bring back decisions while workers prepare changes. That does not have to include permission to merge them.

Put the approval boundary somewhere a prompt cannot casually talk its way around. Review permissions and the available tools, and keep an explicit authorization step before changes reach the branch you ship. Instructions and operating-system enforcement are different layers; say which one you have.

Chief follows that division: it coordinates Claude Code or Codex workers, each in its own worktree, and brings decisions back to the maker. Its delegation rule is an instruction; its editing tools are not disabled. Leads retain separate read-only restrictions. The default merge policy requires the maker's word, and the maker controls that policy. asklog also exposes the same live sessions on the phone, so reviewing a question does not require sitting beside the host. The host still needs to stay awake and connected, and the agents use your own logins.

We're live on Product Hunt today. If you run multiple coding agents, I'd especially like feedback on where you want the approval boundary:

https://www.producthunt.com/products/asklog?launch=asklog-2&ref=hashnode-chief-article-20261103

Demo: https://youtu.be/ivRfjhUl85Y?ref=hashnode-chief-demo-20261103

Disclosure: this article was prepared with AI assistance and checked against asklog's implementation and published design decisions. It describes the workflow, not a benchmark or a guarantee that an agent's changes are correct.