Give each proactive AI agent team a defined output

So far you have built proactive agents one at a time. A proactive agent is an AI assistant given a narrow, recurring job that it carries out without you prompting each step. You have an intake agent, a research agent, an action agent, a delivery agent and a reporting agent. Each does useful work, but on its own each one only sees its own task.

A Factory is the next step. It is a set of agent teams organised around the project outcome, which here is a reviewed, accepted handover. An agent team is a small group of agents that together are responsible for one defined output.

Think of a kitchen. Five cooks working separately can each make good food, yet no one owns the finished meal. Group them into stations, such as prep, mains and the pass where plates are checked, and each station owns one result the next station can rely on.

In the sample service-improvement project, the outcome is a delivery plan the client can act on. The Factory exists to produce that. A team that cannot say which part of that outcome it delivers does not belong in the Factory.

For project preparation, the Factory has three teams. Each one answers a different question.

• Evidence team. It establishes and maintains the evidence: what was asked, what the sources say, which assumptions are still open. Question: What do we know, and how sure are we?
• Delivery team. It prepares the delivery plan and the drafts that go with it. Question: What will we do, in what order, and what will we hand over?
• Review team. It checks whether the handover is usable by the person who receives it. Question: Could the client act on this without coming back to us?

The separation matters. If the team that drafts the plan also decides whether the plan is good enough, weak spots tend to go unnoticed. The same thing happens when one person writes and proofreads their own report.

In the sample project, the evidence team confirms the client's current complaint-handling steps. The delivery team turns that into a phased plan. The review team checks the plan against the agreed acceptance criteria before the project owner sees it.

You do not need new agents. Each team draws on the agents from earlier lessons and gives them a shared purpose.

• The intake agent (request triage) and the research agent (evidence updates) belong in the evidence team. Together they keep track of what was asked and what the sources show.
• The action agent (action register, dependencies, blocked work) and the delivery agent (deliverable preparation, controlled revisions) belong in the delivery team. One keeps commitments visible. The other drafts against them.
• The reporting agent (recurring project review) fits the review team. It already compares the current state with what was agreed.

Some judgment is involved. If your project has heavy client paperwork, for example, you might place the intake agent nearer the delivery team. What matters is that each agent sits in the team whose output it most directly serves, and that you can explain why.

The agents keep their narrow jobs. Joining a team does not widen what an agent is allowed to do. It only makes clear whose output its work supports.

Every team gets a short definition with four parts:

1. Purpose: one sentence on why the team exists.
2. Inputs: what it reads, and from where. Name the specific documents and record entries.
3. Output: the one thing it produces, named as a file or record entry.
4. Done criteria: the checks that tell you the output is finished. These are written in advance, not decided afterwards.

Here is the evidence team for the sample project:

• Purpose: Keep an accurate, current picture of the request and its evidence.
• Inputs: the request digest, the approved source set, owner decisions in the shared record.
• Output: an evidence summary, with the requirement matrix and assumption register kept up to date.
• Done criteria: every requirement links to a source or is marked as an assumption. Conflicting findings are listed, not resolved silently. Nothing is shown as agreed unless the owner approved it.

The last criterion carries a habit from earlier lessons into the team. Missing information must not be presented as an agreed requirement.

Flip the cards to see the same four parts for the delivery team.

The review team has the easiest definition to get wrong. It is tempting to make it a proofreader. Its real job is to ask whether the person receiving the handover could use it.

A definition for the sample project:

• Purpose: Check whether the handover is usable by the client and ready for owner review.
• Inputs: the delivery plan and drafts, acceptance criteria, the requirement matrix, decision history.
• Output: a review queue. This is a folder of items, each one marked as pass, fix needed, or decision needed from the owner. It comes with a completed handoff checklist.
• Done criteria: every acceptance criterion has been checked and given a result. Every "decision needed" item names the decision. No item is marked pass without a reason linked to it.

Notice that the review team does not approve anything. It prepares the decision. The project owner still approves scope, commitments and anything sent to stakeholders.

Put the steps below in order. They show how you would write any team's definition from scratch.

The teams share one project record. This is the place where approved actions, decisions, assumptions and team outputs are kept. Something needs to follow that record across team handoffs and report back to you. In this course you choose OpenAI Dots or Claude Duet for that role.

Whichever you choose, give it the same job. Each cycle it reads the approved record and returns three things:

• current actions
• draft deliverables and their status
• decisions holding up progress

It follows the record. It does not rewrite it. If a draft contradicts an approved decision, the tool reports the conflict and leaves it for you to resolve.

Pick the tool your organisation already permits, and the one whose sharing fits your setup. Before you rely on it, check the tool's current documentation for how it handles two things in your account: shared files and scheduled work. Features and plan limits change, so do not assume. Note what you confirmed and the date you checked it in your Factory notes.

When teams share material, information moves further than it did with a single agent. An interview note that the evidence team picks up can end up in a delivery draft, then in a review folder, then in the tool's summary for you.

So add one rule to every team definition. Client-confidential and employee information stays inside approved connections. An approved connection is a folder, account or integration that your organisation and the client have permitted for this work.

In practice:

• List the approved locations in the project record and point every team's inputs at them.
• Use anonymised versions where a team does not need names. The review team can check a plan without knowing which employee raised a complaint.
• If a team needs material from somewhere that is not approved, it flags this as a decision for the owner and does not copy the material across.

This course does not cover formal data-protection or compliance requirements. Your organisation's own rules apply. If you are unsure whether a connection is approved, treat it as not approved until someone responsible confirms it.