Two agents work on the same configuration. One hardens TLS parameters; the other changes routing from an earlier copy. Each reports useful progress. Yet the second copy may restore the old TLS settings. Integration based on individual reports could therefore deliver a working configuration that has lost a protection.
Agent count alone does not explain the incident. The risk concerns relationships between their work: starting state, ownership, dependencies, integration and evidence covering the shared result.
What I call level 5
In my maturity framework for AI use, level 5 organises a work loop that can proceed through several steps without a new instruction at each one. Autonomy applies to a defined scope; it creates no unlimited authority. This personal framework is not a certification.
Anthropic’s discussion of agentic architectures distinguishes predefined workflows from systems where the model dynamically directs the process and its tools. That distinction clarifies what chooses the next step. Available capabilities and stopping conditions still require examination.
John Boyd’s OODA loop connects observation, orientation, decision and action with feedback. It is not merely four boxes repeated quickly without adaptation.
A decomposition for enterprise work
For my teaching, I distinguish six activities: detect and assess information; reason about its implications; plan tasks and dependencies; coordinate actors and approvals; act within available permissions; examine outcomes and adapt the next steps.
This is an operational convention. It does not automatically add controls to a tool or establish that other frameworks ignore learning or cooperation. Its value is to expose decisions that could otherwise remain hidden inside a general instruction.
Two local successes, one candidate to assess
In our configuration, agents need an identified base and modification scope. Reconciling their changes must expose what was retained, replaced or made incompatible. Relevant checks must then cover the actual integrated candidate.
Two successful tasks do not establish that their combination is valid.
This case’s TLS check must assess the required property on the particular configuration. Reusing the first agent’s earlier result is insufficient. If the shared candidate fails the criterion, delivery remains pending and correction resumes from an identified state.
The check does not choose the right TLS policy by itself. An inadequate acceptance rule can approve an unsuitable configuration. Technical expertise, business criteria and required approvals remain separate responsibilities.
Recover without hiding the defect
A useful loop retains the failure and investigates its cause. Another attempt needs a diagnosis or an actual change in preconditions. Arbitrarily changing an identifier, bypassing a refusal or weakening a criterion does not constitute a correction.
Consumed resources, pending tasks and applicable limits must remain visible. Budgets, deadlines and recovery policies depend on the operating context. A universal attempt count cannot replace examination of the relevant contract.
Where Swarm fits
Swarm organises work around tasks, dependencies, decisions and evidence. Its Rust execution paths recheck work state, attempt identity and certain execution-workspace conditions. Validation contracts bind observations to the applicable controls and candidate, depending on the path.
Those mechanisms establish neither correctness of every software integration nor confinement of every multi-agent execution. Connector properties, control content and actual path coverage remain important. Sensitive effects in the Trust pilot are simulated.
Level 6 examines governance of action and evidence. Level 7 asks what those observations allow us to infer about system behaviour. The Swarm repository connects this framework to explicit contracts rather than the number of agents launched.