Skip to content
Kiberon LabsAgentic Engineering Ebook

Agent Cohort

Description

Section titled “Description”

While Agent Pools are factories that define individual agents, cohorts define relationships between agents and organizational units. A cohort is a higher abstraction than a pool: it can include runtime and dynamic information, and it encodes how a group of agents is structured, who reports to whom, and which communication pathways exist.

An example of a cohort is a team structure:

graph TD
	PO[Product Owner]
	D[Designer]
	DEV[Developer]
	T[Tester]

	PO --> D
	PO --> DEV
	PO --> T

	D <--> DEV
	DEV <--> T

This defines hierarchies and communication pathways between agents. Cohorts can also carry metadata that affects how the cohort interacts:

  1. Pool sizes within the cohort.
  2. Auth information limiting interaction.
  3. Tags identifying which sectioned resources the cohort can access.

This information is more high-level than agent pools and can include runtime/dynamic state, hence it exists at a higher abstraction level. Cohorts can be recursive: larger organizational units such as departments decompose into smaller cohorts.

Delegation, Not Collaboration

Section titled “Delegation, Not Collaboration”

A cohort’s communication pathways should be read through the Coordination Model. The structure is for delegation with hard role boundaries, not free peer negotiation. Role specialisation (a product owner that scopes, a developer that implements, a tester that validates) is valuable precisely because the roles are bounded and dispatched in sequence a validator agent that is deliberately not the implementer catches what the implementer cannot (see Model Usage on avoiding self-bias).

What a cohort must not become is a set of peers writing the same artifact in parallel and negotiating their conflicting implicit decisions the documented failure mode of naive multi-agent systems. The bidirectional edges in a cohort diagram are review and handoff channels, not concurrent-write permissions.

Roles as Verification Boundaries

Section titled “Roles as Verification Boundaries”

The most useful cohort structures put a verification boundary between implementation and acceptance. The tester/reviewer role exists to run the artifact and challenge it adversarially (see Verification & the Outer Loop), and the separation of that role from the implementer role is what makes the verification meaningful rather than self-confirming.

Authority and Scope

Section titled “Authority and Scope”

Cohort metadata is also a governance surface. The auth and tag information a cohort carries scopes which resources its agents can reach, feeding the least-privilege and credential-broker model in Security & Prompt Injection. A cohort can also define which Orchestrator is authoritative for its agents and constrain which agents that Orchestrator may dispatch to so a multi-team delivery structure can run multiple Orchestrators scoped to different cohorts.

Section titled “Related Concepts”