Four separate AI agents or one team: which should you choose?
A team scopes, connects and trains once: that is where the discount comes from, and nowhere else. Separate agents start one at a time, and are paid for one at a time.
The question arises as soon as one department needs more than one agent. There is no single answer: a team removes real costs, but it requires settling the whole perimeter at once. This page gives both sides.
The five differences, from the most decisive to the finest
Ranked by the size of the gap they create on a four-agent project. The first two alone account for most of the discount.
-
Commissioning work, done once instead of four times
Scoping, connecting to your software, training users and steering are the heaviest items of any rollout. In a team they are carried out once for the whole, on a single perimeter and with the same people.
Trade-off: this assumes the four agents really do serve the same perimeter. Four agents spread across three departments have little to pool, and the gap narrows accordingly.
-
On-site hardware: one machine, not four
In the 100 % Sovereign option the installation is physical. A team shares one machine sized for it; four separately installed agents mean four installations, four commissionings and four maintenance points.
Trade-off: a shared machine is a shared point of failure. Sizing and recovery must be settled during scoping, not afterwards.
-
One invoice and one point of contact
The team is ordered, invoiced and monitored as a single whole. For a purchasing department or a finance director, that means one commitment to process instead of four, and one consumption report to reconcile.
For a public buyer it also means a single requirement value to estimate — see the note on the procurement threshold below.
-
The pace of the rollout
Separate agents are ordered one after another: you test the first, then decide on the second. A team starts as one block, which is faster but requires the perimeter to be settled beforehand.
If the requirement is not stable, starting with a single agent is often wiser — and the audit lets you check that before committing.
-
Stopping, agent by agent
An agent ordered on its own stops on its own, at the end of its own commitment. Within a team, removing an agent changes the whole: perimeter, machine sizing and monitoring are all revisited.
Reversibility itself does not change: what is exported, in what format and how quickly is identical in both cases.
Separately or as a team: what changes, item by item
| Item | Four separate agents | One team of four |
|---|---|---|
| Requirement scoping | Once per agent | Once, for the whole |
| Connection to your software | Once per agent | Once, shared connectors |
| User training | One session per agent | One session for the team |
| Steering and review meetings | One per agent | A single review |
| On-site machine (100 % Sovereign) | One per agent | One for the team |
| Invoicing | Four lines, four due dates | A single invoice |
| Stopping one agent | Immediate, no effect on the others | Team perimeter revisited |
That is where the gap comes from, and nowhere else: scoping, connection, training and steering are done only once — and on site, you install one machine, not four. Nothing is given away from the margin: what falls is what is no longer done twice.
What is included and what is rebilled at cost
| Item | Included in the published price | Rebilled at cost |
|---|---|---|
| Scoping, connection, training | Yes | No |
| Human supervision and monitoring | Yes | No |
| Agent updates | Yes | No |
| Model token consumption | No | Yes, at observed cost |
| On-site hardware (100 % Sovereign) | Depends on the option chosen | No |
| Work outside the perimeter | No | By quotation, never without written agreement |
Token consumption is rebilled at cost, with no margin: it is the item that varies with your usage, and the only one we cannot state in advance. An observed monthly order of magnitude is given during scoping, and presented as such.
When separate agents remain the better choice
A comparison page that never concluded against the more expensive option would not deserve to be read. Here are the cases where we advise against a team.
- The requirement is not stable: you are still looking for where the agent adds most, and priorities may change within three months.
- The agents under consideration serve different departments, with different software and different people: there is almost nothing to pool.
- You want to test the method before committing to a broad perimeter — starting with one agent is slower, but reversible without discussion.
- The budget has to be committed in stages, across several financial years, for reasons that belong to your organisation rather than to the technology.