An agent that lives in the project management tool

In my own projects, the agent lives on the task list. It reads the same tasks as the people involved, and it works inside written limits on what it may decide.

It started somewhere else. 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 them, understand them and decide. I wanted the agent available all the time, and I wanted the people around it to keep up.

An operating system for a team of one covers one person and several agents at a keyboard, under the public Agent Operating System. 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 where work was defined, assigned and closed. The agent was connected to that place, not the other way round.

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

A bare AI tool given a project has no idea what the project is. Given the written history and the task list, 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

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.

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 agent keeps the same record 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, whoever closed it.

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

Where the agent stops

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.

These written limits are the fence around the list. The agent is available all the time, and only inside it.

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