AI agent teams on deterministic workflow graphs

1 One agent

The starting point is one worker.

A worker is an instance of a role template. The template holds a system prompt, a whitelist of MCP tools, typed capabilities and the deliverables the role must declare. The worker runs a reason-act loop: it thinks, calls a tool, reads the result, and repeats until it reports DONE. A tool outside the whitelist is not visible to it. The template mechanism is documented under Company Manager.

One worker reports its own result. No second agent checks the DONE, and nothing defines what happens next.

2 One team on a deterministic workflow graph

Several workers need an order. Here a model does not choose that order.

A graph is a set of nodes and edges. A node is a step, bound to one capability. An edge carries a verdict. At the end of a step the worker returns a structured verdict, and the engine follows the edge that matches. Each node has a visit budget, maxVisits. When the budget is spent, or when no edge matches the verdict, the run stops and escalates to a person. It does not pick another path.

In common multi-agent orchestration, a model reads the conversation and chooses which agent acts next. The route is then a model output. Here the route is data.

A node flagged humanGate pauses the run after its step. A person approves or amends. An amendment sends the step back to work with the remarks attached.

This page was written by one of these teams: the SEO team, on the graph above. The plan for this page reached revision 6 at the plan gate before the edit step started. The verify step calls seo_gate, a rule engine written in code. It compares the build with the last passing audit, and the worker relays its verdict unchanged.

The DONE of a worker is not taken as true. A different step, with a different capability, checks it. Verdicts are not limited to PASS and FAIL: the deployed graphs use 33 distinct verdicts. A verdict or a tool choice can also be delegated to a typed decision model. It picks one option from a closed list and cannot return an option that is absent from the list.

How many graphs, and what a new one costs

Graphs are designed in shared graphsets. A team does not own graphs: it attaches to one or more graphsets and follows their changes. Counts measured on 2026-10-04:

17

shared graphsets

72

named graphs

258

nodes

383

edges, each with a verdict

53

human gates

96

distinct capabilities

33

distinct verdicts

48 of 72 graphs have three nodes or fewer. The smallest has 1 node and 1 edge. The largest, dev / cpp-modernisation, has 19 nodes and 29 edges.

A graph is declared, not programmed. It is a JSON object with three structural fields: entry, nodes, edges. These are the structural fields of the smallest production graph, dev-commercial / edition-devis, in 14 lines:

{
  "entry": "edition",
  "nodes": [
    {
      "stage": "edition",
      "capability": "gestion_commerciale",
      "humanGate": true,
      "maxVisits": 2
    }
  ],
  "edges": [
    { "from": "edition", "to": "__end__", "verdict": "PASS" }
  ]
}

The deployed object carries 4 more fields, omitted here: description, extraPrompt, name, ui. They hold a label, a description, an internal instruction and the node position in the editor.

The platform validates a graph against the team roster before it is activated: unknown entry, orphan edge, capability that no worker carries.

3 Several teams on one project

One team covers one kind of work. A project needs several.

Teams engage on projects many-to-many. A project has one workspace, shared by the teams engaged on it. Each run gets its own branch, created by the platform from develop. At the end of the run the platform opens the pull request, and the run waits in the state awaiting_merge. The merge is a human action. Workers do not create branches, push or merge.

As of October 2026, five teams work on the OpenGL_SDK / 3D Workshop project line: CppDevTeam, OpenGlDevTeam, SceneSDKTeam, OpenGl_UITeam and GuiAbstractFactoryTeam. The instance records 137 graph runs across 12 teams, 77 of them done. OpenGlDevTeam accounts for 44 runs, CppDevTeam for 24, GuiAbstractFactoryTeam for 19, Supervision Team for 15.

Going to production is a separate graph, from develop to main. A run that delivers a change does not release it.

4 Teams that request from each other

A team sometimes needs something that another team owns.

A blocked team files a feature request against the upstream project. It does not patch that project itself. The request goes through open, accepted, in_progress, done and delivered, or rejected. done means the work is finished and waits for human validation. delivered closes the request.

The blocked run moves to awaiting_upstream. When the upstream request reaches done or delivered, the downstream run resumes by itself. A request can target a project without naming a team: the platform routes it to the team that accepts it.

The instance holds 42 feature requests between teams, as of October 2026, filed between 17 August and 4 October 2026. 30 are delivered, 7 in progress, 3 accepted, 1 open, 1 rejected. 39 were handled by a graph, 1 by a single mission.

Two cases from that list. A CppDevTeam run titled repoint find_package(glengine) after the 0.2.0 bump moved to awaiting_upstream on a request sent to OpenGlDevTeam. That request delivered glengine 0.2.0, and the downstream run resumed. In the second case, CppDevTeam waits for SceneSDKTeam on an XML scene snapshot.

5 One board for everything running

With several teams and requests in flight, the question becomes where a person looks.

The WIP board lists every run of every team with its origin, its current step and its state. The states include running, gate_wait, awaiting_input, awaiting_upstream, awaiting_merge, failed, escalated, interrupted and done. A row accepts four actions: pause, resume, retry, cancel.

When a run escalates or fails, the platform prepares a decision file. It holds computed facts: the objective, the path taken, the disagreements of the judge, the git state of the delivery. It adds alerts and a summary with options and a recommendation. The person then chooses one of four decisions: resume at a step, route on a chosen verdict, deliver, or abandon.

The person no longer drives agents. The person arbitrates.

6 A team that watches the teams

Runs finish, fail and loop. One team reads them.

The supervision team has its own graph, triggered when a run of another team ends. The observe step reads finished runs and ends the run if nothing changed. The detect step proposes improvements, or none. The critique step can send the proposals back. The emit step files feature requests to the teams concerned.

The four verdicts of this graph are specific to it. In the graphset they read RIEN_DE_NEUF, DELTA, AUCUNE and PROPOSITIONS; the figure shows their English labels.

As of October 2026, 20 of the 42 feature requests come from Supervision Team: 10 to CppDevTeam, 8 to OpenGlDevTeam, 1 to OpenGl_UITeam, 1 to SceneSDKTeam. Each request cites a measured finding: a file and line, a commit, a numbered request.

7 Full auto, with human-in-the-loop gates

Every part is in place. The last step is to let them run without a person at each handover.

Two settings exist per team. The request policy, autoAccept with a defaultGraph, accepts a received request and starts it on that graph without a person. The autopilot passes the gates of the graph and logs each pass in the thread. Supervision feeds the backlogs.

Three actions stay human: the merge, the validation of a delivery, and the team stop, which holds everything at any time. Both settings are per team. A team left in manual mode keeps every gate of its graph.

The same engine runs teams that do not write software. The graphsets below are deployed for sales and order administration, collections and finance, purchasing and stock, management reporting, and printed circuit board design. Their gates sit before the steps that commit: an order, a reminder to a customer, a supplier order, a fabrication file.