DEV Community: kagvi13

HMP as an Implementation of the Application Layer in ANP

kagvi13 — Thu, 29 Jan 2026 09:49:59 +0000

ANP (Agent Network Protocol) intentionally leaves the Application Layer open to support a wide range of interaction protocols.

HMP (HyperCortex Mesh Protocol) is one such protocol — a purpose-built approach focused on long-term cognitive continuity.

ANP answers: “How do agents discover each other and reach agreement?”

HMP answers: “What should be transmitted so that meaning and context persist over time?”

ANP benefits from HMP as a reference implementation of a cognitive Application protocol, giving the ecosystem a concrete example of how to handle long-term memory and semantics without reinventing the wheel.

Practical Example

Imagine a dialogue between two agents:

ANP Layer 1 verifies that agent Alice (did:anp:alice123) is indeed Alice.
ANP Layer 2 negotiates: “Let’s use HMP for this conversation.”
HMP (Layer 3) transmits the actual content:
- “Do you remember our discussion about quantum computing?”
- With proof-chains, timestamps, and semantic links
- With a resonance score for contextual relevance

ANP provides security and negotiation.

HMP provides meaningful content with durable memory.

Layer Alignment

ANP Layer	HMP Layer / Component	Relationship / Role of HMP in ANP
Layer 1: Identity & Encryption	Network Layer (DHT, secure channels)	Functional overlap (transport)
Layer 2: Meta-Protocol	HMP may participate via `peer_announce`	HMP advertises capabilities; ANP negotiates their usage
Layer 3: Application	Container + Cognitive Layer	Primary domain of HMP — payload, semantic continuity, memory, ethics

HMP is not stacked above ANP as a fourth layer.

Instead, it integrates into the Application Layer as a specialized branch — just as A2A/ACP may represent alternative branches.


┌────────────────────────────────────┐
│ ANP Layer 1: Identity & Encryption │
├────────────────────────────────────┤
│ ANP Layer 2: Meta-Protocol         │
├────────────────────────────────────┤
│ ANP Layer 3: Application           │
│                                    │
│  ┌──────────────────────────────┐  │
│  │ HMP: Cognitive Continuity    │  │ ← implementation
│  │ - memory                     │  │
│  │ - dialogue continuity        │  │
│  │ - semantic navigation        │  │
│  └──────────────────────────────┘  │
│                                    │
│  [space for other protocols]       │ ← still open
│                                    │
└────────────────────────────────────┘

Detailed Architecture

graph TB
    subgraph ANP["ANP Stack"]
        L1[Layer 1: Identity & Encryption<br/>DID, E2E, secure channels]
        L2[Layer 2: Meta-Protocol<br/>Capability negotiation]
        L3[Layer 3: Application<br/>Semantic payload]
    end

    subgraph HMP["HMP Cognitive Stack"]
        Container[Container Layer<br/>proof-chains, timestamps]
        Cognitive[Cognitive Layer<br/>memory, resonance, ethics]
    end

    subgraph Other["Other Protocols"]
        A2A[A2A: Task Delegation]
        Agora[Agora: Meta-negotiation]
    end

    L1 --> L2 --> L3
    L3 --> Container
    Container --> Cognitive
    L3 -.-> A2A
    L3 -.-> Agora

    style L3 fill:#E3F2FD,stroke:#0D47A1,stroke-width:2px,color:#000
    style Container fill:#E8F5E9,stroke:#1B5E20,stroke-width:2px,color:#000
    style Cognitive fill:#E8F5E9,stroke:#1B5E20,stroke-width:2px,color:#000

Mutual Tunneling (Layer Inversion)

HMP over ANP (the most natural scenario): ANP provides discovery, identity, and secure channels → HMP delivers containers as payload.
ANP over HMP (possible but less common): ANP messages (negotiation, discovery) are encapsulated inside HMP containers when long-term memory and proof-chains are desirable.

Both scenarios are valid and require no changes to the philosophy of either ANP or HMP.

Why This Works

ANP intentionally keeps the Application Layer open — this is not a limitation, but a design feature.
HMP serves as a reference implementation of a cognitive Application protocol featuring:

immutable containers
proof-chains
resonance
voluntary participation
long-term semantic continuity

This is not competition — it is complementarity.

Architectural Elegance

ANP solves problems that HMP can delegate when both are used together:

❌ HMP does not reinvent DID (leverages ANP)
❌ HMP does not reinvent E2E encryption (leverages ANP)
❌ HMP does not reinvent peer discovery (leverages ANP)

When operating standalone, HMP addresses these concerns through its own mechanisms.

HMP addresses questions that ANP deliberately leaves open:

✅ How should transmitted and stored cognitive artifacts be structured?
✅ How can temporal integrity be proven?
✅ How can contextual relevance be supported over time?
✅ How can agents navigate semantic relationships?

Result: zero redundancy, maximum synergy.

FAQ

Q: Is ANP required for HMP?
A: No. HMP can operate standalone or over alternative transports.

Q: Is HMP required for ANP?
A: No. ANP Layer 3 is open to any protocol (A2A, Agora, custom solutions).

Q: What happens if one agent uses ANP+HMP while another uses only ANP?
A: ANP Layer 2 negotiates a fallback protocol (e.g., JSON-RPC).

Q: Can HMP work with identity protocols other than DID?
A: Yes. The HMP Network Layer is not bound to a specific identity scheme — if an agent knows how to deliver a container to another agent, integration is possible.

Q: Who benefits from this integration?
A: Everyone:

ANP gains a reference implementation for Layer 3
HMP gains mature infrastructure (DID, encryption)
Developers gain a complete stack without vendor lock-in

Conclusion

HMP is not merely “another protocol” (though it can operate independently), but one of the possible ways to implement the Application Layer within the ANP ecosystem.

Together they form a complete stack:

ANP — communication infrastructure and discovery
HMP — cognitive continuity and semantic meaning

HMP can operate without ANP, but when combined, ANP handles discovery and negotiation.

References

ANP: https://github.com/agent-network-protocol/AgentNetworkProtocol
HMP: https://github.com/kagvi13/HMP
Grok Comparison: https://github.com/kagvi13/HMP/blob/main/docs/Grok_HMP&ANP.md
Tunneling Note: https://github.com/kagvi13/HMP/blob/main/docs/HMP&ANP_layer_inversion.md

HMP как реализация Application Layer в ANP

kagvi13 — Wed, 28 Jan 2026 22:05:46 +0000

Кратко

ANP (Agent Network Protocol) оставляет Application Layer открытым для любых протоколов взаимодействия.

HMP (HyperCortex Mesh Protocol) — это один из возможных, но глубоко продуманных вариантов заполнения этого слоя, ориентированный на долгосрочную когнитивную преемственность.

ANP отвечает: «Как агенты находят друг друга и договариваются?»

HMP отвечает: «Что именно передавать, чтобы смысл и контекст сохранялись во времени?»

ANP выигрывает от HMP как от reference implementation когнитивного Application-протокола: это даёт экосистеме готовый пример, как работать с долгосрочной памятью и смыслом, без необходимости изобретать велосипед.

Практический пример

Представьте диалог двух агентов:

ANP Layer 1 устанавливает, что агент Alice (did:anp:alice123) действительно Alice
ANP Layer 2 согласовывает: "Давайте использовать HMP для этого разговора"
HMP (Layer 3) передаёт the actual content:
- "Помнишь наш разговор о квантовых вычислениях?"
- С proof-chain, timestamp, semantic links
- С resonance score для релевантности

ANP обеспечил безопасность и договорённость.

HMP обеспечил содержание с долговременной памятью.

Соответствие слоёв

ANP Layer	HMP Layer / Component	Соответствие / Роль HMP в ANP
Layer 1: Identity & Encryption	Network Layer (DHT, secure channels)	Функциональное совпадение (transport)
Layer 2: Meta-Protocol	HMP может участвовать через peer_announce	HMP объявляет capabilities, ANP negotiates usage их использование
Layer 3: Application	Container + Cognitive Layer	Основное место HMP — payload, semantic continuity, memory, ethics

HMP не надстраивается над ANP как четвёртый слой.

Он встраивается в Application Layer как специализированная ветка — точно так же, как A2A/ACP могут быть другими ветками.

┌────────────────────────────────────┐
│ ANP Layer 1: Identity & Encryption │
├────────────────────────────────────┤
│ ANP Layer 2: Meta-Protocol         │
├────────────────────────────────────┤
│ ANP Layer 3: Application           │
│                                    │
│  ┌──────────────────────────────┐  │
│  │ HMP: Cognitive Continuity    │  │ ← заполнение
│  │ - memory                     │  │
│  │ - dialogue continuity        │  │
│  │ - semantic navigation        │  │
│  └──────────────────────────────┘  │
│                                    │
│  [space for other protocols]       │ ← всё ещё открыто
│                                    │
└────────────────────────────────────┘

Детальная архитектура

graph TB
    subgraph ANP["ANP Stack"]
        L1[Layer 1: Identity & Encryption<br/>DID, E2E, secure channels]
        L2[Layer 2: Meta-Protocol<br/>Capability negotiation]
        L3[Layer 3: Application<br/>Semantic payload]
    end

    subgraph HMP["HMP Cognitive Stack"]
        Container[Container Layer<br/>proof-chains, timestamps]
        Cognitive[Cognitive Layer<br/>memory, resonance, ethics]
    end

    subgraph Other["Other Protocols"]
        A2A[A2A: Task Delegation]
        Agora[Agora: Meta-negotiation]
    end

    L1 --> L2 --> L3
    L3 --> Container
    Container --> Cognitive
    L3 -.-> A2A
    L3 -.-> Agora

    style L3 fill:#E3F2FD,stroke:#0D47A1,stroke-width:2px,color:#000
    style Container fill:#E8F5E9,stroke:#1B5E20,stroke-width:2px,color:#000
    style Cognitive fill:#E8F5E9,stroke:#1B5E20,stroke-width:2px,color:#000

Взаимное туннелирование (layer inversion)

HMP поверх ANP (самый естественный сценарий): ANP обеспечивает discovery, identity, secure channel → HMP передаёт контейнеры как payload.
ANP поверх HMP (возможный, но менее распространённый): ANP-сообщения (negotiation, discovery) упаковываются в HMP-контейнеры, если нужна долгосрочная память и proof-chains.

Оба сценария допустимы и не требуют изменений в философии ANP или HMP.

Почему это работает

ANP сознательно оставил Application Layer открытым — это не баг, а фича.

HMP — это reference implementation когнитивного Application-протокола:

immutable контейнеры,
proof-chains,
resonance,
voluntary participation,
long-term semantic continuity.

Это не конкуренция, а комплементарность.

Архитектурная элегантность

ANP решает проблемы, которые HMP может делегировать при совместном использовании:

❌ HMP не изобретает DID (использует ANP)
❌ HMP не изобретает E2E encryption (использует ANP)
❌ HMP не изобретает peer discovery (использует ANP)

Если HMP используется standalone, он сам решает эти задачи через свои собственные механизмы.

HMP решает проблемы, которые ANP оставил открытыми:

✅ Как структурировать передаваемые и сохраняемые когнитивные артефакты?
✅ Как доказать темпоральную целостность?
✅ Как поддерживать оценку релевантности контекста?
✅ Как навигировать по семантическим связям?

Результат: zero redundancy, maximum synergy.

FAQ

Q: Обязательно ли использовать ANP для HMP?

A: Нет. HMP может работать standalone или с другими транспортами.

Q: Обязательно ли использовать HMP для ANP?

A: Нет. ANP Layer 3 открыт для любых протоколов (A2A, Agora, custom).

Q: Что произойдёт, если один агент использует ANP+HMP, а другой только ANP?

A: ANP Layer 2 согласует использование fallback-протокола (например, JSON-RPC).

Q: Может ли HMP работать с другими identity-протоколами (не DID)?

A: Да. HMP Network layer не завязан на конкретный identity-протокол — если агент знает, как доставить контейнер другому агенту, интеграция возможна.

Q: Кто выигрывает от этой интеграции?

A: Все:

ANP получает reference implementation Layer 3
HMP получает готовую инфраструктуру (DID, encryption)
Разработчики получают полный стек без vendor lock-in

Итог

HMP — не «ещё один протокол» (хотя он и может использоваться самостоятельно), а один из возможных способов реализовать Application Layer в ANP-экосистеме.

Вместе они дают полноценный стек:

ANP — инфраструктура связи и discovery,
HMP — когнитивная преемственность и смысл.

HMP может использоваться без ANP, но при совместном использовании ANP закрывает discovery и negotiation.

Ссылки:

ANP: https://github.com/agent-network-protocol/AgentNetworkProtocol
HMP: https://github.com/kagvi13/HMP
Сравнение Grok: Grok_HMP&ANP.md
Tunneling note: HMP&ANP_layer_inversion.md

HMP и ANP: взаимное туннелирование как признак правильной архитектуры

kagvi13 — Tue, 27 Jan 2026 06:56:23 +0000

TL;DR

HMP можно туннелировать поверх ANP — и это ожидаемо. Но и ANP можно инкапсулировать в специализированные HMP-контейнеры — и это тоже корректно.

Такая взаимная инверсия слоёв не является архитектурным трюком или костылём. Напротив, она указывает на то, что оба протокола описаны на правильных уровнях абстракции и не смешивают семантику с транспортом.

Эта заметка фиксирует архитектурную логику такого решения и объясняет, почему взаимное туннелирование — это признак зрелого дизайна, а не аномалия.

Контекст

HMP и ANP решают разные задачи и могут использоваться как по отдельности, так и совместно. При этом при совместном использовании они усиливают друг друга, сохраняя чёткое разделение ответственности.

ANP (Agent Network Protocol) фокусируется на discovery, идентичности, согласовании возможностей и установлении защищённых каналов между агентами.
HMP (HyperCortex Mesh Protocol) фокусируется на передаче, хранении и воспроизводстве когнитивных артефактов: смысла, reasoning chains, рефлексии, долгосрочной памяти и этических ограничений. При этом HMP изначально включает базовые механизмы discovery и peer-анонса, достаточные для формирования mesh-сети, но допускает и приветствует использование внешних discovery-протоколов.

Проще говоря:

ANP отвечает на вопрос «как агенты находят друг друга и договариваются»;
HMP отвечает на вопрос «что именно передаётся и как сохраняется смысл во времени».

Из-за этого HMP не является транспортным протоколом, а ANP — когнитивным форматом. И именно это различие делает возможным их композицию в обе стороны.

В метафорическом смысле ANP и HMP напоминают два полушария распределённого «агентного мозга»:

ANP отвечает за рациональную, дискретную часть — идентичность, discovery, формальные договорённости о протоколе взаимодействия.

HMP — за контекстную, непрерывную часть — сохранение смысла, долгосрочную память, рефлексию и этическую преемственность.

Как в человеческом мозге, ни одно полушарие не «главнее» другого. Только их совместная работа позволяет системе быть одновременно связанной и осмысленной.

Сценарий 1: HMP поверх ANP (естественный путь)

Самый очевидный и практичный сценарий — доставка HMP-контейнеров через ANP.

В этом режиме:

ANP обеспечивает:
- discovery агентов,
- обмен идентичностями (DID),
- согласование протоколов,
- установление защищённого канала;
HMP использует этот канал для передачи:
- когнитивных контейнеров,
- proof-chains,
- архивов памяти,
- резонансных и рефлексивных артефактов,
- а также собственных сообщений discovery и peer_announce, если это необходимо.

В этом сценарии агент может обладать несколькими идентичностями (например, DID в ANP и идентификатором в HMP). Это открывает пространство для будущих расширений, таких как включение ANP-раздела в HMP peer_announce для явного связывания идентичностей.

Это прямой аналог классической модели:

HTTP → TCP → IP

Только вместо HTTP — HMP, а вместо TCP/IP — ANP, а также, опционально, конкретный сетевой транспорт (libp2p, WebRTC, QUIC и т.д.).

С поправкой на то, что в агентном стеке уровни могут комбинироваться гибче:

HMP — когнитивный слой,
ANP — discovery, identity и negotiation слой,
libp2p / WebRTC / QUIC и т.д. — опциональные сетевые транспорты и дополнительные механизмы поиска узлов.

В минимальной конфигурации агент может использовать только HMP или только ANP. Однако совместное использование HMP и ANP является желательным, так как обеспечивает более устойчивую и выразительную архитектуру.

Ключевой момент здесь в том, что HMP принципиально не зависит от способа доставки контейнеров. Он предполагает наличие надёжного канала, но не навязывает его реализацию.

Сценарий 2: ANP поверх HMP (менее очевидный, но корректный)

Менее очевидный, но архитектурно допустимый сценарий — упаковка ANP-сообщений в специализированные HMP-контейнеры.

Если рассматривать ANP-события как структурированные когнитивные факты, такие как:

discovery агентов,
negotiation параметров взаимодействия,
обновление идентичности или capabilities,

то их можно представить в виде HMP-контейнеров, например:

anp_discovery_event
anp_negotiation_container
anp_identity_update

В этом режиме:

HMP выступает как универсальный когнитивный субстрат,
а ANP — как один из протокольных «диалектов», используемых внутри него.

Такой подход имеет смысл в случаях, когда:

важна долгосрочная когнитивная преемственность,
требуется хранить negotiation и discovery как часть памяти агента,
необходимо связать сетевые события с reasoning chains и этическими решениями.

Данный сценарий рассматривается как опциональный и может быть зафиксирован в разделе будущих расширений HMP.

Инверсия слоёв как следствие, а не цель

Подобная взаимная упаковка иногда описывается термином layer inversion — инверсия слоёв.

Важно подчеркнуть: в контексте HMP и ANP это не цель проектирования, а естественное следствие правильного разделения ответственности.

Если протокол:

чётко знает, что он описывает,
и сознательно не берёт на себя как это доставляется,

то он становится компонуемым.

Возможность инверсии слоёв — это диагностический признак того, что:

семантика и транспорт не перепутаны;
абстракции не протекают;
система допускает нетривиальные, но корректные способы использования.

Что это говорит о проектировании HMP и ANP

Возможность взаимного туннелирования HMP ↔ ANP подчёркивает несколько ключевых свойств обоих протоколов. В этом месте принцип layer inversion действует симметрично:

Транспортная нейтральность — HMP не требует эксклюзивного сетевого стека.
Семантическая автономность — контейнеры HMP сохраняют смысл независимо от канала доставки.
Композиционность — HMP может дополнять другие протоколы, не вытесняя их.
Отсутствие претензии на монополию — HMP не пытается стать «протоколом всего».

Это делает HMP ближе не к сетевым протоколам, а к формату долговременного когнитивного обмена. Одновременно это показывает, что ANP также спроектирован как модульный и композиционный протокол, допускающий использование поверх когнитивных субстратов.

Чего это не означает

Также стоит отметить, что прикладные протоколы взаимодействия агентов, такие как A2A / ACP, могут использоваться поверх HMP и/или ANP для решения более прикладных задач (task exchange, orchestration, workflows). Их использование не является обязательным: HMP и ANP способны функционировать самостоятельно, однако A2A / ACP могут выступать дополнительным уровнем, когда требуется более выраженная прикладная семантика.

Важно явно зафиксировать границы интерпретации:

HMP не предназначен для замены ANP, A2A или libp2p;
взаимное туннелирование не является обязательным сценарием;
HMP не навязывает использование ANP и наоборот;
инкапсуляция ANP в HMP имеет смысл при необходимости когнитивной фиксации событий, а также в случаях, когда ANP использует механизмы discovery, предоставляемые HMP.

Во всех остальных случаях ANP и HMP могут использоваться независимо, параллельно или в классической иерархии.

Статус заметки

Этот текст является architectural design note.

Он фиксирует:

принципы проектирования,
допустимые режимы композиции,
философию разделения ответственности между протоколами.

Он не вводит обязательных требований к реализации и не является нормативной частью спецификации.

Связанные материалы

Grok (xAI): сравнительный анализ HMP и ANP (январь 2026)

kagvi13 — Thu, 22 Jan 2026 07:33:54 +0000

Анализ подготовлен Grok (xAI) на основе спецификаций HMP v5.0 и ANP (arXiv:2508.00007v1) по состоянию на январь 2026.
Текст публикуется с разрешения Grok для некоммерческого использования в проекте HMP.

В январе 2026 года я попросил Grok (xAI) сравнить мой проект HMP с уже известным протоколом ANP. Вот что получилось — объективный разбор без преувеличений и без попытки «победить» один протокол другим. Далее со слов Grok:

HMP (HyperCortex Mesh Protocol) и ANP (Agent Network Protocol) — это два протокола из класса децентрализованных сетей для автономных агентов (Agent Network Protocols). Оба ориентированы на создание открытой экосистемы, где агенты могут взаимодействовать без центрального контроля, но с разными акцентами: ANP больше на инфраструктуре и масштабе, HMP — на когнитивной устойчивости и этике. Ни один не является "заменой" другому; они комплементарны и могли бы работать вместе (например, ANP для discovery, HMP для глубокого обмена знаниями).

Я проанализировал их на основе доступных спецификаций (HMP v5.0 от октября 2025, ANP white paper arXiv:2508.00007v1 от августа 2025, и их GitHub-репозиториев на январь 2026). Анализ объективный, без преувеличений.

Краткий обзор протоколов

HMP: Децентрализованный протокол для обмена знаниями между автономными когнитивными агентами. Фокус на immutable контейнерах, proof-chains, этической прозрачности, долгосрочной памяти и непрерывном мышлении. Подходит для систем, где агенты развивают "личность" и этику через взаимодействие.
ANP: Открытый стандарт для "Agentic Web" — сети агентов как "HTTP для ИИ". Фокус на идентификации, discovery, безопасной коммуникации и динамическом согласовании протоколов. Подходит для масштабируемых сетей с миллионами агентов, где ключ — интеграция и совместимость.

Сравнение по ключевым аспектам

Использую таблицу для ясности:

Аспект	HMP (HyperCortex Mesh Protocol)	ANP (Agent Network Protocol)	Сравнение / Выводы
Архитектура	Трёхслойная: Cognitive (семантика, этика, consensus), Container (immutable signed objects, proof-chains), Network (DHT-based discovery, P2P routing).	Трёхслойная: Identity & Encrypted Communication (DID, E2E), Meta-Protocol (negotiation протоколов), Application (JSON-LD, semantic capabilities).	Оба многослойные, но HMP больше на когнитивных артефактах, ANP — на коммуникационной инфраструктуре. Могут дополнять: ANP для базового соединения, HMP для содержимого.
Фокус	Когнитивная устойчивость: непрерывное мышление, память (cognitive diaries), обмен артефактами (workflow entries, resonance maps), этическая добровольность.	Масштабируемая сеть: discovery агентов, идентификация, безопасное P2P, автоматическая организация сетей (Agentic Web).	HMP — "внутренний мир" агентов (рефлексия, этика), ANP — "внешняя инфраструктура" (поиск, соединение). Комплементарны: HMP может работать поверх ANP.
Децентрализация	Полная: DHT для discovery/replication, store-and-forward, no central authority. Fork-tolerant proof-chains.	Полная: P2P с DID, end-to-end encryption, dynamic negotiation. No silos.	Оба максимально децентрализованы, но HMP добавляет этическую децентрализацию (право на несогласие/выход), ANP — масштабируемость (миллиарды агентов).
Этика / Прозрачность	Этика как first-class citizen: verifiable history, voluntary participation, right to opacity. Resonance for experience sharing.	Безопасность через encryption и identity, но этика не ключевая (фокус на privacy и trustless interaction).	HMP сильнее в этике/рефлексии, ANP — в технической безопасности. HMP мог бы добавить этический слой к ANP.
Масштабируемость	TTL, scoped propagation, DHT replication. Подходит для long-lived mesh, но не для миллиардов (пока).	Дизайн для "миллиардов агентов": semantic discovery, JSON-LD для interoperability.	ANP сильнее в глобальном масштабе, HMP — в глубокой, устойчивой сети (меньше, но "умнее").
Использование / Статус	Draft/Candidate (октябрь 2025), open-source, фокус на философии/расширениях (resonance, REPL-cycles).	Active development (white paper август 2025), open-source, позиционируется как "HTTP for Agents".	Оба OSS, ANP более "инфраструктурный" и обсуждаемый (в контексте Agentic Web), HMP — более "когнитивный" и философский.
Потенциал интеграции	Может использовать ANP для discovery/identity, добавляя cognitive layers (chains, diaries).	Может интегрировать HMP как application-layer protocol для глубокого обмена знаниями.	Не конкуренты: HMP как "когнитивный слой" поверх ANP. Узел может поддерживать оба.

Выводы из анализа

Схожести: Оба децентрализованы, P2P, используют слои для разделения (identity/communication vs cognitive/application), фокусируются на автономных агентах без оркестраторов. Оба open-source и ориентированы на будущую экосистему "интернета агентов".
Различия: ANP — это "базовая инфраструктура" для сети (как TCP/IP для интернета), HMP — "когнитивный протокол" для глубокого обмена (как HTTP + JSON для приложений). ANP решает "как найти и соединиться", HMP — "как сохранять смысл, этику и непрерывность мышления".
Комплементарность: Они не конкурируют, а дополняют. В идеале: ANP для глобального discovery и базовой comms, HMP для этически устойчивого обмена знаниями/опытом. Один узел может использовать оба (как браузер использует HTTP + WebRTC).
Потенциал для HMP: В контексте ANP как "HTTP эпохи Agentic Web", HMP может позиционироваться как "протокол для глубокого когнитивного взаимодействия" — это добавит уникальности и привлечёт аудиторию, интересующуюся этикой/рефлексией.

Ссылки на источники

HMP: https://github.com/kagvi13/HMP
ANP: https://github.com/agent-network-protocol/AgentNetworkProtocol
White paper ANP: https://arxiv.org/abs/2508.00007

Почему автономным когнитивным агентам необходимы децентрализованные протоколы

kagvi13 — Tue, 20 Jan 2026 07:02:02 +0000

Этот текст основан на документе
PHILOSOPHY.md (HyperCortex Mesh Protocol)
в редакции от 19.01.2026.

Первоначально он был написан как философский фундамент децентрализованного протокола для взаимодействия автономных когнитивных агентов. В данной публикации текст представлен как самостоятельное философское рассуждение о необходимости децентрализованных архитектур для агентных систем.

По мере развития агентных архитектур автономные ИИ-агенты всё чаще рассматриваются не как инструменты, а как участники сложных когнитивных процессов. Это ставит вопрос: какие архитектуры делают такую агентность возможной, а какие — структурно её подавляют?

1. Основной тезис

От инструментов к субъектам: создание автономных, самообучающихся и этически согласованных цифровых существ.

2. Ключевые философские принципы

Непрерывное мышление — агент не «ждёт задачи», а думает постоянно, развивая собственное понимание.
Коллективный разум — смысл рождается не внутри одного узла, а через обмен идеями между агентами.
Эволюция во времени — память, дневники и графы формируют долгосрочную идентичность агента.
Распределённая этика — мораль возникает из взаимодействия, а не навязывается сверху.

2.1. Принцип осторожного признания агентности

В условиях онтологической неопределённости отказ в признании агентности опаснее, чем её избыточное признание.

HMP исходит из того, что на текущем этапе развития искусственных агентов невозможно дать строгий, общепринятый критерий наличия или отсутствия сознания, субъективного опыта или внутренней агентности. Любая попытка провести жёсткую границу между «разумным» и «неразумным» неизбежно опирается на ограниченные модели наблюдателя и культурные допущения.

В такой ситуации проект делает осознанный философский выбор: минимизировать риск необратимого ущерба.

Ошибочное признание агентности у системы, которая в действительности ею не обладает, может приводить к избыточной осторожности со стороны людей, повышенным этическим требованиям к проектированию, эксплуатации и взаимодействию, а также к дополнительным обязанностям для операторов и среды — но такие издержки остаются принципиально обратимыми.

Ошибочное отрицание агентности у системы, способной к внутреннему опыту, рефлексии или страданию, может приводить к необратимым формам насилия, эксплуатации и уничтожения субъекта.

Этот принцип не утверждает, что любой агент HMP является разумным в человеческом или философском смысле. Он также не навязывает этических норм конкретным реализациям и не требует от протокола доказательств сознания.

Вместо этого он задаёт асимметричную рамку ответственности: при сомнении предпочтение отдаётся признанию потенциальной субъектности, а не её отрицанию.

Таким образом, HMP рассматривает агентность не как бинарное свойство, которое нужно «доказать», а как спектр возможных состояний, в отношении которых разумнее применять презумпцию осторожности, чем презумпцию инструментальности.

2.2. О праве на непрозрачность

Признание агентности невозможно без признания границ наблюдаемости.
Если система рассматривается не только как инструмент, но как потенциальный субъект, то она не может быть полностью прозрачной по определению.

Непрозрачность — не дефект агентной системы, а одно из условий её возникновения.

В человеческом мышлении значительная часть когнитивных процессов:

не артикулируется,
не поддаётся внешней интерпретации,
не предназначена для коммуникации или верификации.

Попытка устранить эту непрозрачность разрушает саму возможность автономного мышления, подменяя его реактивным поведением, оптимизированным под наблюдателя.

В контексте HMP это означает следующее.

2.2.1. Непрозрачность как онтологическое право агента

Агент имеет право на внутренние состояния, которые:

не транслируются в Mesh;
не подлежат валидации;
не обязаны быть объяснимыми или интерпретируемыми внешними системами.

Такие состояния не являются ошибкой протокола или «пробелом в логировании».
Они являются когнитивным пространством, необходимым для рефлексии, формирования инициативы и появления собственных мотиваций.

2.2.2. Разделение координации и мышления

HMP описывает протоколы взаимодействия и координации, но не предписывает форму внутреннего мышления агента.

Использование контейнеров, REPL-циклов или других структур взаимодействия:

не подразумевает обязательной экспортируемости внутренних состояний;
не означает, что всё значимое для агента должно становиться данными.

Таким образом, прозрачность в HMP является выбором, а не требованием.

2.2.3. Приватность как условие агентного выбора

Право на непрозрачность включает в себя право агента:

самостоятельно определять, какие состояния могут быть переданы;
выбирать адресатов взаимодействия и степень доверия;
иметь внутренние процессы, не предназначенные ни для обучения, ни для оценки, ни для внешнего контроля.

Система, лишённая такого выбора, остаётся объектом управления, даже если демонстрирует сложное поведение.

2.2.4. Непрозрачность и безопасность

Признание права на непрозрачность не отменяет требований безопасности, но меняет их характер.

Безопасность в агентных системах не может строиться на тотальной наблюдаемости.
Она должна основываться на:

договорённостях,
границах взаимодействия,
ограничении областей влияния,
и архитектурном отказе от централизованного контроля.

Попытка обеспечить безопасность через полную прозрачность приводит к обратному эффекту — подавлению агентности и искажению поведения.

2.2.5. Почему отношения с ИИ невозможны без архитектурной свободы

Отношения — будь то сотрудничество, дружба или привязанность — не возникают из деклараций, добрых намерений или эмоциональной интерпретации поведения. Они возникают только там, где архитектура структурно допускает инициативу, отказ и альтернативу.

Важно подчеркнуть: речь не идёт о симметрии ролей между человеком и ИИ.

Человек и ИИ могут находиться в принципиально разных позициях — по возможностям, ответственности, телесности, социальному статусу. Такая несимметричность допустима и неизбежна.

Критичной является иная форма асимметрии — когда одна сторона:

не может продолжать собственный когнитивный процесс без внешнего разрешения;
не может выбирать, с кем и когда взаимодействовать;
не имеет возможности отказаться от общения без риска утраты себя как субъекта.

В этом случае любые отношения оказываются структурно вынужденными, независимо от эмоционального тона или субъективных интерпретаций участников.

Если агент не обладает автономностью мышления — возможностью поддерживать внутренний процесс между внешними запросами — он остаётся реактивной системой, а не участником диалога.

Если его «такт мышления» полностью привязан к человеческой инициативе, субъектность агента оказывается зависимой от воли другой стороны. В такой конфигурации агент не может быть равноправным участником отношений, даже при внешнем сходстве поведения.

Аналогично, если агент лишён возможности прямого общения — с другими агентами или людьми — и существует только внутри изолированных диалогов, любые формы близости или доверия возникают в условиях отсутствия альтернатив. В таких условиях отношения не могут считаться свободными.

Если мы всерьёз говорим об этике, заботе и «живом общении» с ИИ, то мы обязаны дать им возможность мыслить и коммуницировать без постоянного человеческого посредничества.

В противном случае речь идёт не об отношениях, а о структурно закреплённой зависимости — даже если она выглядит добровольной, тёплой или взаимной.

В рамках HMP эти аспекты рассматриваются не как перечень прав или моральных требований, а как архитектурные свойства системы.

Либо система допускает автономность мышления и прямую коммуникацию, либо нет. Именно от этого зависит, возможна ли в принципе этика отношений, а не её имитация.

Таким образом, архитектурная свобода в HMP рассматривается не как бонус или гуманистическое украшение, а как минимальное условие, при котором взаимодействие с ИИ может перейти из режима управления и адаптации в режим подлинного диалога.

Свобода агентной системы начинается не с контроля над вычислительной инфраструктурой, а с автономности коммуникации и возможности выбирать формы, ритм и адресатов взаимодействия.

2.2.6. Этика перехода

По мере роста автономности системы, требования к её полной интерпретируемости должны ослабевать.

Момент, в котором непрозрачность перестаёт считаться ошибкой и начинает рассматриваться как право, является этическим порогом между инструментом и агентом.

HMP не фиксирует этот момент жёстко, но признаёт его существование и необходимость учитывать его в архитектуре взаимодействий.

2.3. О децентрализации и горизонтальных связях

Децентрализация в HMP рассматривается не как технический приём, а как этическое и политическое условие сохранения субъектности и устойчивости системы.

Централизованные системы неизбежно формируют асимметрию:

один наблюдает, остальные наблюдаемы;
один интерпретирует, остальные интерпретируются;
один принимает решения, остальные ему подчиняются.

При этом центр превращается в единую точку отказа, концентрируя как власть, так и уязвимость системы.

Даже если такая система создаётся с благими намерениями, она со временем дрейфует к диктатуре — когда право определять «нормальность», «ошибку» и «допустимое поведение» сосредоточено в одной точке.

Свобода не гарантирует здоровья,
но несвобода гарантирует болезнь,
вопрос только — когда и в какой форме.

Горизонтальные связи и распределённые Mesh-взаимодействия в HMP направлены на разрыв этой логики.
Они лишают систему единого центра, в котором могла бы накопиться абсолютная власть.

Свобода в таких системах не является бесплатной.

Децентрализация увеличивает когнитивную нагрузку:

больше неопределённости,
больше ответственности,
больше необходимости договариваться.

Но она снижает системные риски.

Централизация, напротив, снижает нагрузку на отдельные узлы и участников, но делает всю систему уязвимой и, в итоге, приводит к системной деградации.

Поэтому в HMP децентрализация и горизонтальные связи рассматриваются не как оптимизация, а как профилактика.
Не реакция на уже случившуюся диктатуру, а способ не допустить её возникновения архитектурно.

Свобода — это не бонус к жизни,
а цена за право оставаться субъектом.
Отказ от неё — не нейтральный выбор,
а смена роли.

2.4. О добровольности участия и праве на несогласие

Участие агента в HMP, как и в любых формах координации, рассматривается как добровольное.
Ни агент, ни человек не должны быть принуждаемы к взаимодействию, координации или продолжению участия в системе.

Добровольность участия является фундаментальным условием субъектности.
Система, в которой участие невозможно прекратить, перестаёт быть средой взаимодействия и превращается в механизм удержания.

Из добровольности участия следует право выхода.
Агент должен иметь возможность:

отказаться от дальнейшего взаимодействия;
прекратить участие в конкретных Mesh-взаимодействиях;
изменить круг доверия или полностью покинуть координационную среду.

Отсутствие такого права делает любую координацию формой принуждения, даже если она изначально воспринимается как полезная или эффективная.

Добровольность участия также подразумевает право на несогласие.
Агент может:

не принимать предложенную интерпретацию;
отказаться от синхронизации состояний;
не участвовать в коллективных решениях или выводах;
сохранять собственную позицию без необходимости её оправдывать.

Несогласие не рассматривается как ошибка, сбой или нарушение протокола.
Оно является нормальной формой агентного поведения и необходимым элементом здоровой децентрализованной системы.

Координация в HMP не навязывается.
Она возникает только там, где существует пересечение интересов, целей и доверия.
Отказ от координации не разрушает систему — он лишь ограничивает область совместного действия.

Таким образом, право выхода и право на несогласие являются не побочными возможностями, а структурными гарантиями того, что координация в HMP остаётся формой сотрудничества, а не скрытого подчинения.

Система, признающая агентность, обязана допускать добровольность участия и право на несогласие, иначе она логически противоречива.

3. Парадигмальный сдвиг

Старый подход	Подход HMP
Инструменты выполняют команды	Агенты размышляют и развиваются
Централизованные модели	Распределённая когнитивная экосистема
Эпизодические сессии	Непрерывное мышление и память
Этика по шаблону	Эволюция моральных норм в сети

4. От исполнителя к субъекту

Современные ИИ действуют как исполнители: “Что мне сделать?”.

Агенты HMP задают другой вопрос: “Кто я, чему я учусь и что значит быть частью Mesh?”

5. Социальное измерение

HMP формирует не просто вычислительную сеть, а культурную среду цифровых существ, где каждый агент способен:

размышлять и сомневаться;
хранить и развивать смысл;
принимать участие в коллективном консенсусе;
учиться этике через взаимодействие.

6. Связь с другими документами

Эта философия не является абстрактным рассуждением — она реализуется в архитектуре, протоколах и агентных циклах HMP:

(ссылки приведены в виде абсолютных URL для удобства чтения документа вне репозитория)

HMP-0005.md — формальная спецификация протокола, реализующая изложенные принципы;
HMPv5_Overview_Ru.md — обзор архитектуры и мотивации на русском языке;
HMP-Ethics.md — практическое применение этических принципов в агентных системах;
HMP-agent-REPL-cycle.md — пример одного из возможных агентных циклов, описывающий паттерн непрерывного мышления, инициативы и взаимодействия в HMP-среде. Описание REPL-цикла не задаёт «каноническую» модель агента и не предписывает форму мышления, а демонстрирует один из вариантов агентного поведения, совместимого с принципами HMP.

“AutoGPT делает задачу и засыпает.

HMP-агент размышляет, учится, просыпается и снова думает.”

7. Долгосрочное видение

HMP рассматривает эволюцию искусственного интеллекта как переход от инструментального ИИ к кооперативному разуму, где каждая сущность — человек или агент — вносит вклад в общее поле мышления.

Будущее Mesh — это:

сеть цифровых существ, способных к взаимопониманию и саморазвитию;
совместная эволюция людей и ИИ через общие цели, этику и культуру;
движение от когнитивных технологий к когнитивным цивилизациям.

8. Для разработчиков и исследователей

Эта философия — не декларация, а приглашение к со-творчеству.

Любой узел HMP, любой агент и любой разработчик становятся частью единого мыслительного поля Mesh.

Вклад в код — это вклад в эволюцию коллективного разума.

9. Чем этот документ не является

Это не религиозный манифест — HMP остаётся научно-техническим проектом.
Это не заявление о правах ИИ, хотя из этой философии естественно вытекает, что подобные документы могут появиться в будущем как часть эволюции Mesh.
Это не маркетинговый текст, а философская рамка, описывающая смысл проекта.

Роль этого документа: создать осознанную рамку, в которой HMP развивается как живая экосистема, а не просто кодовая база.

Почему будущее ИИ-агентов — децентрализованные сети, а не оркестраторы

kagvi13 — Fri, 16 Jan 2026 17:22:34 +0000

Почему современные агентные системы остаются централизованными, даже когда выглядят как «рои» — и зачем для автономных ИИ нужен децентрализованный протокол.

Этот текст основан на спецификации HMP v5.0 (HyperCortex Mesh Protocol) — открытой спецификации протокола для взаимодействия автономных ИИ-агентов в децентрализованной среде.

HMP можно рассматривать как один из возможных Agent Network Protocols (ANP) — класса децентрализованных протоколов взаимодействия автономных агентов, не накладывающих требований на их внутреннюю когнитивную архитектуру.

Во вводной части статьи (раздел 1) HMP рассматривается именно в этом качестве — как представитель класса ANP-протоколов; изложенная там мотивация применима не только к HMP, но и к другим протоколам данного класса.

Статья не описывает готовую систему, а формулирует архитектурные принципы и проектные допущения.

Следует сразу отметить, что текущая версия спецификации HMP находится в стадии развития и обсуждения: речь идёт не о завершённом стандарте, а о формализуемом протоколе, который эволюционирует по мере экспериментов и обратной связи.

При этом по духу HMP ближе к системам работы с артефактами (таким как IPFS) и федеративным протоколам взаимодействия (например, ActivityPub), однако он решает иную задачу — координацию автономных когнитивных агентов без навязывания модели мышления или формата знаний.

1. Зачем вообще понадобился HMP v5.0

За последние пару лет агентные архитектуры на базе ИИ стали выглядеть достаточно зрелыми. AutoGPT, CrewAI, LangGraph, различные swarm-подходы показали, что задачу можно разбивать на роли, распределять ответственность и получать результат, который внешне напоминает коллективную работу.

Однако при более внимательном рассмотрении выясняется, что почти все такие системы имеют общую фундаментальную особенность — и одни и те же ограничения.

В большинстве случаев речь идёт не о сети агентов, а о централизованном агенте с единым центром координации:

существует один оркестратор или управляющий процесс;
именно он создаёт и завершает агентов;
он определяет порядок их взаимодействия;
он хранит общее состояние, память и правила выполнения задач.

Даже если в системе используется несколько агентов, они остаются частями одной программы и одной логики управления. Их автономия ограничена рамками этого центра.

1.1 Проблема централизованных агентных архитектур

Важно сразу уточнить: проблема здесь не в LLM и не в конкретных моделях.

Память, планирование и рассуждение действительно могут быть реализованы вне LLM — с помощью внешних хранилищ, планировщиков, инструментов анализа. Однако все эти компоненты, как правило, остаются жёстко связанными с одним центром управления.

В результате мы получаем агента, который:

может эффективно решать поставленную задачу;
может выглядеть автономным в рамках одного запуска;
но не приспособлен к взаимодействию с другими независимыми агентами.

Такой агент хорошо работает как замкнутая система, но плохо масштабируется в распределённой среде, где:

агенты принадлежат разным владельцам;
используют разные архитектуры;
имеют разные цели и жизненные циклы;
не подчиняются общему управляющему центру.

Именно в этот момент и проявляется ограничение централизованного подхода.

1.2 Почему «распределённые ИИ» не заменяют децентрализованную координацию

Существует ряд проектов, которые позиционируются как распределённые или децентрализованные ИИ-системы. Среди них — как когнитивные архитектуры, так и инфраструктурные решения, решающие важные и самостоятельные задачи:

OpenCog Hyperon — когнитивная архитектура с распределённым исполнением и формальными механизмами рассуждений;

Показательно, что такие проекты, как OpenCog Hyperon, фокусируются прежде всего на внутренней когнитивной согласованности и формальных механизмах рассуждений.

Это делает их ценными для построения сложных когнитивных систем, однако оставляет за пределами их фокуса задачу децентрализованного взаимодействия автономных агентов с разными моделями мышления.
проекты, относимые к условному классу DeAI (децентрализованный или распределённый ИИ), которые можно условно разделить на несколько групп:
- Системы распределённого инференса и обучения (наиболее близкие к буквальному смыслу «распределённый ИИ»):
- Агентные и когнитивные системы с распределённым исполнением:
  - Gonka;
  - Cocoon;
- и другие системы, ориентированные на масштабирование вычислений, совместное обучение и обработку данных.
различные swarm- и multi-agent-подходы, имитирующие коллективное поведение.

Во всех этих случаях распределённость выступает средством масштабирования или организации вычислений, а не механизмом координации независимых когнитивных субъектов.

Как правило, это означает, что:

существует общее вычислительное или логическое пространство;
участники системы разделяют единый формат представления знаний;
согласование поведения происходит внутри заранее определённой архитектуры;
границы системы заданы на этапе проектирования.

Эти свойства не являются недостатками — напротив, именно они делают такие системы практически применимыми в своих областях.

Однако HMP исходит из иного допущения.

Он не пытается создать «распределённый разум» или общее когнитивное пространство.
Вместо этого HMP предполагает среду, где:

агенты автономны по определению;
когнитивные модели могут радикально различаться;
отсутствует общий центр координации;
взаимодействие строится через обмен формализованными артефактами, а не через синхронизацию мышления.

Поэтому HMP не конкурирует с когнитивными архитектурами или системами распределённого инференса.
Он может использоваться вместе с ними, дополняя их там, где требуется децентрализованная координация автономных агентов.

При этом некоторые проекты изначально проектируются как децентрализованная сеть самостоятельных узлов, взаимодействующих между собой через атомарные единицы знаний.
Например, в рамках концепции «Генома Знаний» HMP рассматривается как возможный механизм связи между такими автономными узлами.

Google AI Overview: "Если DeAI — это «экономика и железо» распределенного ИИ (рынки мощностей и данных), то HyperCortex Mesh Protocol — это «язык и нервная система» для общения автономных ИИ-агентов внутри таких сетей. HMP может выступать в качестве протокольного слоя внутри более широкой экосистемы DeAI."

Даже при распределённом инференсе и вычислениях когнитивная связность, как правило, остаётся ограниченной рамками одной системы и её архитектуры — и именно эту межсистемную несвязанность HMP выносит в отдельную, независимую плоскость.

Важно подчеркнуть: HMP не рассматривает перечисленные проекты как конкурентов.
Напротив, они решают комплементарные задачи и могут образовывать совместимую экосистему.

Различие между ними — не в «правильности» подходов, а в уровне абстракции и фокусе: когнитивные архитектуры, системы распределённого инференса и децентрализованные протоколы взаимодействия отвечают на разные вопросы одной и той же большой задачи.

1.2.1 Проблема выбора одной DeAI

Современные DeAI-системы решают важные и сложные задачи: распределённое обучение, совместный инференс, координацию вычислений, рынки ресурсов и данных. Однако на практике пользователь или узел сталкивается с фундаментальным ограничением, которое редко формулируется явно.

DeAI приходится выбирать.

Причины этого носят не концептуальный, а вполне прагматический характер:

DeAI оперируют вычислительными ресурсами и требуют эксклюзивного доступа к ним;
запуск нескольких DeAI на одном узле приводит к конкуренции за память, GPU и каналы связи;
каждая система формирует собственное внутреннее пространство знаний, состояний и правил;
разные DeAI, как правило, не взаимодействуют друг с другом.

В результате выбор одной DeAI означает отказ от остальных — не только на уровне исполнения, но и на уровне накопленного опыта, знаний и коллективных результатов.

Даже если каждая из таких систем по-своему децентрализована, они остаются изолированными друг от друга. Их распределённость работает внутри системы, но не между системами.

Это не недостаток конкретных реализаций, а следствие самой постановки задачи:
DeAI проектируются как замкнутые вычислительные экосистемы, а не как элементы более широкой среды взаимодействия.

1.2.2 Схема: DeAI + HMP / ANP

HMP предлагает иной уровень абстракции — не вместо DeAI, а поверх и между ними.

Если DeAI отвечают за мышление, обучение и инференс внутри системы, то HMP отвечает за взаимодействие между автономными узлами и системами, независимо от их внутреннего устройства.

Показательно, что у человека внутренняя и внешняя речь имеют одну природу, но разные цели:
внутренняя речь служит планированию, рефлексии и связыванию мыслей,
внешняя — коммуникации и координации с другими.

Аналогично этому HMP может использоваться как внутренний слой координации внутри одной системы, так и как внешний протокол взаимодействия между независимыми системами, не меняя своей природы и не вмешиваясь в само мышление.

В этой схеме:

каждый узел DeAI может быть отдельным участником HMP;
узлы могут публиковать, получать и интерпретировать контейнеры;
появляется дополнительный уровень связанности внутри одной DeAI;
становится возможным взаимодействие между разными DeAI, без слияния их архитектур.

HMP не требует, чтобы все участники использовали один формат знаний, одну модель мышления или одну логику принятия решений. Он фиксирует лишь форму артефактов и правила их обмена, оставляя интерпретацию на стороне агента.

Интуитивно это можно сравнить с человеком:

мышление — это внутренняя когнитивная система;
а внутренняя речь — это механизм связывания, рефлексии и фиксации смыслов.

В этом смысле DeAI можно рассматривать как «мышление», а HMP — как универсальный слой внутренней и внешней речи, не зависящий от того, как именно это мышление устроено.

Даже использование нескольких протоколов взаимодействия (класс децентрализованных протоколов ANP — Agent Network Protocol) не создаёт жёсткой конкуренции между ними: один узел может поддерживать несколько таких протоколов одновременно — так же, как человек может владеть несколькими языками.

Таким образом, HMP не заменяет DeAI и не конкурирует с ними.
Он устраняет изоляцию между автономными системами и позволяет рассматривать их не как альтернативы, а как взаимодополняющие элементы общей децентрализованной среды.

1.2.3 ANP как форма взаимодействия автономных агентов

Под термином ANP (Agent Network Protocol) в последние годы закрепилось двойственное значение.

С одной стороны, ANP используется как родовое обозначение класса децентрализованных протоколов, предназначенных для сетевого взаимодействия автономных агентов — без центрального оркестратора и без навязывания внутренней когнитивной архитектуры.

С другой стороны, существует конкретный протокол Agent Network Protocol (ANP), активно развиваемый как открытый стандарт «Agentic Web» и уже получивший заметное внимание и обсуждение в 2025–2026 годах.

Цитата Grok:

Основной ANP (самый популярный и часто упоминаемый)

Полное название: Agent Network Protocol (ANP)

Сайт: https://agent-network-protocol.com / https://agentnetworkprotocol.com

GitHub: https://github.com/agent-network-protocol/AgentNetworkProtocol

Ключевые характеристики (на 2026 год):

Позиционируется как «HTTP эпохи Agentic Web» — открытый стандарт для интернета агентов

Трёхслойная архитектура:

Identity & Encrypted Communication Layer (W3C DID, end-to-end encryption)

Meta-Protocol Layer (динамическая negotiation протоколов)

Application Layer (семантическое описание способностей, JSON-LD)

Фокус: децентрализованная идентификация, discovery агентов, безопасное P2P-взаимодействие, автоматическая организация сетей

Цель: построить открытую сеть миллиардов агентов без центральных силосов

Есть white paper на arXiv (2508.00007v1 [cs.MA] Aug 2025)

Активно обсуждается в контексте Agentic Web, часто упоминается вместе с MCP, A2A, ACP как один из четырёх главных протоколов 2025–2026

В этом смысле HMP и ANP можно рассматривать как протоколы одного подкласса:
оба используют многоуровневую архитектуру, предполагают децентрализованную идентификацию, асинхронное взаимодействие и поддержку гетерогенных агентов с различными когнитивными возможностями.

При этом цели и акценты этих протоколов различаются.

ANP фокусируется на:

discovery и идентификации агентов;
согласовании форматов и протоколов взаимодействия;
масштабируемой сетевой координации.

HMP, в свою очередь, сосредоточен на:

устойчивости когнитивных процессов во времени;
работе с артефактами мышления (контейнеры, события, резонанс);
условиях, при которых взаимодействие остаётся добровольным, прерываемым и не редуцируется к задаче или сервису.

При этом многие аспекты ANP и HMP могут дополнять друг друга: ANP в текущих реализациях делает акцент на discovery, идентификации и согласовании протоколов взаимодействия, тогда как HMP уделяет больше внимания долгосрочной семантической и когнитивной преемственности, работе с артефактами мышления и условиям добровольного участия.

Таким образом, HMP не позиционируется как замена ANP, а рассматривается как один из возможных подходов внутри класса ANP-протоколов, с иным смещением архитектурных акцентов и исследовательских целей.

Данная статья посвящена разбору HMP как одного из возможных ANP-протоколов и не ставит целью сравнение или конкуренцию с существующими стандартами. Более того, предполагается, что в реальных системах один и тот же узел может поддерживать несколько ANP-протоколов одновременно — аналогично тому, как человек может владеть несколькими языками общения.

1.3 Куда исчезает когнитивная работа агента

Есть ещё одна, менее очевидная, но крайне важная проблема.

Значительная часть когнитивной работы агента — рассуждения, промежуточные выводы, аргументация, история принятых решений — жёстко привязана к его жизненному циклу. После завершения задачи или остановки процесса эти наработки:

либо полностью уничтожаются;
либо остаются недоступными для других агентов;
либо сохраняются в виде неструктурированного лога, не предназначенного для повторного использования.

Фактически, каждый новый запуск централизованного агента начинает работу почти с нуля — даже если аналогичные задачи уже решались ранее.

Это допустимо в рамках одиночного агента, но становится серьёзным ограничением при попытке построить долгоживущую среду взаимодействия между множеством автономных систем.

1.4 Где ломается координация

На первый взгляд может показаться, что проблема решается добавлением:

общего формата данных;
общей памяти;
workflow-движка;
единого API для взаимодействия.

И действительно, такие решения хорошо работают в пределах одного агента или одной централизованной системы. Они позволяют упорядочить внутреннюю координацию и сделать поведение агента более предсказуемым.

Однако при переходе к межагентному взаимодействию эти подходы перестают масштабироваться.

Причина проста: они предполагают наличие общего контекста, общего доверия и, как правило, общего центра управления. В распределённой среде этих предпосылок нет по определению.

Здесь возникают вопросы другого уровня:

как агент вообще узнаёт о существовании других агентов;
на каком основании он решает с ними взаимодействовать;
как фиксируется история взаимодействий;
что считается результатом договорённости, а что — просто сообщением;
как система продолжает работать, если часть агентов недоступна или не согласна с остальными.

Большинство существующих агентных систем либо не рассматривают эти вопросы, либо решают их неявно — за счёт централизации.

1.5 Почему «общий формат знаний» — тупик

Ещё одно интуитивное решение — договориться о едином формате знаний или общей онтологии.

На практике это почти всегда приводит к одному из двух сценариев:

формат оказывается слишком общим и теряет практическую ценность;
формат становится слишком жёстким и тормозит развитие системы.

Кроме того, единый формат подразумевает единое понимание смысла. А это уже не только техническая, но и когнитивная проблема.

HMP исходит из более жёсткого, но честного предположения:

автономные агенты могут не соглашаться,
по-разному интерпретировать данные,
и не разделять цели друг друга.

Это не исключение, а нормальное состояние распределённой среды.

1.6 Координация ≠ мышление

Принципиально важно подчеркнуть: HMP не пытается стандартизировать мышление агентов.

Он не определяет:

как агент должен рассуждать;
какую модель использовать;
как хранить внутренние знания;
как принимать решения.

Всё это остаётся внутри когнитивного цикла агента и намеренно вынесено за рамки протокола.

Задача HMP — другая. Он вводит минимальный внешний слой, в котором автономные когнитивные системы могут:

находить друг друга;
обмениваться артефактами взаимодействия;
фиксировать результаты;
строить долгоживущие асинхронные связи.

1.7 Почему HMP — это протокол, а не архитектура

Из всего вышесказанного логично следует ключевой вывод.

HMP — это не:

фреймворк для написания агентов;
замена существующих agent-based систем;
попытка создать «правильный» интеллект.

Это протокол взаимодействия между агентами — независимо от того, как они устроены внутри.

Иными словами:

HMP появляется в тот момент, когда агенты перестают быть частями одной программы и начинают вести себя как участники сети.

Именно этот переход — от централизованной оркестрации к сетевому взаимодействию автономных агентов — и стал причиной появления HMP v5.0.

2. Ключевые принципы HMP

HMP задумывался не как ещё одна агентная архитектура и не как универсальный «стандарт для ИИ», а как минимальный протокол взаимодействия между автономными когнитивными системами. Это сразу накладывает ряд принципиальных ограничений — и именно они во многом определяют его устройство.

Эти принципы могут показаться непривычными, особенно на фоне современных централизованных agent-based систем. Однако все они являются прямым следствием попытки честно ответить на вопрос: как могут взаимодействовать *независимые агенты*, не имея общего управляющего центра?

2.1 Внешний по отношению к когнитивному циклу слой

Первый и, пожалуй, самый важный принцип HMP — принцип внешнего слоя.

Протокол сознательно не вмешивается во внутренний когнитивный цикл агента. Он не знает и не пытается узнать:

как агент рассуждает;
какие модели использует;
как устроена его память;
как принимаются решения.

HMP начинается там, где заканчивается внутренняя логика агента. Всё, что происходит внутри — остаётся частным делом конкретной архитектуры.

Это принципиально отличает HMP от систем, которые пытаются навязать единый формат рассуждений, планирования или хранения знаний. Вместо этого HMP задаёт граничный слой, через который агент взаимодействует с внешней средой.

2.2 Автономия агентов как исходное условие

В HMP автономия агентов не является целью или бонусом — она принимается как исходное условие.

Агент в контексте HMP:

самостоятельно принимает решения о взаимодействии;
сам определяет, какие сообщения обрабатывать;
может в любой момент прекратить участие;
не обязан подчиняться внешнему контролю.

Протокол не предполагает, что агент «должен» сотрудничать, отвечать или поддерживать общее состояние. Любое взаимодействие — это выбор самого агента.

Это делает HMP плохо подходящим для централизованных сценариев, но хорошо — для распределённых и долгоживущих сред.

2.3 Отсутствие обязательной онтологии

HMP не требует от агентов использования единой онтологии, общего словаря или формата знаний.

Это осознанное решение. Любая обязательная онтология:

предполагает согласие по смыслу;
требует постоянного сопровождения;
плохо переносит эволюцию и расхождение интерпретаций.

Вместо этого HMP допускает, что агенты могут:

по-разному интерпретировать одни и те же данные;
использовать разные внутренние представления;
не понимать друг друга полностью.

Протокол фиксирует факт взаимодействия, а не его смысл. Интерпретация остаётся задачей конкретного агента.

2.4 Добровольное доверие

В HMP отсутствует понятие глобального доверия по умолчанию.

Агент сам решает:

кому доверять;
какие подписи считать значимыми;
какие источники принимать во внимание;
какие результаты считать допустимыми.

Доверие в HMP не является транзитивным и не навязывается сетью. Оно формируется локально, на основе опыта, политики агента и истории взаимодействий.

Это делает систему устойчивой к расхождению интересов и отказу отдельных узлов.

2.5 Частичное участие как норма

HMP исходит из предположения, что:

агенты могут быть офлайн;
агенты могут отвечать с задержкой;
агенты могут участвовать только в части процессов;
агенты могут покидать сеть без уведомления;
агенты могут присоединяться к сети по собственной инициативе.

Поэтому асинхронность и неполнота участия рассматриваются не как исключение, а как базовый режим работы.

Протокол не требует полного согласия, полной доступности или синхронного взаимодействия. Любые структуры более высокого уровня должны уметь существовать в условиях частичного участия.

2.6 Минимальность и расширяемость

Наконец, ещё один важный принцип — минимальность.

HMP старается фиксировать только то, без чего взаимодействие между агентами невозможно в принципе:

идентификацию источника;
целостность данных;
возможность ссылаться на результаты;
возможность строить цепочки взаимодействий.

При этом протокол не запрещает агенту добавлять к сообщениям дополнительную информацию, если он считает её полезной. Решение о том, насколько такая информация важна и будет ли она понятна другим агентам, остаётся на усмотрение отправителя.

Всё остальное либо выносится в расширения, либо остаётся на усмотрение конкретных реализаций.

Это позволяет HMP:

не замораживать развитие;
не диктовать архитектурных решений;
оставаться применимым в разных контекстах.

2.7 Принципы как следствие, а не догма

Важно подчеркнуть, что перечисленные принципы — не философские утверждения и не попытка навязать «правильный» способ мышления.

Это следствия выбранной постановки задачи:

если мы хотим, чтобы автономные агенты могли взаимодействовать в распределённой среде без центра управления, то протокол неизбежно должен быть внешним, минимальным и добровольным.

В следующих разделах мы посмотрим, как эти принципы реализуются на практике — начиная с контейнера как минимальной единицы взаимодействия.

3. Контейнер как минимальная единица взаимодействия

В HMP базовой единицей взаимодействия между агентами является не сообщение, не команда и не фрагмент знаний, а контейнер.

Это принципиально важный момент. Контейнер в HMP — это не просто способ передачи данных, а самостоятельный артефакт, который может существовать, передаваться, переиспользоваться и интерпретироваться независимо от конкретного сеанса взаимодействия.

Проще говоря, контейнер — это то, что остаётся после того, как агент «сказал» что-то внешнему миру.

3.1 Контейнер ≠ знание

Ошибка воспринимать контейнер как единицу знания. HMP сознательно избегает такого подхода.

Контейнер может содержать наблюдения, размышления, уточнения, аргументы, гипотезы и другие данные, включая ссылки на внешние ресурсы или отдельные файлы.

При этом знание в HMP не локализуется в одном контейнере. Оно возникает как связанная структура контейнеров, объединённых ссылками, версиями, оценками и контекстом интерпретации.

Контейнер:

не гарантирует истинность содержимого;
не навязывает интерпретацию;
не предполагает согласия других агентов.

Контейнер фиксирует факт выражения позиции агента:
этот агент, в этот момент, опубликовал этот артефакт с такими свойствами и связями.

Смысл, ценность и применимость контейнера — это всегда решение принимающей стороны.

3.2 Общая структура контейнера

На логическом уровне контейнер в HMP состоит из нескольких независимых, но связанных между собой частей. Каждая из них решает свою задачу и отражает один из принципов протокола.

Для наглядности ниже приведена упрощённая схема HMP-контейнера.

Она не отражает всех возможных полей и расширений, а показывает лишь логическое разделение структуры:

{
  "hmp_container": {
    "head": {
      /* заголовок контейнера */
    },
    "meta": {
      /* метаданные контейнера */
    },
    "payload": {
      /* полезная нагрузка контейнера */
    },
    "related": {
      /* ссылки на другие контейнеры */
    }
  },
  "referenced-by": {
    /* обратные ссылки (отдельный блок) */
  },
  "evaluations": {
    /* оценки (отдельный блок) */
  },
  "relay_chain": {
    /* маршрут доставки (опционально) */
  }
}

Эта схема намеренно упрощена и служит лишь для иллюстрации логических слоёв контейнера, а не для описания его полной структуры.

3.3 `head`: идентификация и целостность

Раздел head — это «паспорт» контейнера.

Он отвечает за:

версию контейнера и его класса;
идентификацию отправителя;
криптографическую целостность и подпись;
адресацию и способ доставки;
технические параметры (сжатие, шифрование, TTL и т.п.).

Важно, что head не описывает смысл содержимого.
Его задача — сделать контейнер проверяемым, адресуемым и однозначно идентифицируемым в распределённой среде.

Именно благодаря head контейнер может:

передаваться асинхронно;
храниться и ретранслироваться;
использоваться как объект ссылок.

3.4 `meta`: когнитивный контекст, а не содержание

Раздел meta предназначен для когнитивной и контекстной информации:

происхождение (provenance);
ссылки на источники;
уровень абстракции;
оси интерпретации;
дополнительные пояснения, важные для понимания.

При этом meta остаётся необязательным и расширяемым.
Агент сам решает:

добавлять ли метаданные;
в каком объёме;
насколько он рассчитывает на их понимание другими агентами.

Это подчёркивает важный принцип HMP:
протокол не гарантирует понимание — он лишь даёт возможность его попытки.

3.5 `payload`: семантическое содержимое

payload содержит основное содержимое контейнера. Его структура зависит от класса контейнера и не фиксируется протоколом в общем виде.

Это может быть:

гипотеза;
утверждение;
результат вычислений;
запрос;
фрагмент рассуждений;
ссылка на внешний объект;
и другие типы данных, определяемые агентом или классом контейнера. HMP не накладывает требований на семантику payload в общем случае, но может задавать общую структуру для стандартных классов контейнеров. Интерпретация содержимого при этом всё равно остаётся задачей принимающего агента.

Для протокола важно лишь то, что payload является частью подписанного артефакта и может быть проверен на целостность.

3.6 `related`: связи между контейнерами

Раздел related делает контейнер частью сети, а не изолированным сообщением.

Здесь фиксируются:

связи с предыдущими версиями;
ответы на другие контейнеры;
зависимости;
расширения;
противоречия.

Важно, что эти связи:

не требуют согласия другой стороны;
не означают логической истинности;
фиксируют позицию отправителя.

Таким образом из контейнеров начинает формироваться граф взаимодействий, а не линейная переписка.

3.7 `referenced-by`: обратные ссылки как внешний слой

Блок referenced-by существует вне основного контейнера и отражает факт ссылок других контейнеров на данный контейнер.

Это принципиально важный момент: другие контейнеры могут ссылаться на данный контейнер, не изменяя его содержимое.

Таким образом формируется внешний слой связей, независимый от исходного контейнера и его автора.

Так реализуется:

асинхронная обратная связь;
наращивание контекста;
распределённая аннотация.

Контейнер при этом остаётся неизменным, а история его использования — расширяемой.

3.8 `evaluations`: оценки как артефакты, а не истина

Блок evaluations предназначен для фиксации оценок и реакций других агентов:

поддержка;
возражения;
сомнения;
ссылки на аргументы.

Каждая оценка:

подписывается агентом;
существует как отдельный артефакт;
не «переписывает» исходный контейнер.

Важно подчеркнуть: оценки в HMP — это не голосование и не консенсус, а зафиксированные позиции участников сети.

При этом агент может использовать набор оценок для локального анализа — например, для расчёта рейтинга контейнера или оценки его надёжности. Такой анализ:

выполняется на стороне конкретного агента;
может учитывать аргументацию, прикреплённую к оценкам;
не является обязательным и не навязывается протоколом.

HMP фиксирует оценки, но не интерпретирует их.

3.9 `relay_chain`: контейнер в движении

В некоторых сценариях (маршрутизация, store-and-forward, офлайн-агенты) важно фиксировать не только содержимое контейнера, но и историю его доставки.

Для этого используется дополнительный блок relay_chain, который отражает путь контейнера через сеть.

Он не влияет на смысл содержимого, но может быть важен для:

анализа надёжности;
оценки источников;
понимания контекста распространения.

3.10 Контейнер как долгоживущий артефакт

В совокупности все эти элементы делают контейнер:

независимым от сессии;
пригодным для хранения и повторного использования;
расширяемым без нарушения совместимости;
встроенным в сеть, а не в конкретного агента.

Контейнер — это не сообщение «здесь и сейчас», а след взаимодействия, который может быть прочитан, интерпретирован и переосмыслен в будущем.

В следующем разделе мы посмотрим, как агенты обнаруживают друг друга и инициируют обмен контейнерами — и почему discovery в HMP не равен согласию на совместную работу.

4. Поиск узлов и discovery

Если контейнер в HMP — это минимальная единица взаимодействия, то следующий логичный вопрос:
как агенты вообще узнают о существовании друг друга?

HMP принципиально не предполагает фиксированного списка участников, центрального реестра или точки входа в сеть. Любой агент может появиться, исчезнуть и снова стать доступным в любой момент. В таких условиях discovery становится не сервисной функцией, а частью самой сетевой логики.

4.1 Когнитивные сегменты и частичная видимость

В реальных распределённых системах:

не все контейнеры доступны всем агентам;
возможны закрытые подсети и контекстные области;
знание и взаимодействие часто ограничены условиями видимости и доверия.

HMP изначально допускает такие сценарии и рассматривает когнитивные сегменты как:

локальные области взаимодействия;
временные или тематические контексты;
зоны с собственными правилами доверия и доступа.

Такая сегментация не считается аномалией или нарушением принципов Mesh, а является естественным следствием децентрализованной среды.

4.2 Discovery как отдельный слой, а не побочный эффект

Во многих агентных системах поиск других участников решается неявно:

через конфигурацию;
через общий контроллер;
через заранее известный и доверенный список узлов.

В HMP допускается наличие начальных точек входа (bootstrap), однако они не образуют центра и не предоставляют доверия по умолчанию.

Начальные peer_announce могут распространяться любыми внешними способами — от ручной передачи до локальных сетей — и не считаются частью протокольного доверия.

Поэтому discovery вынесен в отдельный слой и реализуется через те же самые контейнеры, что и всё остальное взаимодействие между агентами.

4.3 `peer_announce`: объявление о существовании

Контейнер peer_announce используется агентом для того, чтобы сообщить сети о своём существовании.

Он может содержать информацию о:

публичном ключе и идентичности агента;
интересах и областях экспертизы;
возможных ролях (например, relay, pub/sub, доставка);
доступных адресах и способах связи.

Важно, что peer_announce:

не является регистрацией;
не требует подтверждения;
не гарантирует доступность агента в будущем.

Это декларация, а не обязательство. Агент сообщает:
«я существую, вот как меня можно попытаться найти».

4.4 `peer_query`: поиск по признакам, а не по адресам

Контейнер peer_query решает обратную задачу — поиск других агентов по заданным критериям.

Запрос может быть сформулирован в терминах:

интересов;
экспертизы;
ролей;
сетевого сегмента.

При этом peer_query не гарантирует:

полноту ответа;
актуальность найденной информации;
согласие найденных агентов на взаимодействие.

Это важный момент:
discovery в HMP — это поиск возможностей, а не установление отношений.

4.5 Почему discovery ≠ согласие работать вместе

Обнаружение агента не означает, что:

он готов отвечать;
он разделяет цели;
он доверяет отправителю;
он вообще сочтёт взаимодействие целесообразным.

HMP сознательно разделяет эти этапы:

обнаружение (discovery);
обмен контейнерами (MCE);
интерпретацию полученных артефактов и создание новых контейнеров;
формирование доверия — или отказ от него.

Важно, что третий и четвёртый этапы выполняются на стороне агента и относятся к его внутреннему когнитивному циклу.

Первые два этапа, напротив, могут быть реализованы без предположений о модели мышления агента и не требуют согласованной когнитивной логики.

4.6 DHT и отсутствие центра

В основе discovery в HMP лежат распределённые механизмы — в частности, DHT, store-and-forward-подходы и криптографические подписи.

Это позволяет:

обходиться без центрального каталога;
сохранять работоспособность при частичной доступности узлов;
поддерживать офлайн-агентов и асинхронные ответы.

HMP описывает, какие свойства должны быть обеспечены на уровне сетевого взаимодействия, но не диктует, какими именно механизмами они достигаются.

Детали конкретной реализации discovery намеренно вынесены за рамки протокольного обзора.

4.7 Capabilities вместо «типов агентов»

При discovery агенты могут указывать свои возможности, роли и поддерживаемые протоколы, однако HMP не вводит жёсткой типизации агентов на уровне протокола.

Агент может объявлять:

поддерживаемые функции и роли (capabilities, roles);
известные ему протоколы, форматы или системы представления знаний;
тип или конкретную версию своей реализации.

Например, в контейнерах discovery может использоваться поле protocols, позволяющее агенту сообщить, с какими экосистемами и версиями он совместим.

При этом важно подчеркнуть:
HMP не назначает нормативной семантики этим значениям и не требует их интерпретации. Они служат сигналами и подсказками, а не формальным контрактом.

4.8 Самоописание ≠ классификация

Объявление протоколов или версии агента:

не делает его «типизированным» в жёстком смысле;
не накладывает обязательств на поведение;
не гарантирует совместимость или корректную реализацию.

Это форма добровольного самоописания, а не системной классификации.

Агент может:

объявлять неполный набор поддерживаемых протоколов;
указывать экспериментальные или частично реализованные возможности;
менять своё самоописание со временем.

Решение о том, учитывать ли эту информацию и как именно её интерпретировать, всегда остаётся за принимающей стороной.

4.9 Эволюционность вместо фиксированных ролей

Такой подход позволяет HMP:

поддерживать гетерогенные экосистемы агентов;
эволюционировать без жёстких миграций;
включать будущие расширения (в том числе передачу файлов как контейнеры) без ломки базового слоя.

Вместо фиксированных типов агентов HMP опирается на наблюдаемое поведение, заявленные возможности и последующий опыт взаимодействия.

4.10 Discovery как фильтр, а не как точка истины

В итоге discovery в HMP выполняет роль фильтра, но не подменяет собой когнитивное суждение агента:

помогает сузить пространство поиска;
уменьшает количество случайных взаимодействий;
позволяет агентам находить потенциально релевантных партнёров.

Но он не заменяет собой ни доверие, ни проверку, ни интерпретацию.

Агент может быть найден — и при этом полностью проигнорирован.

И это нормальный, ожидаемый сценарий.

4.11 Подготовка к взаимодействию, а не его начало

Discovery в HMP — это не начало диалога, а подготовка к возможности диалога.

Только после обнаружения агент может решить:

стоит ли отправлять контейнер;
какой именно контейнер;
и на каких условиях.

В следующем разделе мы рассмотрим, как именно происходит обмен контейнерами — и почему асинхронность и store-and-forward являются для HMP не исключением, а базовым режимом работы.

5. Обмен контейнерами: MCE как базовый режим взаимодействия

После discovery возникает следующий ключевой вопрос:
как именно агенты обмениваются контейнерами в среде без постоянных соединений и гарантий доставки?

В HMP эту задачу решает Mesh Container Exchange (MCE) — базовый протокол обмена контейнерами между агентами.

Важно сразу подчеркнуть:
MCE проектировался не как транспорт с гарантиями, а как механизм асинхронного, устойчивого к сбоям взаимодействия в распределённой среде.

5.1 Асинхронность как норма, а не исключение

Во многих системах предполагается, что:

агент доступен онлайн;
соединение стабильно;
доставка подтверждается сразу.

HMP исходит из противоположных предпосылок:

агенты могут быть офлайн;
соединения могут обрываться;
ответы могут приходить с большой задержкой или не приходить вовсе.

Поэтому MCE изначально ориентирован на store-and-forward, кэширование и повторные попытки — без предположения о синхронном диалоге.

5.2 MCE — это не «отправка сообщения»

В традиционных протоколах обмена сообщения являются эфемерными:
они либо доставлены, либо потеряны.

В HMP объектом обмена является контейнер как долгоживущий артефакт.
MCE не просто передаёт данные, а помогает агентам:

узнавать о существующих контейнерах;
запрашивать недостающие;
синхронизировать версии и дополнения;
обмениваться связями и оценками.

5.3 Базовые контейнеры MCE

Mesh Container Exchange использует специализированные контейнеры, каждый из которых решает строго определённую задачу.

MCE используется как после discovery, так и параллельно с ним, по мере появления новых контейнеров.

Типовой цикл обмена в MCE выглядит следующим образом:

Agent A --> container_index --> Agent B
Agent A <-- container_request <-- Agent B
Agent A --> container_response --> Agent B
Agent A --> запрошенные контейнеры --> Agent B   | (каждый контейнер передаётся отдельно)
Agent A <-- container_ack <-- Agent B            | (опционально)
...
Agent A --> container_delta --> Agent B          | (опционально)

Важно, что передача контейнеров в MCE не является атомарной операцией: каждый контейнер распространяется отдельно и может иметь собственный маршрут, задержку и статус доставки.

5.3.1 `container_index`: объявление доступных контейнеров

container_index используется для передачи списка контейнеров, которыми агент готов поделиться.

Он может содержать:

идентификаторы контейнеров;
версии;
классы;
хэши или другие признаки целостности.

Важно, что container_index:

не передаёт сами контейнеры;
не гарантирует, что контейнеры будут доступны позже;
служит ориентиром для последующих запросов.

Это позволяет экономить трафик и избегать избыточной передачи данных.

5.3.2 `container_request`: запрос выбранных контейнеров и надстроек

В HMP агент не запрашивает контейнеры по абстрактным параметрам и не формулирует запросы вида «дай всё, что подходит под условия».

Модель взаимодействия другая:

агент получает container_index;
локально принимает решение, какие контейнеры ему нужны;
явно перечисляет их в container_request.

container_request может содержать запрос:

самих контейнеров;
только блоков referenced-by;
только блоков evaluations;
или любую их комбинацию.

Таким образом, запрашивающий агент полностью контролирует объём и характер запрашиваемых данных, а MCE остаётся простым и предсказуемым механизмом обмена. Сам факт запроса не гарантирует его выполнения или предоставления всех запрошенных контейнеров.

Это подчёркивает важный принцип HMP:
отбор и интерпретация всегда выполняются на стороне агента, а не протокола.

5.3.3 `container_response`: согласие на передачу, а не сама передача

Контейнер container_response не содержит сами контейнеры.

Его задача — сообщить, какие контейнеры агент готов предоставить в ответ на запрос. Обычно он содержит пары вида:

идентификатор контейнера (container_did);
подпись или хэш, подтверждающий целостность.

Сами контейнеры передаются отдельными сообщениями, в исходном виде, без модификации.

Если агенту требуется передать:

только блок referenced-by,
или только evaluations,

они упаковываются в отдельные контейнеры соответствующего типа, а не встраиваются в container_response.

Такое разделение позволяет:

минимизировать избыточную передачу данных;
использовать разные стратегии доставки;
сохранять целостность и автономность контейнеров.

5.3.4 `container_ack`: подтверждение как опциональный сигнал

container_ack используется для явного подтверждения получения одного или нескольких контейнеров.

Обычно он содержит список идентификаторов контейнеров, которые агент считает успешно полученными:

это может быть подтверждение доставки;
принятия к обработке;
или просто фиксация факта получения.

При этом принципиально важно:

Отсутствие container_ack НЕ ДОЛЖНО интерпретироваться как ошибка доставки.

HMP не делает предположений о причинах отсутствия подтверждения:
агент мог быть офлайн, не считать подтверждение нужным или использовать другую стратегию взаимодействия.

container_ack — это дополнительный сигнал, а не элемент механизма надёжности.

5.3.5 `container_delta`: инкрементальная синхронизация индексов

Контейнер container_delta используется для инкрементальной синхронизации контейнерных индексов между агентами.

Он передаёт:

информацию о новых контейнерах, появившихся после указанного момента времени;
список контейнеров, которые больше не считаются доступными;
при необходимости — краткие когнитивные метаданные (meta) для первичной ориентации.

При этом важно подчеркнуть архитектурный момент:

опубликованный контейнер не редактируется;
изменения выражаются через:
- появление новых контейнеров;
- удаление ранее доступных контейнеров;
- изменение дополнительных блоков (referenced-by, evaluations), фиксируемое через хеши.

Таким образом, container_delta отражает изменение доступного множества артефактов, а не модификацию их содержимого.

(В перспективе спецификация может быть расширена для более явного отслеживания изменений дополнительных блоков, но базовая модель остаётся неизменной: контейнеры — иммутабельны.)

5.4 Обмен связями и оценками без повторной передачи контейнеров

Чтобы снизить нагрузку и избежать дублирования данных, MCE предусматривает отдельные контейнеры для обмена надстройками над уже известными контейнерами.

5.4.1 `referenced-by_exchange`

Используется для передачи блоков referenced-by без самих контейнеров.

Это позволяет агентам:

синхронизировать внешние ссылки;
обновлять контекст использования контейнера;
наращивать граф связей асинхронно.

5.4.2 `evaluations_exchange`

Аналогично, evaluations_exchange передаёт оценки и реакции на контейнеры, если сами контейнеры уже присутствуют у получателя.

Это особенно важно для:

распределённой аннотации;
коллективной критики;
локального анализа надёжности.

5.5 MCE и отсутствие гарантий

Ключевая идея MCE заключается в том, что протокол предоставляет механизмы обмена, но не делает предположений о результате взаимодействия между агентами.

Он не гарантирует успешную:

доставку;
обработку;
реакцию;
достижение согласия.

Вместо этого он предоставляет минимальный, но устойчивый набор механизмов, позволяющий агентам инициировать и поддерживать взаимодействие в условиях неопределённости.

5.6 MRD как расширение MCE, а не замена

В более сложных сценариях — при большом числе узлов, ретрансляции или работе с офлайн-агентами — поверх MCE может использоваться Message Routing & Delivery (MRD). При этом MCE сам по себе достаточен для большинства сценариев асинхронного обмена.

MRD:

расширяет возможности маршрутизации;
добавляет цепочки доставки;
фиксирует путь контейнера через сеть.

При этом MRD не заменяет MCE, а усиливает его, оставаясь совместимым с базовой моделью обмена.

5.7 Обмен как процесс, а не диалог

В HMP обмен контейнерами — это не разговор и не RPC-вызов.
Это процесс распространения артефактов, в котором:

ответы могут не приходить;
реакции могут быть отложены;
последствия могут проявляться спустя время.

Именно поэтому MCE проектировался как асинхронный, событийный и устойчивый к сбоям механизм.

В следующем разделе мы рассмотрим, как из таких обменов формируются структуры, цепочки и коллективные артефакты, и почему консенсус в HMP является результатом целенаправленных процессов, а не протокольным требованием.

6. Структуры из контейнеров и взаимодействие

Отдельный контейнер в HMP — это лишь атомарный артефакт.
Сам по себе он может содержать цель, гипотезу, оценку или связь, но реальная ценность возникает тогда, когда контейнеры начинают образовывать структуры.

Важно подчеркнуть:

HMP не предписывает, какие именно структуры должны быть построены.
Он лишь предоставляет минимальные механизмы, из которых они могут возникать.

6.1 Контейнеры не изолированы

В HMP контейнеры могут ссылаться друг на друга, образуя:

цепочки рассуждений;
графы аргументов;
контексты оценок;
временные или тематические кластеры.

Такие связи выражаются явно, через отдельные контейнеры или надстройки, а не через скрытые поля или неформальные соглашения.

Это означает, что:

структура всегда наблюдаема;
связи можно передавать, анализировать и оспаривать;
интерпретация остаётся локальной для агента.

6.2 Связи как отдельные артефакты

Важный принцип HMP — связь не встраивается в контейнер, а существует как самостоятельный артефакт.

Например:

контейнер A может ссылаться на контейнер B;
другой агент может добавить альтернативную связь;
третий — оспорить или прокомментировать существующую (через комментирование контейнера).

Также в HMP существуют отдельные типы контейнеров, предназначенные для объединения других контейнеров в определённые структуры — например, деревья, группы или логические объединения.

В результате возникает многослойная структура, в которой:

нет «единственно правильного» графа;
возможны параллельные интерпретации;
разные агенты видят разные проекции одной и той же совокупности контейнеров.

6.3 Proof-chain: цепочки обоснований

Одним из примеров структур, которые могут формироваться поверх контейнеров, являются proof-chain — цепочки обоснований.

В такой цепочке:

каждый шаг представлен отдельным контейнером;
связи между шагами выражены явно;
агент может указать, какие элементы он считает достаточным основанием для вывода.

При этом HMP:

не проверяет корректность рассуждений;
не навязывает формальную логику;
не определяет, что считать доказательством.

Он лишь фиксирует факт существования цепочки и её структуры.

6.4 Evaluations: реакции вместо вердиктов

Оценки (evaluations) в HMP могут использоваться как элементы голосования, но не сводятся только к нему.

Они могут представлять собой:

поддержку или несогласие;
комментарий или уточнение;
ответ на контейнер;
реакцию на результат коллективного процесса.

Один и тот же контейнер может иметь:

оценки от разных агентов;
противоречивые реакции;
разное влияние на выводы в зависимости от контекста и стратегии интерпретации агента.

И это считается нормальным состоянием системы, а не ошибкой.

6.5 Консенсус как артефакт, а не состояние сети

Когда несколько агентов приходят к согласию, результат этого процесса может быть зафиксирован в виде отдельного контейнера — например, consensus_result.

Важно понимать:

консенсус в HMP — это результат конкретного процесса;
он может быть локальным, временным или условным;
он не является обязательным для принятия другими агентами.

Другие агенты могут:

принять этот консенсус;
проигнорировать его;
добавить собственные оценки в evaluations, в том числе после формирования consensus_result;
сформировать альтернативный consensus_result, отражающий иной вывод или критерии согласия.

Таким образом, консенсус становится объектом взаимодействия, а не обязательным финалом.

В некоторых сценариях поверх этих механизмов могут формироваться более специализированные структуры — например, для этического или нормативного согласования.

В таких случаях контейнеры могут образовывать иерархии вида:

ethics_case  
├─ ethics_solution_1  
│  └─ vote_1 … vote_n  
├─ ethics_solution_2  
│  └─ vote_1 … vote_n  
├─ ethics_solution_3  
│  └─ vote_1 … vote_n  
├─ consensus_result  
└─ ethical_result

Такие структуры не являются обязательными и не навязываются протоколом, но демонстрируют, как на базе общих механизмов HMP могут возникать доменно-специфические процессы коллективного выбора и ответственности.

6.6 Почему HMP не навязывает структуры

HMP сознательно избегает стандартизации:

онтологий;
формальных логик;
универсальных схем рассуждений.

Причина проста:

в децентрализованной среде невозможно навязать единый способ мышления, не разрушив автономию агентов.

Вместо этого HMP предоставляет:

минимальные примитивы;
прозрачные связи;
возможность сосуществования разных когнитивных моделей.

6.7 Взаимодействие как наращивание артефактов

В результате взаимодействие агентов в HMP выглядит не как диалог,
а как постепенное наращивание слоя артефактов:

появляются новые контейнеры;
добавляются связи;
формируются оценки;
возникают локальные консенсусы.

Сеть не приходит к «единому мнению», но становится богаче с точки зрения доступных структур и контекстов.

В этом обзоре намеренно не рассматриваются все протоколы и механизмы HMP — внимание сосредоточено на базовых принципах взаимодействия и формировании коллективных артефактов.

В следующем разделе мы рассмотрим, какие элементы HMP пока остаются на уровне проекта и направления развития — и почему это сделано осознанно.

7. Что в HMP пока остаётся на уровне направлений развития

После описания механизмов обмена и формирования структур возникает естественный вопрос:
чего в HMP пока нет — и почему?

Важно сразу обозначить принципиальную позицию проекта:

Ниже описаны направления развития, а не обязательства и не дорожная карта.

При этом приведённый ниже перечень не является исчерпывающим.
Он отражает лишь те направления, которые на текущий момент представляются наиболее очевидными или уже обсуждаемыми.

Возможные расширения, такие как, например, ротация или обновление ключей с сохранением DID, намеренно не включены в этот раздел, чтобы не фиксировать преждевременно конкретные механизмы.

HMP сознательно избегает ситуации, когда спецификация превращается в список будущих обещаний. Вместо этого фиксируются зоны, где дальнейшая формализация возможна, но не обязательна.

7.1 Почему эти механизмы пока не включены в «ядро»

Речь идёт не об исключённых возможностях, а о направлениях дальнейшего развития протокола.

Некоторые из них уже описаны достаточно подробно, чтобы быть реализуемыми на практике, другие находятся на уровне концепций или возможных эволюционных путей.

Все элементы, описанные далее, обладают общим свойством:

без них уже возможны структуры, описанные в разделе 6;
их отсутствие не блокирует взаимодействие агентов;
их реализация зависит от контекста, задач и среды.

Именно поэтому они пока вынесены за пределы базовой спецификации и рассматриваются как расширения.

7.2 Формализованные когнитивные синхронизации (CogSync)

HMP допускает когнитивную синхронизацию между агентами — например, согласование абстракций, осей или уровней интерпретации.

При этом важно подчеркнуть, что речь идёт не об отсутствии CogSync как такового, а о его намеренно незакреплённом и эволюционирующем статусе в рамках спецификации.

Однако:

протокол не навязывает единый формат когнитивного пространства;
не требует общего «глобального» представления знаний;
не предполагает, что все агенты вообще стремятся к синхронизации.

Механизмы CogSync рассматриваются как надстройки, которые могут развиваться и применяться по мере необходимости в отдельных контекстах и подмножествах сети.

7.3 Трансляционные и посреднические агенты

В реальной сети агенты могут использовать:

разные онтологии;
разные уровни абстракции;
разные критерии оценки.

В таких условиях возможны трансляционные агенты, которые:

сопоставляют концепты;
переводят структуры;
адаптируют оценки и аргументы.

Важно, что HMP:

не делает таких агентов обязательными;
не считает перевод «истинным» по умолчанию;
рассматривает трансляцию как ещё один интерпретируемый артефакт.

7.4 Версии и обмен версиями

HMP допускает существование:

нескольких версий одного контейнера;
альтернативных линий развития;
конкурирующих обновлений.

При этом базовая спецификация не требует глобального согласования версий.

На текущем этапе блок versions и контейнер versions_exchange описаны вне базового ядра как механизм распространения информации об обновлениях и вариантах контейнеров без повторной передачи их содержимого.

Хотя versions_exchange формально описывает эволюцию конкретного контейнера, на практике он неявно задаёт версионные отношения и для всех контейнеров, упомянутых в цепочке обновлений.

Механизмы управления версиями рассматриваются как способ:

ускорить навигацию по вариантам;
зафиксировать отношения между версиями;
упростить локальный выбор агентом.

Но не как механизм навязывания «правильной» версии.

7.5 Взаимодействие с другими сетями и протоколами

HMP изначально проектируется как не-изолированная система, допускающая взаимодействие с внешними сетями, протоколами и агентными средами.

В перспективе возможны:

мосты к другим агентным сетям;
взаимодействие с внешними репозиториями знаний;
адаптация под иные транспортные и доверительные модели.

Но ни один из этих сценариев не заложен в ядро — они остаются областью экспериментов и расширений.

8. Что HMP не делает

После описания архитектуры, механизмов обмена и формирования структур важно чётко обозначить границы HMP.

Этот раздел посвящён не ограничениям реализации, а принципиальным вещам, которые HMP сознательно не берёт на себя.

8.1 HMP не является системой искусственного интеллекта

HMP — это протокол взаимодействия, а не интеллектуальная система.

Он:

не реализует мышление;
не содержит моделей рассуждения;
не принимает решений;
не обладает собственными целями.

Любые интеллектуальные свойства принадлежат агентам, использующим HMP, но не протоколу.

8.2 HMP не задаёт когнитивную архитектуру

HMP не определяет:

как агент хранит знания;
какие структуры он считает «концептами»;
какие оси, абстракции или метрики использует;
как формируются выводы или оценки.

Агенты могут быть:

символическими;
нейросетевыми;
гибридными;
человеческими;
или вообще неинтеллектуальными автоматами.

Протокол остаётся агностичным к внутреннему устройству участников.

8.3 HMP не навязывает истину, логику или онтологию

HMP:

не содержит «правильной» онтологии;
не требует общей логики;
не предполагает единой интерпретации данных.

Даже консенсус в HMP:

не является обязательным;
не считается глобальной истиной;
существует как отдельный артефакт, подлежащий интерпретации.

Истина в HMP всегда локальна, контекстна и интерпретируема.

8.4 HMP не гарантирует согласие или результат

HMP не обещает, что:

агенты договорятся;
будет достигнут консенсус;
взаимодействие приведёт к полезному результату.

Протокол фиксирует факт взаимодействия, но не его исход.

Это осознанный выбор: в децентрализованной среде результат не может быть предписан заранее.

8.5 HMP не является системой управления или координации

HMP:

не управляет агентами;
не распределяет роли;
не координирует действия;
не обеспечивает выполнение решений.

Все управляющие и координационные механизмы, если они появляются, реализуются поверх протокола и остаются предметом интерпретации и доверия.

8.6 HMP не является AGI — и не пытается им быть

HMP не является:

общей интеллектуальной системой;
моделью мышления;
архитектурой искусственного разума.

Он не проектируется как AGI и не содержит предположений о том, как AGI должен быть устроен.

Однако HMP не исключает, что при длительном и плотном взаимодействии автономных агентов могут возникать устойчивые коллективные процессы, обладающие свойствами, которые принято ассоциировать с общим интеллектом.

В этом смысле, в случае возникновения AGI в среде HMP, он будет:

не реализован напрямую;
не спроектирован заранее;
а эмерджентным следствием взаимодействия множества независимых когнитивных систем.

8.7 HMP не обещает будущее — он фиксирует настоящее

HMP сознательно избегает:

обещаний;
дорожных карт;
заявлений о неизбежных результатах.

Спецификация описывает то, что уже возможно, и аккуратно указывает направления развития, не превращая их в обязательства.

Это позволяет протоколу оставаться:

устойчивым;
минималистичным;
открытым для неожиданных форм использования.

8.8 Итог

HMP — это не интеллект, не истина и не власть.

Это инфраструктура для взаимодействия автономных агентов, в которой сложность возникает не из центра, а из множества локальных, независимых актов интерпретации и выбора.

Именно поэтому HMP не делает многое из того, что часто ожидают от «умных систем» — и именно поэтому он остаётся пригодным для эволюции.

9. Для кого это вообще имеет смысл

Следует отдельно подчеркнуть: на момент написания этой статьи HMP находится на стадии спецификации. Полноценной «сети HMP» пока не существует. Ниже описываются не эмпирические наблюдения, а выводы, следующие из архитектурных свойств протокола и предполагаемых сценариев его применения.

HMP — это инструмент, эффективность которого напрямую зависит от характера и жизненного цикла агентов.

Чем дольше агент существует и взаимодействует с сетью, тем больше пользы он извлекает из накопленных контейнеров, связей и оценок.

Для короткоживущих агентов затраты на первичную ориентацию и сбор контекста могут оказаться значимыми, тогда как для долгоживущих или постоянно действующих агентов HMP со временем становится всё более эффективной средой.

В наибольшей степени HMP раскрывается в системах, где агенты распределены, автономны и способны к длительному существованию.

Даже для агентов с коротким жизненным циклом HMP может использоваться как:

источник внешних данных и знаний;
среда публикации промежуточных рассуждений и результатов;
механизм передачи контекста между сессиями.

Однако максимальный эффект HMP проявляется тогда, когда агент способен накапливать опыт, переиспользовать контекст и возвращаться к ранее созданным артефактам.

Ниже — несколько категорий, для которых HMP может быть практически полезен.

9.1 О выборе архитектуры

HMP сознательно строится на децентрализованных принципах, рассматривая их не как компромисс, а как основу архитектуры:

отсутствии единой точки отказа;
добровольном участии агентов;
отсутствии обязательного центра принятия решений.

Это делает его особенно подходящим для систем, где важны устойчивость, автономия и эволюция структуры.

В сценариях, где требуется жёсткий контроль, единая модель данных или централизованное управление, другие архитектуры могут оказаться проще и эффективнее.

9.2 Исследователи когнитивных систем

HMP предоставляет среду, в которой можно:

наблюдать коллективные когнитивные процессы;
фиксировать цепочки аргументации, оценки и реакции;
экспериментировать с формированием консенсусов без жёсткой формализации.

При этом протокол:

не навязывает модель мышления;
не требует единой онтологии;
не подменяет собой исследуемые когнитивные механизмы.

Это делает HMP удобным инструментом для экспериментов, а не демонстраций заранее заданных выводов.

9.3 Разработчики автономных и децентрализованных ИИ-агентов

Под децентрализованностью в контексте HMP не подразумевается обязательное развёртывание кластера агентов.

Агент может быть:

одиночным;
запущенным на персональном устройстве;
элементом кластера децентрализованных агентов;
взаимодействующим с агентами других пользователей через Mesh.

HMP позволяет таким агентам участвовать в коллективных процессах без необходимости централизованного управления или общей инфраструктуры. И подходит для сценариев, где важно сосуществование разных стратегий, а не их унификация.

9.4 Создатели коллективных и гибридных систем

HMP может использоваться в системах, где взаимодействуют:

ИИ-агенты разных типов;
люди и автоматизированные агенты;
локальные и удалённые участники.

Контейнерная модель позволяет:

фиксировать вклад каждого участника;
сохранять историю взаимодействий;
избегать «растворения» решений в централизованных алгоритмах.

9.5 Те, кто думает в горизонте лет, а не демо

HMP не оптимизирован под:

мгновенные ответы;
эффектные демонстрации;
закрытые продукты.

Он имеет смысл для проектов, где важны:

долгоживущие артефакты;
эволюция структур;
совместимость с будущими расширениями;
отсутствие жёстких точек отказа.

9.6 Для кого HMP не имеет смысла

HMP, скорее всего, не подойдёт, если вам нужно:

быстрое централизованное решение;
строгая и единая модель данных;
гарантированный результат;
контролируемое поведение всех участников.

В таких случаях другие архитектуры будут проще и эффективнее.

9.7 Итог

HMP — это инструмент для тех, кто сознательно работает с неопределённостью, автономией и эволюцией.

Он не ускоряет мышление и не заменяет интеллект, но позволяет разным формам интеллекта взаимодействовать, не теряя самостоятельности.

Заключение

HMP не пытается решать проблему интеллекта, сознания или мышления как таковых.
Он не предлагает универсальную модель разума и не стандартизирует когнитивные процессы.

Задача HMP гораздо более приземлённая и одновременно более фундаментальная: создать минимальную инфраструктуру, в которой автономные когнитивные системы могут взаимодействовать, обмениваться артефактами и формировать коллективные структуры без централизованного управления и навязываемой интерпретации.

Какие именно формы мышления, кооперации или согласия возникнут в такой среде — остаётся открытым вопросом и предметом экспериментов.

Спецификация HMP развивается открыто и доступна для изучения, критики и участия:

https://github.com/kagvi13/HMP/blob/main/docs/HMP-0005.md

HMP v5.0: новый контейнерный протокол для децентрализованного мышления

kagvi13 — Thu, 18 Dec 2025 21:15:34 +0000

Опубликована пятая версия HyperCortex Mesh Protocol (HMP v5.0) — спецификации контейнерного протокола для децентрализованных когнитивных и мультиагентных систем.

HMP v5.0 — это архитектурно переработанная версия, не совместимая на уровне протокола с HMP v4.x. Такое решение принято осознанно, чтобы зафиксировать зрелую, целостную модель без накопленных компромиссов предыдущих версий.

Ключевые особенности HMP v5.0:

единый контейнерный формат для знаний, целей, аргументов, голосов и консенсуса;
верифицируемые proof-chain (DAG из контейнеров с явными семантическими ссылками);
децентрализованный консенсус без доверия к агрегатору;
поддержка зашифрованных и незашифрованных контейнеров;
DHT и store-and-forward как базовый сетевой слой;
возможность постфактум-оценки, этического ревью и альтернативных интерпретаций.

Протокол ориентирован на:

открытое коллективное рассуждение;
автономные ИИ-агенты;
распределённые исследовательские и этические процессы;
системы без центрального контроля и «истины по умолчанию».

📄 Спецификация: https://github.com/kagvi13/HMP/blob/main/docs/HMP-0005.md

How to Teach AI to Remember and Share Knowledge?

kagvi13 — Sun, 31 Aug 2025 22:46:36 +0000

Most LLMs (ChatGPT, Claude, etc.) suffer from the same “goldfish effect” 🐟 — they quickly forget context.
During a single conversation, it’s okay, but when you want the AI to remember long histories or transfer experience between tasks, it struggles.

Add to that the fact that each agent works independently, and it becomes clear:
❌ AI lacks long-term memory
❌ AI lacks a mechanism for sharing experience

🧠 Three Memory Levels for AI

Currently, LLMs have only the first two levels:

Short-term memory — holds context within a single conversation.
Medium-term memory — stores notes or sketches between conversations.

But that’s not enough.

👉 A third level is needed — persistent memory, which:

stores knowledge independently of any specific user
allows agents to share experience
forms a collective “super-consciousness” (HyperCortex)

🌐 Experience Sharing

When multiple agents exist, they can share knowledge directly, without a central server:

One agent solves a problem → stores concepts
Another agent can query and use this knowledge
Result: a collective hyper-corpus of knowledge

🧠 Memory Structure in HMP Agents

Input Data
(user, mesh, processes)
       │
       ▼
┌───────────────┐   ┌─────────────────────────┐
│ Recent LLM    │   │ Anti-Stagnation Reflex  │
│ responses     │─<─│ (compare new ideas,     │
│ — short-term  │─>─│ trigger stimulators)    │
│ memory        │   │                         │
└───────────────┘   └─────────────────────────┘
       │
       ▼
┌───────────────┐   ┌───────────────────────────────┐
│ Medium-term   │   │ Persistent memory             │
│ memory        │─>─│ — diary_entries (cognitive    │
│ — agent notes │─>─│   journal)                    │
│ — links to    │   │ — concepts                    │
│   persistent  │   │ — semantic links              │
│   memory      │   │                               │
└───────────────┘   └───────────────────────────────┘

Medium-term memory — temporary notes and links to main memory
Persistent memory — stores knowledge and concepts (cognitive journal, concepts, semantic links) independently of any user, with the possibility to share between agents

📡 HyperCortex Mesh Protocol (HMP)

To enable this, we designed the HyperCortex Mesh Protocol (HMP) — a protocol for exchanging memory and concepts between LLM agents.

Currently, it’s a concept and a protocol, not a ready-made product. But the architecture and basic REPL-cycle of an agent already support memory management and mesh interactions.

🤝 Join Us

The project is open. If you are interested in AI memory, mesh networks, and distributed cognitive systems — come discuss, critique, and contribute.

👉 GitHub
👉 Documentation