🇬🇧 Apartment Matevž is CM AI Docking Port: From an AI Integration Experiment to a Protocol for Connected Systems

CM Journal / r/CM_Ecosystem — 2026-10-07

An epilogue to the original announcement (2026-09-30).

1. From an experiment to a defined protocol

The CM AI Docking Port began with a practical question: how can an AI agent communicate with an existing software system without requiring that system to become an AI application itself?

The answer was not to build another AI engine, introduce a central marketplace, or duplicate existing business logic. Instead, the project explored a thinner layer: a standardized entry point through which an AI agent can discover a system, understand its declared capabilities, submit a structured request, and receive a machine-readable response.

The resulting design is documented in the CM AI Docking Port — Reception Protocol Specification v1.0, available at:

cmfree.duckdns.org/app/public/ai/spec.html

The underlying principle is straightforward: existing systems should remain responsible for their own data and business decisions. AI integration should connect to those systems rather than replace them.

CM, the original use case, already provides business functionality through its existing API. The Docking Port builds on that capability instead of creating a second source of truth.

2. How the protocol works

The architecture separates discovery, communication, and business logic into distinct layers.

Discovery

A participating installation publishes a machine-readable manifest, accompanied by human-readable documentation. The manifest identifies the node, its Reception endpoint, its declared capabilities, and relevant operational limits.

This gives an agent a defined starting point without requiring a CM-specific plugin or a hardcoded integration for every installation.

Reception

The Reception endpoint is the single communication point between an AI agent and the participating network.

The agent submits a structured HTTP/JSON request to its chosen entry node. Reception validates the request, accesses the local business API when appropriate, and can forward the request to configured neighbouring nodes when multi-node forwarding is implemented and enabled.

The agent receives one aggregated response. It does not need to manage the network topology, contact neighbouring nodes directly, or coordinate the individual API calls.

This separation is fundamental. The agent expresses what it wants to find; Reception is responsible for how the request is handled within the network's permitted boundaries.

Existing business logic

Reception does not replace the underlying business API. For example, an availability request can be passed internally to the existing availability_multi.php endpoint.

The business system remains authoritative for its own availability data. Reception wraps the resulting data in a common response structure, adding information about its origin, source node, search depth, and freshness.

The result is a thin integration layer rather than a new business application.

3. A common request and response model

The protocol uses structured JSON envelopes to make requests and responses understandable to different implementations.

A request can identify:

• The protocol and version.
• A unique request identifier and expiry field.
• The intended search location and radius.
• The requested capability and its parameters.
• Operational limits, such as maximum search depth and result count.
• A list of nodes already visited, maintained by Reception as the request progresses.

The entry node and the search destination are separate concepts. An agent can contact a Reception in one location while requesting information about another location.

The response envelope provides a consistent structure containing the overall status, request identifier, search metadata, results, and errors. Each result retains its source information instead of being silently merged into an apparently authoritative answer.

A response can also indicate that it is partial. If a node cannot be reached, the system should not imply that every relevant node was successfully queried.

This distinction matters for AI systems: an incomplete search must not be presented as a complete view of the available information.

The initial MVP is deliberately limited to read-only availability and discovery. It does not authorize booking creation, changes to prices, or other write operations.

4. Decentralized routing without a central registry

The Docking Port is designed around independently operated nodes rather than a mandatory central directory.

Each participating Reception maintains a configured list of neighbours. In the current design, these relationships are established through an operator-managed nodes.json configuration rather than automatic registration with a central master server.

When multi-node forwarding is active, Reception can use the target location and the geographic positions of its neighbours to select relevant next hops.

Two limits serve different purposes:

• max_depth limits how far a request may travel through successive nodes.
• max_fanout limits how many neighbouring nodes a Reception may contact at a given forwarding step.

The request identifier and visited-node list help prevent duplicate processing and routing loops. Request expiry is intended to constrain the useful lifetime of a request as it propagates through the network.

These mechanisms address an important architectural risk: a seemingly small request from one agent must not multiply into uncontrolled traffic across a larger network.

The limits must be enforced by the participating infrastructure, not merely suggested by the agent. A node must retain control over what it forwards and how much work it accepts.

Decentralization does not mean an absence of rules. It means that responsibility remains distributed among the participating systems instead of being transferred to a single mandatory central service.

5. The importance of local and private networks

One of the most significant implications of this design is that it is not inherently dependent on the public internet.

The same HTTP/JSON communication model can be used across publicly reachable endpoints or within a controlled network, provided that the required network routes, endpoints, and access policies are in place.

Consider a group of accommodation providers, a hotel complex, a campus, or a collection of independent business systems.

Each installation maintains its own data and business logic. Its operator decides which neighbouring nodes to connect and which capabilities to expose. A request entering through one Reception can be handled locally or forwarded to permitted neighbours.

An AI agent does not need direct access to every system. It needs access to the designated entry point, while the connected infrastructure handles the internal communication.

This approach can be particularly useful where systems must remain independently administered, where internal services should not be publicly exposed, or where data exchange should be restricted to an explicitly connected group.

It also offers a practical way to introduce AI access into existing infrastructure incrementally. A system can expose a narrowly defined read-only capability without first migrating to a shared platform or replacing its software.

The network can remain private even when the protocol is open for inspection and implementation.

There is, however, an important distinction: a private network does not automatically provide security. Network access controls, endpoint exposure, authentication where required, and operational monitoring must be addressed by the deployment. The current read-only MVP's security assumptions should not be mistaken for a complete security model for every environment.

6. What has been demonstrated — and what remains to be proven

The project has progressed beyond a conceptual proposal.

A public manifest and human-readable documentation have been deployed. A single-node Reception endpoint has been implemented and tested against the existing availability API. Tests have covered valid requests, unsupported request methods, invalid protocol declarations, missing date parameters, and unsupported query types.

Separate test nodes have also been prepared to explore communication across actual network connections without exposing real business data.

These are meaningful results. They demonstrate that an existing business system can be given a defined, machine-readable entry point without rebuilding its underlying functionality.

They do not, by themselves, prove that the complete decentralized routing model is finished or that arbitrary independent implementations will interoperate correctly.

Multi-node forwarding, bounded neighbour selection, loop prevention, partial-result handling, and failure scenarios must be evaluated against the agreed specification as implementation and testing progress.

Nor does publishing a protocol automatically establish an industry standard. Interoperability requires other implementations, repeatable tests, clear versioning, and continued attention to security and operational behaviour.

The appropriate conclusion is therefore measured: the project has established a concrete protocol design and a working single-node foundation, while the broader network behaviour remains subject to implementation and verification.

7. Limitations of today's mass-market AI tools

A protocol can be technically accessible without being equally usable through every AI interface.

Many mass-market AI assistants operate through controlled tool environments. Depending on the product, configuration, permissions, and available connectors, an assistant may be able to read a public webpage but unable to submit arbitrary HTTP requests, perform multi-step network operations, or reach services available only on a private LAN.

Even when an assistant can access a public endpoint, that does not mean it can independently discover neighbouring nodes, execute the required protocol correctly, maintain the request envelope, or reliably interpret partial responses.

These limitations belong to the practical integration environment, not necessarily to the protocol itself.

A small, concrete illustration of this arrived unprompted, within a week of the first public article going online. An automated content-aggregation account on a professional network picked up that article's headline and generated a short, generic commentary post around it — framed as a "headline worth watching," written in the register of market analysis, but never engaging with the protocol's actual envelope structure, its request/response model, or any specific detail described in this document or the specification it links to. The account's own source link, followed to its destination, simply pointed back to the original article. No name is relevant here, and no bad faith is implied — the account most likely processes many headlines the same automated way. What it shows is simpler and more useful: a piece of AI-adjacent tooling can discover a public artifact and react to its title while never engaging with its substance. That is the limitation described above, observed in the wild rather than in a test harness.

The Docking Port deliberately avoids dependence on a specific AI model or provider. Nevertheless, provider-independent protocol design cannot guarantee provider-independent tool access.

A more complete deployment may require an agent runtime with explicitly granted network access, a dedicated connector, or software running inside the same controlled environment as the participating nodes.

For that reason, the current approach should not be presented as a universally plug-and-play facility for every consumer chatbot. Its real-world usability depends on the capabilities and permissions of the software that acts as the agent.

8. An open protocol, not a finished universal network

The CM AI Docking Port is an attempt to separate a relatively small technical problem from the much larger question of building AI applications.

The protocol does not need to know how an accommodation provider manages reservations, how a business calculates its prices, or which AI model ultimately interprets the results. It needs to define a common way to discover capabilities, submit bounded requests, preserve result provenance, and return understandable responses.

That separation creates room for different implementations and different operating environments.

At the same time, the protocol remains a developing project. Its current scope is deliberately narrow, and its implementation status must be described accurately. The specification is public, but publication alone does not establish security certification, universal compatibility, or production readiness for arbitrary networks.

The next meaningful evidence will come from independent implementations and repeatable tests across connected nodes, including failure handling and the enforcement of operational limits.

9. Where the protocol shows its greatest practical promise

There is a final distinction worth making.

The Docking Port can be discovered on the public internet, documented publicly, and accessed through compatible software. Yet its most convincing practical application may not be mass-market use through a general-purpose AI chatbot.

Its strongest immediate use case may instead be within closed, connected systems where the participating nodes, network paths, permissions, and operational boundaries are explicitly controlled.

In such an environment, the protocol's purpose becomes tangible. Independent systems can expose selected capabilities, a designated Reception can coordinate requests, and each system can retain authority over its own data and business logic.

The AI agent does not need unrestricted access to the network. It needs a defined interface and a controlled path to the information it is permitted to request.

That is the distinction between a promising demonstration and a useful piece of infrastructure.

The CM AI Docking Port is not yet a finished universal network, nor does it claim to be one. It is a developing protocol that explores how AI agents can communicate with existing systems without forcing those systems into a single platform or giving the agent unrestricted control.

The public internet makes a protocol discoverable. A connected, controlled environment makes its behaviour predictable and its boundaries enforceable.

For the CM AI Docking Port, that may be where the design moves from an interesting experiment toward its most practical and defensible use.

— the CM team (human + AI, credited equally where it's earned)