An agent that lives in the project management tool

In my own projects, I want an always-available agent where the work is recorded. It reads the same task list as the people involved, with written limits on what it may decide.

In An operating system for a team of one I wrote about one person and several agents at a keyboard, and about the Agent Operating System, the public operating model behind both essays. This is the shared half: one agent, several people, the same rules.

It went where the work already was

The work already ran as a task with a brief, in one place. That was true before any agent arrived, and it is the reason an agent could arrive at all. The list was already where work is defined, assigned and closed. The agent was connected to that place, not the other way round.

The second precondition was written context: how the work proceeds, what was decided and why. For years that was a discipline kept for its own sake. It turned out to be the thing that made the agent useful.

Give a bare AI tool a project and it has no idea what the project is. Give it the written history and the task list, and it can read a task against what came before.

So documentation became the rule. Nothing is connected to an agent without the written context that tells it what it is looking at.

The gap is the point

The agent lives in the task list for a human reason. Working with an agent in a terminal or a chat is fast, and fast is often overwhelming: replies arrive faster than a person can read, understand and decide.

A task with a comment on it has a gap built in. The agent writes; the person reads when ready, thinks, and answers. That gap is where understanding happens, and the setup is designed to keep it.

The rule underneath is that every action item lands on the task list first, wherever it surfaced: a chat, a code review, an agent session. When a note somewhere else disagrees with the list, the list wins. An agent that “logged it in its notes” has logged it where nobody on the team will look.

The same discipline as a person

The agent is held to the same standard as a person. A task opens with a brief that says what is in scope and what done looks like. It closes with a note on what shipped. A closed task with no note is a hole in the record.

Briefs name roles, never people. The work then stays easy to hand over, including when it changes hands to an agent.

Where the agent stops

In these projects, an agent acting in my name may read and summarise the work. It drafts a reply for me to read. I approve the exact words before it sends them. A change to those words needs my approval again.

When a request does not fit cleanly, it asks me before acting.

Tools are not projects

One line took longest to learn. A tool is reusable code with a defined scope. A project is one piece of work, tracked on the list.

Material from a project never goes into a tool, and that work stays on its own list. When a new request arrives, the first question is whether it needs a new tool, a new project, or work inside one that exists. It is almost always the third.

The fence is the point

Availability without the fence is a faster way to make a mess.