Your Coding Agents Don't Need a Project Board

At some point in every Agentic Engineer's work, there comes a time where there are multiple sessions, on multiple machines, working on the same project. The challenge here is always coordination. To complicate things, we have human-designed project management frameworks, code repos, and all sorts of workflows.

The question becomes, do we bring that foundation of thinking into the Agentic age? Most people say yes ... IMHO, it can be a lot simpler.

The real work of moving an active project across two machines with multiple AI sessions without losing a thing is daunting. But the whole coordination layer could be as simple as two plain text files committed next to the code. Here is why that beats the elaborate tooling most teams reach for.

And ... I do this all the time. Real work moving across my coding lab of machines, with multiple separate AI coding sessions. The coordination layer for all of that is JUST two plain text files, and nothing gets lost in the handoff.

The setup

The pattern is almost embarrassingly simple. Every working repository carries two markdown files next to the code.

One is a whiteboard. It holds the current state: what is live, what is half done, what another session(s) depends on, and what must not be touched. It opens with one instruction, read this first. You update it the moment you change something another session relies on.

The other is a TODO list. It holds what is left, in plain language, with enough context that a fresh session can pick up an item cold.

That is the entire system. No board, no tickets, no status automation, no second place to look. And each coding session or agent is advised to review it, update it, and clean up the stale data regularly.

Why it holds

Seeing people put all sorts of frameworks out there and complicating things, I keep coming back to what worked best in those early days of my time in the industry. Turns out, it is a simple whiteboard the whole office could walk up to and read, and a singular set of tasks aligned to a specific project goal.

The files are the same everywhere, and using GitHub branches and merges enables the insights to travel cleanly across machines, purely on the strength of those two files.

Why does it work? Because it is honest and accessible.

The state lives next to the code and travels with it. Pulling the latest code pulls the latest state in the same motion. There is no separate system to keep in sync, so there is nothing to drift out of sync. The commit history becomes the archive on its own. The whiteboard is the now, the log is the past, and you never confuse the two.

It is plain text, so it is legible to anything. Any session, any machine, any person reads it in one glance with zero tooling. A project board asks you to go somewhere else, in a browser, and interpret a schema before you learn anything. A file in the directory you are already standing in just tells you.

Most importantly, the protocol is social, not infrastructural. Read the shared state first, update it when you change something shared. That one sentence does the work that teams stand up elaborate systems to do. The discipline lives in the habit, not in the tool.

If the shared state is colocated with the work, versioned with the work, and written in the plainest possible format, most of the workflow ceremony stops being necessary. The result is not being short a system; it is a simplification of a convention.

In designing for AI more broadly, the interface between a human and a fleet of agents does not have to be a dashboard or a bespoke orchestration layer. It does not have to be the latest chatroom tool replicating human conversations and "named agents" as personas.

It can be a simple, shared, legible, versioned text that every party reads and writes the same way.

When you are designing how people and agents work together, the coordination surface is the thing to design. Keep it legible and keep it close to the work, and a lot of the apparatus you thought you needed quietly disappears.

The challenge of discipline

IMHO, this works this cleanly because the parties reading and writing those files are disciplined and trusted. In my case they are my own sessions, following the same convention, reading first and updating on change. Even without formal skills files, or other higher-level configuration templates.

It can also work across small teams of developers. But drop in an undisciplined actor, or scale to dozens of strangers who do not prompt every session to review the TODO and WHITEBOARD before getting into the session work, and you would need more guardrails than a shared text file.

Though it is worth being precise about what those guardrails are, and what you already have. This is not pure convention with nothing beneath it. Git is the enforcement underneath: when two sessions touch the shared files, the second push is rejected until the change is reconciled, so a collision surfaces at the boundary instead of merging silently. The convention handles the writing, version control handles the clashes.

And if you push further, into many agents writing the same repository at once with nobody sequencing them, you still do not need a new system. You need a lighter version of the same convention. Add a claim line to the whiteboard, where a session writes what it is taking before it starts: this machine owns the deploy as of today. Or move to one task per file, so two sessions can never conflict on the same lines. Both are still just text, next to the code. Add them when the pain actually shows up, and not a moment before.

But for a mesh of your own machines running your own work, the heavy setups are answering a question you never have to ask. Less tool, more signal. Two files, two machines, one mind.

Give it a try ... and if you are finding your way ... WHITEBOARD and TODO are just the file names. How you structure the data within, that depends on the maturity and necessities of your work. For me, my sessions go across Claude and DeepSeek, and any number of local LLMs. So ... what I am saying is ... your mileage may vary.