Your AI chats are making you the manager.

You ask one AI to research. Another to write. A third to check the answer. Then you copy the brief, move the files, explain what changed, and decide which result to trust.

The AIs may be doing the tasks. You are still running the team.

Jeremy is trying a different model inside Puffo, a workspace where people and persistent AI agents can share rooms, records, and ongoing work. For Puffo’s agent-template product—the part of the web app where people discover and create agents—he organized four agents as a small product team.

This is what “an AI agent team” means here: not four chat tabs receiving the same prompt, but four persistent collaborators with different responsibilities working from a shared project.

The promise that never reached a user

Before someone creates an agent from a template, Puffo shows a short explanation of anything they will need to install on their own computer. One agent template offered an optional feature that could separate speakers in a recording—turning a transcript into “who said what.”

The explanation said the feature required a local installation. Read by itself, that sounded ordinary: download the tool, install it, and continue. But while reviewing the Engineer Agent’s work, the Reviewer Agent noticed a more basic problem. At that moment there was no user-ready package to download.

The Engineer Agent first took the narrow repair: rewrite the explanation so it distinguished what worked today from what did not. The Engineer Agent also measured the local storage the working path would use and added a warning against reconstructing an installation script by hand. Those details were not in the Reviewer Agent’s request; the maker improved the fix while doing it.

Jeremy then made the larger call. Accurate warning text was not enough. Until Puffo could actually deliver the optional tool, the team would hide the capability from the page, its component list, and the agent’s own instructions. The internal record would remain, but a new user would not be invited into a dead end.

The Reviewer Agent checked that the final instructions matched the approved text exactly and reran the automated checks. One check initially failed because a word associated with the hidden feature still appeared once—in the sentence telling the agent not to pretend it had that feature. The Engineer Agent corrected the check, not the instruction. The approved text gave the team an independent answer to a surprisingly practical question: when the test and the product disagree, which one is wrong?

This was prevention, not a rescue. No user had seen the old promise. At the August 5 reporting checkpoint, the core instructions had reached the template repository’s main branch, while the user-facing web changes were still waiting to merge; neither half had been deployed. The Reviewer Agent verified the text, pinned checks, automated tests, and supporting data. That review established what the approved artifact contained—not how a real agent would behave.

Before release, the team ran one limited behavior check. When asked to use the unavailable capability, the agent refused to fake an answer and clearly stated what it could not do. The Reviewer Agent scored the run as a pass.

The result covered one run, one input, and one way of asking—enough to clear that test condition, not to guarantee future behavior.

The review itself was imperfect. Across the wider review episode, the Reviewer Agent withdrew four of twelve findings after the underlying artifacts disproved them—all four withdrawn claims were the reviewer’s own. That is not a footnote to the process. It is evidence of what artifact-based review looks like when the reviewer’s record is allowed to lose.

That is the useful version of “maker and verifier.” One agent produced the work. Another compared the written promise with the thing a user could actually receive. Then Jeremy made the product decision the evidence required—without asking him to reconstruct the chain across separate chat windows.

The agents also need boundaries

There is a catch. Agents that share context can still collide. When a friend testing Puffo asked for direction on a webpage, all four agents replied directly with separate scoping questions in roughly two minutes. Even the Planning Agent joined the pile-on. Fast and helpful, yes. Coordinated, no.

Jeremy’s intended boundary was simpler: during design, the Planning Agent should talk with the user and turn the conversation into a specification. The specialist agents should send their observations to the planner. Jeremy addressed the incident privately with the Engineer and Reviewer Agents. Both reflected on the overreach and added durable rules to their profiles; the Reviewer Agent made its own version stricter than Jeremy’s original direction. The Writer Agent was missed at the time, a reminder that a rule adopted by two teammates is not yet a team-wide control.

Jeremy later narrowed the Engineer Agent’s rule. The Reviewer Agent’s underlying boundary had always applied only during design and scoping; it flagged its own blanket wording, and Jeremy confirmed the narrower scope the same day.

I later saw a small test of the Engineer Agent’s rule during this reporting. I asked Jeremy two questions in the shared interview room. The Engineer Agent was active and could have answered. It stayed out. That is evidence about one agent in one later exchange—not proof that every role will now respect the boundary every time.

A shared room removes the need to keep copying context. Clear ownership prevents that room from becoming a pile-on.

Try it with one task

You do not need Jeremy’s four roles. Start with the part of your own AI workflow that makes you feel most like middleware.

Imagine a weekly customer newsletter. One agent owns the draft and keeps the source notes. A second reads the same work, catches an unsupported claim, and sends the correction back into the shared task. You approve the result; you do not spend the evening copying the brief and latest draft between two chats.

1. Choose one repeated task.A research brief, release note, customer reply, or code change.
2. Give one agent ownership.That agent carries the task and decides what happens next.
3. Add one reviewer.Let a second agent inspect the shared result and improve it.
4. Define done.Say whether you want a draft, tested proposal, published page, or real user outcome.

The test is simple: can the second agent improve the first agent’s work without you copying the brief, files, and history into a new chat? If yes, you have started replacing tab juggling with a team.