Assign proactive AI agent team responsibilities

Over the last module you built several proactive agents. A proactive agent is one that starts work when something changes, such as a new file arriving or reconciled results moving, instead of waiting to be asked. Your agents now cover intake, reconciliation, variance review, driver updates and the management pack.

With that many agents, two problems appear. It gets hard to see who is responsible for what. A mistake in one place can also travel straight into the pack without anyone checking it.

The fix is to group agents into teams. In this course, a Factory is a set of coordinated agent teams that prepare a reporting deliverable together. You will use three teams:

• Data and Control
• Planning and Analysis
• Management Reporting

Each team gets a written charter. A charter is a short document that states the team's scope (what it covers), inputs, outputs, its 'must not' list, and the finance owner it escalates to. A charter makes each team's work something a person can check.

In this lesson you write the three charters. In the next lesson you define how work passes between the teams.

Start by placing the agents you already have. Group them by the kind of work they do, not by the order you built them.

• Data and Control gets the work that makes the numbers trustworthy: the data intake agent (Day 3) and the reconciliation agent (Day 4), including exception handling.
• Planning and Analysis gets the work that explains and projects the numbers: the variance agent with its evidence requests (Day 5) and the driver-update agent (Day 6).
• Management Reporting gets the work that presents the numbers: the reporting agent (Day 7), which assembles the narrative, slides, dashboard and cross-pack tie-outs.

A cross-pack tie-out is a check that the same figure shows the same value everywhere it appears. For example, March revenue of EUR 4,820k should match in the narrative, on slide 3 and on the KPI dashboard.

Write this assignment down as a simple table: agent, team, and the earlier lesson where you built it. If an agent seems to fit two teams, split its duties or give it to the team whose output it mainly produces.

Scope: intake, reconciliation and exceptions for the reporting period.

Inputs: arriving sample files (trial balance, sub-ledger extracts, bank balances), with period and currency labelled.

Output: one reconciled dataset version with the open differences listed. A dataset version is a fixed, numbered copy of the data, such as March v2, so later work can say exactly which numbers it used. An open difference is a reconciling item not yet explained or cleared.

Example output line: March v2, EUR thousands. Bank vs ledger difference EUR 12k, open, evidence requested from Treasury.

Limits: the team does not hide or net off differences. It makes no unexplained adjustments and invents no correcting entries. Rejected files stay out of totals, and duplicates are flagged rather than counted twice.

The key test for this charter: could the next team accept the output without asking which version it is, and without missing any open item? If the open differences are not listed, the output is not finished, even if the totals look right.

Scope: variance review, evidence requests and driver updates.

Inputs: a reconciled dataset version from Data and Control, the approved sample model, and an assumption version. An assumption version is a numbered set of approved assumptions, such as Assumptions A3: price +2%, volume -1%.

Outputs: variance explanations and scenarios, each tied to a named dataset version and a named assumption version.

Example: Revenue EUR 4,820k vs budget EUR 5,000k, a variance of EUR -180k (dataset March v2, assumptions A3). Price effect supported by price list; volume cause requested from Sales, not yet in commentary.

Limits: a possible cause stays labelled as possible until evidence supports it. The team keeps the model, changed assumptions and resulting scenarios distinct. It does not approve its own assumption changes. A new driver value creates a proposed assumption version that waits for finance.

Why tie every output to two versions? If Data and Control later issues March v3, you can see at once which explanations were built on old numbers and need refreshing.

Scope: the narrative, financial slides, KPI dashboard and cross-pack tie-outs.

Inputs: variance explanations and scenarios from Planning and Analysis, each with its dataset and assumption versions, plus the list of open differences carried forward.

Output: a draft pack for finance review. The word draft matters. This team prepares the pack but never releases it.

Example checks before handing over:

• March revenue reads EUR 4,820k in the narrative, on the slides and on the dashboard.
• Every chart footnote names its dataset version (March v2).
• The EUR 12k open bank difference appears in the review queue, not buried or dropped.
• No sentence states a cause that Planning and Analysis marked as unsupported.

Limits: the team does not change figures to make slides tidier. It does not rewrite an unsupported cause as fact, and it does not mark the pack as final. If a tie-out fails, the team stops and reports it. It does not pick the number it prefers.

Each charter ends with a 'must not' list: actions the team may never take, whatever its instructions or inputs say. Three items differ by team, as you saw above. Four are the same for all three teams, because this Factory only prepares reporting:

1. No posting entries to any ledger.
2. No releasing payments.
3. No moving money between accounts.
4. No placing trades.

These limits hold even when an action looks helpful. Suppose the reconciliation agent finds that an accrual of EUR 8k was missed. It must not post a correcting journal. It records the difference, attaches the evidence and escalates. A person then decides, in the live accounting system, what to do.

Write the list into every charter, not into one shared footnote. That way anyone reading a single team's charter sees the limits without searching elsewhere. The classroom system also stays disconnected from live ledgers, bank accounts and payment systems. The rule is backed by the setup, not only by the instruction.

Some decisions never move to an agent team. Finance owners approve assumptions and approve release of the pack. A finance owner is a named person, not a department or a job title on its own, who is accountable for a decision.

Each charter names the person its team escalates to. For example, with fictional names:

• Data and Control escalates to the Financial Controller, Maria Lopez, for unresolved differences and rejected files.
• Planning and Analysis escalates to the FP&A Lead, Tom Reyes, for unsupported causes and proposed assumption changes.
• Management Reporting escalates to the Head of Finance, Priya Shah, who approves release.

Also name a deputy, so escalations do not stall when someone is away.

Escalation follows a fixed path. The agent stops the affected work and records the issue in the shared record. It then notifies the named owner and waits. The owner's decision is recorded before work continues. You will design that shared record and the handoffs between teams in the next lesson.