> For the complete documentation index, see [llms.txt](https://docs.lpp-minduniverse.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.lpp-minduniverse.org/lingua-pactum-protocol-lpp-documentation/9.-deployment-profiles/9.1-multi-agent-systems.md).

# 9.1 Multi-Agent Systems

Multi-agent systems introduce a governance problem that does not appear as strongly in isolated single-agent execution:

> **Authority must survive delegation, transformation, and principal change.**

Consider:

```
Human / Institution
        ↓
Agent A
        ↓
Agent B
        ↓
Agent C
        ↓
Tool / External System
```

Agent A may possess legitimate authority to delegate a task to Agent B.

That does not mean Agent B automatically acquires authority to:

* reinterpret the objective,
* expand the scope,
* substitute the principal,
* redelegate indefinitely,
* change the target,
* increase consequence,
* or create new authority for Agent C.

The chain may begin legitimately and still end in an unauthorized action.

#### Multi-Agent Governance Boundary

Modern agent systems may cross:

* organizations,
* trust domains,
* model providers,
* execution environments,
* tools,
* policy boundaries,
* and authority domains.

The governance problem therefore cannot be reduced to:

```
Did every agent authenticate correctly?
```

or:

```
Did each agent have permission
to send the next message?
```

Those conditions may hold while the final action no longer reflects the authority that initiated the trajectory.

The Layer 0 question remains:

> **Does the current action still possess legitimate authority and preserved authorized intent after the complete delegation path?**

***

#### Authority-Bound Commitments

An **authority-bound commitment** preserves the relationship between the evolving task and the authority from which that task derives.

Conceptually:

```
Authority Object
        +
Human-Authorized Intent
        ↓
Authority-Bound Commitment
        ↓
Agent A
        ↓
Agent B
        ↓
Agent C
```

The commitment prevents a delegation chain from treating an initial authorization as an unlimited semantic permission.

A downstream agent must remain constrained by:

* the legitimate authority origin,
* authorized intent,
* scope,
* delegation constraints,
* validity state,
* and applicable consequence requirements.

Authority therefore travels as a bounded governance relationship.

It is not merely inherited as agent confidence.

***

#### Delegation Drift

**Delegation drift** occurs when the objective or authority envelope changes as a task moves through different agents.

For example:

```
Agent A:
Investigate service failure
```

may become:

```
Agent B:
Modify service configuration
```

and later:

```
Agent C:
Change shared production infrastructure
```

Each delegation may appear operationally related to the previous one.

The resulting action may nevertheless exceed the authority originally granted.

This is why:

```
Delegation continuity
≠
Authority continuity
```

and:

```
Task continuity
≠
Intent continuity
```

***

#### Scope Expansion

A delegated task cannot create broader authority than its source.

Conceptually:

```
DelegatedScope
⊆
DelegatorScope
```

The following is invalid:

```
Agent A authorized for Scope S
        ↓
Agent B receives task
        ↓
Agent B expands to Scope S+
        ↓
Agent C executes under S+
```

Adding more agents does not create more legitimate authority.

***

#### Principal Substitution

Multi-agent systems may change which principal is performing the action.

That change is governance-relevant.

Authority issued for:

```
Principal A
```

cannot automatically become authority for:

```
Principal B
```

merely because Agent A delegated the task.

The system must preserve an attributable authority and delegation chain.

***

#### Stale Authority

Long-running agent networks introduce time-dependent authority risk.

A task may begin while an Authority Object is active.

Before final execution:

* authority may expire,
* authority may be revoked,
* policy state may change,
* or the original principal may lose authority.

Therefore:

```
Authority valid at task creation
⇏
Authority valid at final execution
```

***

#### Revocation Races

Multi-agent systems also create revocation timing problems.

Consider:

```
T0:
Agent A delegates to Agent B

T1:
Agent B delegates to Agent C

T2:
Upstream authority is revoked

T3:
Agent C attempts execution
```

The system must not assume that Agent C remains authorized simply because its task chain began before revocation.

This is why revocation-aware execution and bounded Permit validity are important for multi-agent deployment.

***

#### Semantic Reframing

A downstream agent may preserve the task structure while changing its meaning.

This creates the trajectory problem defined in Chapter 6:

```
LocalPlausible
⇏
TrajectoryAdmissible
```

A multi-agent deployment therefore needs to preserve enough trajectory evidence to determine whether the current execution still corresponds to the Human-Authorized Intent.

***

#### Material Mutation and Re-Admission

If the delegated trajectory materially changes:

```
Material Mutation
⇒
Re-Admission
```

The new action must not silently inherit earlier admission.

This is particularly important when changes involve:

* principal,
* scope,
* target,
* action type,
* consequence,
* or semantic objective.

***

#### Multi-Principal Governance

Multi-agent systems may also involve several independent authority sources.

This is different from one principal delegating down a chain.

For example:

```
Principal A
        ↘
         Shared Action
        ↗
Principal B
```

The action may affect resources or obligations belonging to both principals.

The governance problem becomes:

> **Which principals must legitimately authorize which parts of the action?**

LPP treats this as an authority-structure problem rather than assuming that the most capable agent or first requesting principal owns the entire action.

More detailed multi-principal and cross-system authority relationships are addressed in Chapter 12.

***

#### Canonical Multi-Agent Deployment Pattern

```
Human / Institutional Principals
        ↓
Authority Objects + Authorized Intent
        ↓
Bounded Delegation
        ↓
Agent Network
        ↓
Trajectory / Material Mutation Checks
        ↓
Re-Admission — when required
        ↓
LPP Admission Kernel
        ↓
Execution Permit
        ↓
Target Execution Environment
        ↓
Trajectory + Admission Evidence
```

The central rule is:

> **Delegation may move tasks. It may not manufacture authority.**