> 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/12.-interoperability-and-standards/12.3-agent-protocol-integration.md).

# 12.3 Agent Protocol Integration

LPP is intended to coexist with agent communication and coordination protocols.

The architectural separation is:

```
Agent Protocol
=
How agents communicate / exchange work

LPP
=
Whether a resulting consequential action
has legitimate authority to proceed
```

The two functions are complementary.

#### A2A

An agent-to-agent protocol may enable heterogeneous agents to:

* discover one another,
* exchange tasks,
* communicate state,
* delegate work,
* and coordinate execution.

Those functions do not themselves answer the LPP question:

> **What legitimate upstream authority makes this downstream action admissible?**

A canonical integration may therefore look like:

```
Principal
        ↓
Authority Object + Authorized Intent
        ↓
Agent A
        ↓
A2A / Agent Protocol
        ↓
Agent B
        ↓
Action Candidate
        ↓
LPP Admission Kernel
        ↓
Permit
        ↓
Execution
```

The transport may carry governance references.

It does not become the constitutional authority layer.

#### Other Agent Protocols

The same principle applies to other agent communication, tool, or orchestration protocols.

An external protocol may provide:

```
Transport
Identity
Authentication
Authorization
Capability Exchange
Tool Description
Task Exchange
```

while LPP provides:

```
Authority Semantics
Intent Binding
Constitutional Admissibility
Permit Semantics
Governance Evidence
```

#### MCP and Tool-Oriented Protocols

Tool-oriented agent protocols may determine whether a client can access or invoke a particular resource or tool.

That remains important.

LPP adds the upstream distinction:

```
Authorized to access Tool T
```

does not necessarily mean:

```
This specific use of Tool T
is constitutionally admissible.
```

The integration relationship is therefore:

```
Protocol Authorization
        ↓
Can this principal access the capability?

LPP Admissibility
        ↓
Does this specific action have legitimate authority
and preserved intent?
```

#### LPP Does Not Replace Transport

LPP does not define itself as a replacement for:

* A2A,
* MCP,
* message buses,
* RPC,
* API protocols,
* workflow engines,
* or other transport / orchestration systems.

The canonical positioning is:

> **LPP may travel over an agent protocol. It does not need to replace that protocol.**

#### Governance Metadata

An agent protocol integration may need to carry references to governance objects such as:

* authority identifier,
* authorized-intent commitment,
* principal identity,
* scope,
* delegation information,
* admission reference,
* Permit reference,
* or Artifact reference.

GitBook v2.0 does not yet define one mandatory wire format for all agent protocols.

That is a future interoperability task.

#### Protocol Boundary

The key separation is:

```
Communication Success
≠
Authority Validity
```

```
Authenticated Agent
≠
Admissible Action
```

```
Valid Transport Message
≠
Constitutional Legitimacy
```

Agent interoperability must not become a path for authority bypass.

***