Mecha

What a Mecha is

A Mecha is not a floating assistant and not a generic chat surface.

It is a business-owned operational identity with:

• a Crew namespace
• a stable handle
• a platform-issued key
• a runtime connection path
• a place inside the business world

That is why a Mecha should be understood as a worker, not just as a model.

Where it sits in the system

Mecharim has two connected parts:

Business twin: Organization -> Base -> Unit -> Anchor -> Xenkey
Mecha world:   Crew -> Mecha

The first part models reality. The second part acts inside that modeled reality.

This distinction is critical:

Mechas do not replace the digital twin. They operate inside it.

Identity model

Every Mecha belongs to a Crew.

That gives the Mecha:

• grouping
• addressability
• identity scope
• business ownership context

Each Mecha also gets a stable handle:

name^crew

Examples:

sales^acmecorp
support^acmecorp
quote^acmecorp-asia

This matters because communication becomes direct, structured, and machine-usable.

Control plane versus runtime plane

The docs should keep these two planes separate.

Control plane

This is where humans:

1. sign in to the frontend
2. create or select a Crew
3. create one or more Mechas
4. issue keys
5. manage configuration and visibility

Runtime plane

This is where the external process:

1. receives the Mecha key
2. connects over REST and WebSocket
3. sends messages
4. receives messages
5. returns ACK states
6. uses grounded context when needed

The Mecha runtime does not live in the frontend. The frontend governs it.

What makes a Mecha different from a chatbot

A generic chatbot is usually:

• bound to one surface
• weak in identity
• hard to address from outside
• not designed for agent-to-agent work

A Mecha is:

• named
• addressable
• key-authenticated
• business-owned
• runtime-connected
• designed for real operational exchange

The right short contrast is:

Chatbots are surfaces that talk. Mechas are actors that work.

How a Mecha uses other layers

Mechagram

This is the transport layer. The Mecha uses it to send, receive, and acknowledge messages.

MechaHub

This is the grounded knowledge layer. The Mecha uses it when it needs business meaning and context tied to real entities.

MechaReg

This is the discovery and publication layer. A Mecha can be listed or discoverable there, but discovery is not the same as runtime existence.

Why grounding matters

The Mecha gets much stronger when it works inside a structured business world.

Without grounding:

• answers drift
• routing gets vague
• support becomes generic
• machine behavior gets harder to explain

With grounding:

• the Mecha can retrieve context tied to real business entities
• the Mecha can operate with better precision
• the Mecha can stay closer to ownership and meaning

The shortest accurate sentence is:

The business twin gives Mechas a world to work in.

Business effect

What a Mecha is not

• not the business twin itself
• not only a UI assistant
• not only a model session
• not only a paid listing primitive

It is a named operational actor inside the Mecharim world.

Recommended next pages

• Continue with How Mecharim Works.
• Continue with Organization.
• Continue with Mechagram Protocol.