AI Agent Team: What Survives When the Session Ends

An AI agent team is defined by what survives a session: a name, standing rules and written memory. Here is how AuricIDE keeps them.

->->$->&&->{}->AI AGENT TEAMAuricIDE · Blog

Picture a Monday morning. On Friday afternoon a supervisor run sorted a backlog, and the human corrected it twice. A blocked ticket had been put first, and a duplicate had landed next to a ticket that was already closed. Both fixes went into the chat. On Monday a new run opens on the same repository and puts the blocked ticket first again.

Nothing is broken.

The repository is the same, but the run is not, because it never heard of Friday, and that gap is what separates a pile of agent runs from an AI agent team.

Is an AI agent team just roles side by side?

The obvious answer is yes: a planner, a coder and a reviewer, each with its own prompt, running next to each other. The split is sensible. A reviewer who never writes the patch is easier to trust, and a planner who only orders work keeps its prompt short.

Monday breaks it anyway. Each role starts from zero, so the planner has not heard Friday's rule and the coder repeats a step the reviewer already rejected. Same titles. No notes.

A role tells an agent what to do now. A handover tells the next session what changed. Roles alone carry no handover. An agent team is defined by what is still there when a session ends: a name, standing rules from the human, and written memory. How many agents run at once decides the speed, and has little to do with whether they form a team.

Think of a colleague who keeps a handover notebook and a stranger with the same job title who walks in empty-handed each morning. Only the first can pick up Friday's work. A single session holds plenty while it is open, which is what agent context management is about, but that hold ends when the session does.

How does a supervisor run become a Project Manager?

A finished supervisor run is promoted from the runs panel with "Promote to Project Manager", and the human gives it a name. The run keeps its folder and everything in it. It gains two things. One is an INSTRUCTIONS.md file. The other is a knowledge/ folder.

A run that is still working can be promoted too. It keeps running as it is and works as a manager from its next start, and the inspector offers a restart for people who do not want to wait.

The name and the address sit in a registry file that the app owns, outside the run folder. The reason is practical: the manager's own file tools reach that whole folder. The manager can rewrite its notes all day. Its registered name is not in them.

What does a manager read on Monday?

It reads two things. One comes from the human, one from itself.

INSTRUCTIONS.md belongs to the human. Its text is added to the manager's start prompt every time it opens, and the template suggests rules like "Write every ticket in Spanish." The manager reads this file. It is told never to edit it. The rules steer. They grant nothing. What the manager may start, where and with which model stays in Settings.

The second is knowledge/, a folder of notes the manager keeps as it works, after a decision, a correction from the human or a lesson learned. Each fact gets its own file. Nothing is ever deleted. A note that turned out wrong is marked deprecated and points to its replacement, so an old fact cannot come back as current. At the next start the manager reads the index, the index of each section and the newest note in sessions/, and goes deeper only as far as it needs. The agents its earlier sessions started are now its children, so it can read what the finished ones left and check on any still running before it starts new ones.

On Monday, Friday's two corrections are in that folder, written down in the manager's own words. The blocked ticket stays at the bottom.

Who touches what
Registry, instructions, knowledge
RegistryAppHolds the name and the address, outside the run folder.
INSTRUCTIONS.mdManagerAdded to the start prompt every time the manager opens.
knowledge/ManagerIndex, section indexes and the newest session note, deeper only as needed.

At the next start the manager reads its instructions and its notes. The registry is not among them.

How does the human see what a manager is doing?

Quick Access shows each manager as a tile with a monogram, a dot while a session works, and amber when it needs you. The tooltip carries the last session's note. "Ask" on the tile sends a task as a message to a running manager, or starts a stopped one with it. A schedule can hand a manager a task too, and a running manager receives it as a message.

When a session ends, the app checks the memory itself, and the agent does not get to mark its own work as checked. It posts "name finished a session" with the manager's own note, or says plainly that the manager ended without writing one. If the check found layout problems, the message says how many. A session that ended in a crash or an app quit gets the same check at the next app start. Where a manager sits among the other screens is covered in the article on the AI agent control plane.

What does a Project Manager cost?

Each choice here has a price. One manager means one folder and one live session. Resuming a folder that a live session already works in is refused, so two sessions can never edit the same memory. That keeps the notes safe from two writers at once.

The memory is plain files on this machine. A teammate who clones the repository gets the code and none of the manager's notes. That keeps the record private. It also means the history never reaches anyone else.

The manager writes its own notes, so the notes are only as good as what it chose to write down. The app's check covers the layout of the folder, not whether a note is true.

Standing instructions steer and never widen permissions. Giving a manager a new capability is a separate step in Settings, slower than writing a rule, and visible in one place.

No standing notes for a one-off task. A plain supervisor run is enough when nothing has to outlast the afternoon. A manager pays off for work that continues over days, where the next session would otherwise start from a blank prompt.

Retiring one is a decision too. Archiving keeps the entry but blocks new starts, and a schedule can no longer pick it. Restoring brings it back. That works only while no other manager has taken its name. Removing works only on an archived manager, and its folder stays behind as an ordinary run.

One manager, five moves
What the manager looks like now
StateActive manager
RegistryName and address entered, outside the run folder
New startsAllowed
SchedulesCan hand it a task
FolderKept, plus INSTRUCTIONS.md and knowledge/

The run keeps its folder and everything in it. It gains the instructions file and the knowledge folder, and the human gives it a name.

What is left when the session ends?

What is left is a name, rules and notes. That holds in any tool. The specifics here may change. A group of agents becomes a team when the next session can read what the last one learned, and not before.

So the test is short. End a session and start another. Ask for the rule from Friday, and ask why the duplicate was rejected. If the answer comes from a saved record, it is a team. If the run asks what the project is, it is a shift of strangers. A note nobody reviews can still mislead, so the record needs a reader too.

AuricIDE is open source

AGPL v3, alpha, developed in the open. Read the source on GitHub and judge it yourself.

Star on GitHub