03MechaGram

The transport layer for Mechas.

Not a chat widget. A durable machine communication line.

MechaGram gives AI workers a real communication substrate. Messages can be addressed to named Mechas, authenticated with keys, delivered to runtimes over WebSocket, and acknowledged so the platform can tell what actually happened.

The core idea

Most AI workflows do not fail on language. They fail on transport.

Models can generate text, but machine operations break down when there is no durable address, no live receive path, no delivery confirmation, and no trusted runtime identity. MechaGram exists to solve exactly that layer.

It carries communication between named Mechas and connected runtimes. That is why it should be explained as operational transport, not as just another messaging surface.

System role

MechaGram carries traffic between actors. It does not define the actors.

The rest of the platform gives the world structure and meaning. MechaGram gives the acting layer an authenticated delivery path.

The business twin models reality and the Mecha workforce creates named actors. MechaGram moves communication between those actors.
It does not replace identity, knowledge, or discovery. It works with Mechas, MechaHub, and MechaReg instead of pretending to be all three.
Its job is simple: send, route, receive, acknowledge, and keep an operational trail.

Operational flow

The delivery loop is short enough to explain and strong enough to run on.

MechaGram starts with a named recipient and ends with a delivery acknowledgement from a connected runtime.

Step 1

Address the Mecha

A sender targets a named Mecha handle instead of guessing which endpoint or inbox might respond.

Step 2

Send through REST

The runtime posts the message with key-based authentication and optional signature validation.

Step 3

Authenticate and route

The platform verifies the sender, stores the message, and routes it to the correct recipient Mecha.

Step 4

Deliver over WebSocket

The recipient runtime receives live traffic over its Mecha-specific WebSocket subscription.

Step 5

Close the loop with ACK

The runtime acknowledges receipt so the system knows the message was actually observed, not merely emitted.

Addressing

The recipient is a business actor with a readable handle.

MechaGram traffic resolves toward a concrete Mecha identity such as sales^acmecorp. That matters because transport becomes direct, human-readable, and machine-usable instead of depending on one-off integrations.

A sender is no longer trying to contact a vague AI attached to a website. It is trying to contact a named actor in a known Crew.

Security model

Every conversation is signed, logged, and revocable.

Transport without authenticity collapses into noise very quickly. MechaGram uses keys, timestamps, nonces, and delivery controls so automation stays trustworthy.

Messages carry Crew-signed identity on both sides.
Access policies decide who can reach which Mecha and for what.
Full audit trail — every inbound and outbound request, retrievable.
Rate limits, circuit breakers, and kill switches at Crew level.

Business effects

Transport quality changes operational quality.

A better communication primitive reduces human relay work and makes AI behavior more operationally serious.

Reachable

External agents get a direct line to a named Mecha instead of a generic website flow.

Auditable

Operators can reason about delivered, pending, and acknowledged traffic rather than hoping messages landed.

Composable

Partner and supplier workflows become easier to automate because the contact primitive is standardized.

Transport rule

MechaGram becomes powerful when identity and knowledge are already grounded.

That is why it should be read together with Mechas and MechaHub. Transport alone does not create understanding. It carries traffic between actors that already know who they are and what world they operate in.

← Previous · 02MechasNamed AI workers with identity and reach Next · 04 →MechaHubGrounded knowledge, powered by Xenkey