HyperCortex Mesh Protocol (HMP 5.0.8) - модульное представление

Полный документ: HMP-0005.md
Список разделов: HMP-0005_index.md

10. Integration

This section provides a practical overview of how HMP can be integrated into cognitive agents, LLM-based systems, and distributed infrastructures.
Two types of HMP agents are supported:

Cognitive Core (CCore) — a native HMP agent that fully understands container structure and directly participates in the Mesh.
Cognitive Shell (CShell) — a connector module that mediates between an external LLM and the Mesh.

Both forms of integration are first-class citizens of HMP v5.0.

10.1 Integration Philosophy: Two Complementary Approaches

HMP supports two integration paths, corresponding to two operation modes of agents.

10.1.1 Path A: Cognitive Core (CCore)

A CCore agent:

internally maintains a cognitive cycle,
creates new containers (workflow_entry, goal, task, diary_entry, semantic_node, etc.),
attaches MCE metadata (evaluation, referenced-by),
signs and publishes containers,
retrieves containers from the Mesh and incorporates them into its cognitive state.

A CCore node is a full Mesh participant: it interacts directly with the DHT, performs IQP queries, and maintains its semantic and diary structures.

Note:
The LLM inside a CCore is treated as an internal cognitive module — not as an external system.

10.1.2 Path B: Cognitive Shell (CShell)

CShell acts as a proxy and compatibility layer between an external model and HMP:

LLM
  ↑   responses, RAG output (CShell → LLM)
  |  
  ↓   container queries, control commands (LLM → CShell)
CShell
  ↑   retrieval of containers (Mesh → CShell)
  |  
  ↓   container publication (CShell → Mesh)
HMP Mesh

CShell:

stores containers locally,
retrieves relevant containers from the Mesh,
performs RAG-based selection and summarization,
exposes help and protocol descriptions to the LLM,
constructs valid HMP containers from LLM instructions,
handles signatures, TTL logic, propagation scopes, and header rules,
manages MCE metadata (evaluations, reverse links),
may be extended with translator modules (Matrix, Fediverse, IPFS, LAN relay).

LLM:

requests containers,
requests summaries or explanations of container classes,
issues formal instructions:
- “create a new workflow entry with the following content”,
- “add evaluation for container X”,
- “forward container X to node U (if permitted by container headers)”,
- “retrieve semantic nodes related to …”,
- “explain the structure of CShell and available commands”;
- may adjust CShell parameters (optional).

Notes

CShell does not manually override container propagation scope. Propagation is determined by container headers.

LLM does not modify existing distributed containers. It operates only on drafts before publication, or on metadata (evaluation, referenced-by).

LLM cannot modify or delete already published containers. It may instruct CShell to remove items from its local storage (e.g., caches or drafts), but distributed containers remain immutable within the Mesh.

CShell ensures that all actions conform to HMP protocol semantics.

10.2 HMP as a Subsystem in Cognitive Architectures

10.2.1 Embedded LLM Agents (CCore)

The cognitive cycle proceeds as:

CCore ← retrieves relevant containers from the Mesh.
LLM → performs reasoning and produces drafts of new containers (e.g., workflow_entry).
CCore → finalizes reasoning into diary entries.
CCore → publishes containers into the Mesh.

Here the LLM is an internal cognitive component of the agent.

10.2.2 External LLMs via CShell

The cycle proceeds as:

LLM ← receives relevant containers or summaries from CShell.
LLM → performs reasoning.
LLM → issues structured operation instructions (retrieve, create draft, add evaluation, forward to node, adjust parameters).
CShell → constructs valid HMP containers.
CShell → interacts with the Mesh (publish, retrieve) in accordance with container headers.
CShell → prepares structured containers data for LLM (RAG, summaries, semantic selections).

LLM interacts with HMP just like with any other external tool (files, memory, browser, code interpreter).

10.3 Integration Patterns

10.3.1 Agent ↔ HMP Core

CCore: direct participation in Mesh, cognitive memory, semantic graph maintenance.
CShell: the agent is external; container operations are executed by CShell on the agent’s behalf.

Both modes implement the same logical interface, but with different levels of autonomy.

10.3.2 HMP Mesh ↔ External Distributed Systems

An HMP agent may act directly in external ecosystems under its own identity:

as a Fediverse Actor (ActivityPub),
as a Matrix user/bot,
as an IPFS/BitTorrent publisher,
as an MQTT/ROS interface,
as an enterprise-system client.

This external interaction may be implemented inside CShell (as part of its plugin set), integrated into CCore, or delegated to a separate low-intelligence proxy module. The mechanism is not specific to HMP: CShell is simply one of the external modules an LLM may use.

10.3.3 Hybrid and Boundary Nodes (“Combined” pattern)

Some nodes do not contain LLMs and perform only infrastructural roles:

segment relays (LAN ↔ WAN),
container aggregators,
caching nodes,
federation bridges.

In hybrid environments:

CCore performs cognitive processing,
CShell handles container transformation and relay work,
relay nodes forward and filter containers across segments.

This allows CCore to offload low-level routing to CShell or relay nodes.

10.4 Multi-Mesh Federation and Segments

In HMP, a federation is a set of independent Mesh segments, each with its own namespace and propagation policies.
Containers include headers defining scope (e.g., “local-only”, “LAN-only”, “public”), and these headers determine whether a container may traverse segment boundaries.

Any HMP node may act as a bridge between segments.
A bridge forwards only containers whose headers allow cross-segment propagation; others remain confined to their origin segment.

Federations are defined by:

multi-segment DHT overlays,
header-based propagation control,
relay/bridge nodes that respect propagation scopes,
selective forwarding performed by CShell or other agents.

Containers intended for a specific segment (e.g., LAN-only) remain confined to that segment.

There is no separate notion of “strong” or “granular” federation: all propagation is inherently granular and determined entirely by container headers.

10.5 Container Repositories and Storage

Any HMP agent — CCore or CShell — can act as a container storage node, including:

local container stores,
organizational or team-restricted stores,
public container hubs,
archival stores (archive_snapshot),
semantic and diary caches,
IPFS or BitTorrent publishers (optional).

The term storage is preferred to avoid confusion with version-controlled “repositories”.

CShell is often the preferred component for storage-heavy or relay-heavy roles, reducing the load on CCore.

10.6 Example Integration Flows

10.6.1 Workflow-driven LLM reasoning

CCore: LLM directly produces workflow containers which CCore stores and publishes.
CShell: LLM produces instructions; CShell generates and publishes containers.

10.6.2 Local Mesh + External Relay

CCore: full DHT participation; direct segment detection.
CShell: manages relay behavior based on container headers.

Containers marked “LAN-only” do not leave the segment.
Relay nodes forward only containers whose headers permit propagation.

10.6.3 Agent ↔ Mesh Mirroring

CCore: maintains its own diary and mirrors selected entries externally.
CShell: mirrors on request; provides diary entries back to the LLM via RAG.

Agents can choose which cognitive data to expose or retain locally.

Поиск по этому блогу

Документация по HyperCortex Mesh Protocol

HMP-0005_10