I got overwhelmed by all the separate chats.
Emma was coordinating. Maya and the Agent Village were building. Claude was reviewing and working on the harness. Rocky was my muse.
Then two agents ended up working on overlapping parts of the John OS harness. I asked one to stop until Claude finished.
That’s when “who’s doing what?” became a practical problem.
I created a shared TASKLOG.md file and started insisting on a routine: pull the current state, update the log when starting or completing work, push each update, and preserve everyone else’s changes.
I want one place to coordinate.
In “I Wanted a Coding Partner. I Built a Village.” and “The Village Was Never About the Agents,” I wrote about the people, roles, and ownership behind this approach. This time, I want to walk through how to set it up.
You can start with two AI chats and a document. You don’t need to build an agent platform first.
Step 1 Choose one place where assignments live
Create a document called “Project Task Log.”
For a coding project, that can be TASKLOG.md in your repository. For other work, use a shared document or a note you maintain yourself.
Write these four things at the top:
Goal
Current scope
Coordinator
Last updated
The coordinator can be you. That’s the simplest starting point.
Agents can suggest tasks, flag problems, and recommend changes. The coordinator decides who owns each task and whether the scope has changed.
Don’t assume a chat message reaches another agent. Don’t assume an agent reads the task log automatically. Until you have verified those capabilities, explicitly provide the current instructions and collect the response.
Step 2 Define one finish line people can check
We’ll use one hypothetical example throughout: building a signup page for a paid workshop.
The business goal is to sell workshop seats.
The first engineering goal is narrower: produce a working signup page on a private preview, ready for your review.
Those finish lines require different evidence. A working page doesn’t prove anybody will buy a seat.
Write the immediate goal like this:
“Create a private workshop signup preview. Visitors can read the approved description, submit a test email, and see a confirmation. No real payments, public launch, or customer outreach.”
Then define acceptance:
Approved workshop details appear correctly
A test signup reaches the test destination
Invalid entries show a useful error
The page works on mobile
The reviewer records the checks performed
Now “done” has something behind it.
Step 3 Divide the work by deliverable
Start with three tasks:
T1: Write workshop page copy
T2: Build the signup page using approved copy
T3: Review the completed preview
Give each task one owner.
“One owner” means one agent is accountable for delivering that task and reporting its status. Other agents can contribute through separate, clearly bounded assignments.
Make the boundaries concrete. For this example:
T1 owns the copy document
T2 owns the signup page and its tests
T3 reports findings without editing the implementation
If this is a repository, list the actual files or directories each builder may edit. If it’s a writing project, name the document or sections.
Anything outside those boundaries requires a new assignment or an explicit scope change.
That prevents a helpful copywriter from also rewriting the page while the builder is implementing it.
Step 4 Give every task a small, useful record
Here’s a sample entry you can copy:
Task: T2
Title: Build workshop signup preview
Owner: Builder
Status: Ready
Depends on: T1 copy approved
Inputs: Approved copy document; existing site conventions
May edit: Signup page, signup component, related tests
Must leave alone: Pricing, payment setup, customer data, unrelated pages
Deliverable: Private preview and change summary
Acceptance: Test signup succeeds; invalid email is rejected; mobile layout checked
Evidence: Preview link, test results, screenshot, commit or document version
Budget: One implementation pass and one review-fix pass within the project’s stated cost limit; stop before exceeding it
Next update: On completion, blockage, or proposed scope change
Use actual paths and actual limits in your project. “Related files” gets vague quickly.
Keep secrets out of the log. Reference an approved credential mechanism if one exists. Don’t paste API keys, passwords, or customer data into a shared task record or handoff.
Step 5 Claim the task before starting
This is the part that can look solved when it isn’t.
Two agents can read the same Git file, both see “Ready,” and both start. Pulling and pushing TASKLOG.md provides visibility. It doesn’t create an atomic lock.
For a beginner setup, use one person or coordinator as the only writer of assignments and ownership.
The sequence is:
1. Coordinator assigns T2 to Builder.
2. Coordinator records the assignment.
3. Builder acknowledges the exact task and boundaries.
4. Builder starts.
Other agents send proposed status updates to the coordinator.
If you later let several agents claim work directly, use a system that atomically grants the task to one claimant. A shared Markdown file alone cannot guarantee that.
My pull-update-push habit helps keep the record current. Reliable ownership still needs this additional rule.
Step 6 Send a kickoff the agent can acknowledge
Don’t just say, “Build the signup page.”
Use this:
“Start T2 using task log version [version/date]. You own only [deliverable and files]. Use [approved inputs]. Do not change [boundaries]. Completion requires [acceptance checks and evidence]. Your limit is [time/cost/passes]. Stop and report if a dependency is missing, another agent owns overlapping work, or the task requires new permissions. Before starting, summarize your understanding and confirm the files or documents you expect to change.”
Read the acknowledgment.
If it includes unexpected work, correct the assignment before execution.
That short exchange is much cheaper than discovering later that “signup page” became a payment integration, email campaign, and redesigned website.
Step 7 Parallelize only work that can stay separate
In our workshop example, copywriting and building the final page have a dependency. The builder needs approved copy.
You could separately assign a layout skeleton while copy is being written, but say explicitly that it uses placeholders and cannot settle the final wording.
Safe parallel work needs separate outputs and a clear point where they come together.
For code, give builders isolated branches or worktrees when your environment supports them. A worktree is a separate working directory tied to its own branch, so agents aren’t editing the same checkout.
Isolation helps protect unfinished work. It doesn’t prevent incompatible decisions.
Name shared interfaces up front, including form fields, file locations, and expected input/output formats.
The coordinator controls integration and merge order. Builders submit their changes and evidence. They don’t independently merge overlapping work because their own tests passed.
For documents, use separate drafts and have one owner assemble the final version.
Step 8 Make status changes explicit
Use a short set of states:
Ready → In progress → Review → Done
Add Blocked and Cancelled when needed.
“Review” means the owner has submitted the deliverable and evidence. “Done” means the acceptance checks have been reviewed and the deliverable accepted.
A blocked report should say:
“T2 is blocked by [specific problem]. I completed [work]. I need [input or decision] from [owner]. Current changes are saved at [location/version]. I have paused [dependent work].”
A handoff should say:
“T2 is ready for review. Delivered: [link/version]. Changed: [files or sections]. Evidence: [checks and results]. Not checked: [limitations]. Known issues: [list]. Please review against [acceptance criteria].”
For a Git-based log, update from the current remote state before editing, preserve others’ entries, and push the update. If there’s a conflict, reconcile it rather than replacing the whole file with an older copy.
An agent saying it updated the record is useful. Checking that the update is actually visible closes the loop.
Step 9 Handle a changed goal as a new instruction
Suppose the workshop changes from paid registration to a free interest list.
Don’t leave that decision buried in a new chat while the builder continues following yesterday’s brief.
Send:
“Change request for T2: the goal is now [new goal]. Stop work based on [old assumption]. Report your current state, saved changes, any actions still running, and any external changes already made. Do not resume until I provide the revised scope.”
Wait for confirmation from every affected owner.
Then update the task log, dependencies, and acceptance criteria. Resume with a clear new kickoff.
If work is being cancelled entirely, use:
“Cancel T2. Stop new work and cancel running operations where safely supported. Report what has already changed, what remains running, and where unfinished work is saved. Do not delete or roll back changes without a separate instruction. Confirm when you have stopped.”
Stopping work doesn’t undo a deployment, sent message, or saved change. Record what happened and decide separately whether anything should be reversed.
If an agent can’t confirm that an operation stopped, keep that uncertainty visible.
Step 10 Review the evidence before closing the task
The reviewer gets the assignment, acceptance criteria, deliverable, and limitations.
For our signup page, the review asks:
Does the test signup reach the correct destination? Does the confirmation appear? Does the mobile layout hold up? Is the copy approved? Was anything changed outside the authorized scope?
A screenshot proves appearance. It doesn’t prove the signup works.
A passing test proves what that test checked. It doesn’t prove the workshop will sell.
Record any failed checks as specific follow-up tasks with one owner each. After changes, repeat the relevant checks on the integrated result.
Only then move the engineering task to Done.
The business goal stays open until you have business evidence.
Start today with one small project
Pick something you already need to finish.
Create one task log. Write the goal, boundaries, and acceptance checks. Break the work into three tasks. Give each one an owner. Start only the tasks whose dependencies are ready.
Keep yourself as coordinator for the first run.
Before ending, make sure you can answer:
Who owns each unfinished task?
What are they allowed to change?
What are they waiting for?
What evidence will let you accept the result?
Who decides what happens next?
If those answers are scattered across five chats, bring them into the log.
That’s the setup I’m working toward: one place to coordinate, clear assignments, and enough evidence to know when the work is actually finished.