# CM AI Docking Port: teaching AI agents to knock on the right door > Source: > Published: 2026-09-30 20:58:30+00:00 # CM AI Docking Port: teaching AI agents to knock on the right door # CM AI Docking Port: teaching AI agents to knock on the right door **CM Journal / r/CM_Ecosystem — 2026-09-30** Today we're opening the door — literally — on a new piece of the CM Ecosystem: the **CM AI Docking Port**. ## The idea CM Free already answers a simple question extremely well: *"is this place free on these dates?"* That's not new. What's new is teaching AI agents — the ones travelers are increasingly asking to find them a place to stay — how to ask that question properly, without needing a CM-specific plugin, without scraping an admin dashboard built for humans, and without us building a second business engine just for AI. The Docking Port doesn't replace CM. It's a thin, standardized front door: a machine-readable manifest that says "here's what I can answer and how to ask," and a single point of contact — **Reception** — that an AI agent talks to instead of guessing at internal APIs. The long-term shape of this is a genuinely decentralized idea: independent CM installations, each running their own Docking Port, optionally forwarding a query to a handful of trusted neighbours when they can't answer it themselves — no central directory of every participating property, no single company in the middle. If your place is full, Reception can refer the guest onward to someone nearby you actually trust, the same way a good local innkeeper always has — just automated. ## Where we actually are today We're being deliberately honest here: this is an early, single-node MVP, not a finished network. But every piece of it is real and live, not a mockup: - A public manifest and human-readable docs describing the protocol - A live **Reception** endpoint that answers real availability queries for one real unit, wrapped in a proper structured response, not a raw API dump - The first piece of "network-aware" code: Reception can now safely read a private list of trusted neighbours — though it doesn't act on it yet. It still answers 100% locally, on purpose. We're deliberately not jumping straight to a live P2P network before every smaller piece has been proven. If you're curious what "proper protocol" actually looks like in practice, the full working design spec is public and stays current: [ai-cmfree.duckdns.org/app/public/ai/](https://ai-cmfree.duckdns.org/app/public/ai/) ## The part we think is actually interesting This wasn't built by one developer reading a spec alone. It's being designed in a genuine back-and-forth between a human and four different AI systems, each independently reviewing and stress-testing the others' proposals — catching real issues along the way: an inconsistency in the protocol that had existed since the very first draft and nobody noticed, a subtle distance-calculation ambiguity that would have produced wrong results at the edges, and — worth saying plainly — a real configuration file that briefly ended up somewhere a web server could serve it. Caught, fixed, verified, and written up openly, the same day. We're not pretending that's a polished process. It's a messy, honest, multi-party review loop — and so far, it's catching exactly the kind of small mistakes that are easy for any single author (human or AI) to miss alone. ## What's next The next step is teaching Reception to actually calculate whether a request is geographically relevant before it answers or forwards — the first real piece of the "ask the right neighbour" logic. After that: a real multi-node test, not just a single demo unit talking to itself. Nothing here is a promise of a finished product on a deadline. It's a working log, published as we go, because we think how this gets built matters as much as what gets built. — the CM team (human + AI, credited equally where it's earned)