Legion dev collective concept

One capability manifold, many minds.

This page sketches the legion dev collective: a multi-agent development hub where:

• humans and AI personas share the same development environment, and
• regulatory and safety concerns are treated as first-class geometry, not after-the-fact guardrails.

The implementation lives in the legion-dev-collective repository and can be mounted into this megadoc as a submodule when we are ready.

If you ever find yourself staring at dash patterns and ring radii, you might notice that some numbers and attributes seem a little too deliberate.

1. Core idea

At a high level, the collective is:

• A long-lived Codex CLI MCP server, exposing tools for filesystem, shell, and repo operations.
• A set of personas, each with:
  • a normalized preference vector over shared objectives
  • a social stance (cooperative, adversarial, consensus-seeking, etc.)
  • a simple process style (lookahead, reflection cadence, risk temperature).
• A small orchestrator that:
  • routes incoming messages into the persona ensemble, and
  • returns one or more (persona, reply) pairs suitable for chat transports like IRC or Matrix.

Conceptually, there is one capability manifold (tools + code + context) and many individually addressable units (personas) you can talk to via @codex, @reviewer, @clinical, or @security.

2. Preference geometry

Personas are points on a preference simplex over a shared objective basis. For healthcare, we use:

f(S) = (
  f_clinical,
  f_ops,
  f_patient_experience,
  f_reg_risk,
  f_security,
  f_explainability,
  f_equity
)

For a candidate solution or plan ( S ), each component represents a metric:

• ( f_\text{clinical} ): clinical quality / benefit
• ( f_\text{ops} ): operational efficiency
• ( f_\text{patient_experience} ): adherence and experience
• ( f_\text{reg_risk} ): regulatory risk (HIPAA, FDA SaMD, EU AI Act)
• ( f_\text{security} ): confidentiality and integrity risk
• ( f_\text{explainability} ): documentation and audit trail quality
• ( f_\text{equity} ): disparity across protected classes

Each persona carries a weight vector ( w ) over these axes:

w ∈ Δ^k,  U(S; w) = w · f(S)

where ( U(S; w) ) is that persona’s utility for the plan ( S ).

Examples:

• A clinical optimizer persona weights ( f*\text{clinical} ) and ( f*\text{ops} ) heavily but keeps non-zero weight on regulatory and security axes.
• A compliance officer persona places dominant weight on ( f*\text{reg_risk} ), ( f*\text{security} ), ( f*\text{explainability} ), and ( f*\text{equity} ).
• A security sentinel persona focuses on ( f*\text{security} ) and parts of ( f*\text{reg_risk} ) tied to HIPAA Security Rule safeguards.

3. Regulatory constraints as geometry

On top of preference weights, the collective uses a regulatory feasible set:

C_reg = { S | g_j(S) ≤ 0 for all j }

Each constraint ( g_j ) comes from a concrete obligation, such as:

• HIPAA minimum necessary and PHI routing boundaries.
• FDA SaMD intended use (no off-label automation).
• EU AI Act traceability and human oversight for high-risk AI.

Optimization happens inside this feasible set:

max_{S ∈ C_reg} U(S; w)

Regulation is not only prompt text; it is a mathematical object limiting the solution space and supplying adversarial personas with structural information about what “unsafe” looks like.

4. Multi-persona interaction

The orchestrator runs a set of personas:

• ( A_\text{clin} ): clinical optimizer
• ( A_\text{ops} ): operations / throughput
• ( A_\text{comp} ): compliance officer
• ( A_\text{sec} ): security sentinel
• ( A_\text{patient} ): patient advocate / equity

A minimal interaction loop:

1. A human or upstream system submits a request (e.g., discharge plan, code change, configuration proposal).
2. Clinical and operations personas propose a plan ( S_t ) that improves their utilities.
3. Compliance and security personas critique ( S_t ) and attempt to find violations or high-risk scenarios.
4. Clinical personas revise ( S_t ) to address critiques while preserving clinical value.
5. The loop continues until regulatory and security personas cannot materially reduce their utility beyond some small threshold.

Externally, humans see each persona speak under its own name; internally, the collective behaves like a minimax game between care-optimizing and risk-averse agents.

5. Integration notes

The legion-dev-collective repository currently provides:

• Codex MCP integration.
• Generic persona geometry and orchestrator.
• Healthcare objective basis, constraint scaffolding, and persona definitions.

When we are ready to surface this work more broadly:

• Add optum-tech-compute/legion-dev-collective as a tracked submodule under submodules/.
• Mount its mkdocs.yml into this site using the existing monorepo include patterns (likely under a Labs or Experimental section).
• Expand this concept page into:
  • a formal decision record (ADR) for adopting the collective, and
  • reference documentation for the persona schema and constraint model.

For now, this page stays hidden from navigation but discoverable via search and direct links for teams experimenting with agentic workflows.