Axiom // Embodiment Bridge

AXIOM lets one AI identity move between robot bodies while preserving memory, capabilities, safety limits, and human oversight. The body becomes an interface—not the identity.

Comment

Inspiration

What it does## Inspiration

I have wanted a robot friend since I was six years old.

As robots and AI became real engineering platforms instead of science fiction, I kept returning to one question: why should an AI companion be permanently trapped inside a single body? A damaged robot, depleted battery, or better piece of hardware should not require starting over with a new identity.

AXIOM began with a different model: the AI is the portable identity, while each compatible robot is peripheral hardware. Its memories, permissions, objectives, and relationship with the user remain consistent even as its physical capabilities change.

What it does

AXIOM // Embodiment Bridge is a safety-controlled layer between an AI agent and compatible robot bodies.

The agent receives a normalized description of the selected body and proposes actions using semantic capabilities such as walk_to, pick_up, and inspect. It never controls motors, joints, or torque directly.

Every proposed action passes through an independent deterministic safety kernel that can:

  • Approve the action
  • Modify it into a safer action
  • Reject it
  • Require explicit human approval

The simulation demonstrates AXIOM safely rerouting around structural walls, blocking restricted zones, requesting approval for destructive computer use, responding to an emergency stop, and transferring from an office-oriented body to a field-oriented body without losing its identity or task context.

Every proposal, safety decision, approval, adapter command, execution result, and embodiment switch is recorded in an audit timeline.

How I built it

I built AXIOM as a typed Next.js application using React, TypeScript, React Three Fiber, Zustand, Zod, Vitest, and Playwright.

The system is divided into deliberately replaceable boundaries:

  • An AgentProvider creates schema-constrained plans
  • A deterministic safety kernel authorizes each action
  • A task orchestrator manages execution, retries, cancellation, and approval
  • A RobotAdapter translates approved semantic actions for the selected body
  • A normalized state layer returns results without exposing manufacturer-specific controls to the agent

GPT-5.6 is integrated behind the server-side provider boundary. For reliable judging, the application defaults to a deterministic demonstration provider that exercises the same validation, safety, approval, audit, and adapter pipeline without requiring an API key.

I used Codex as the engineering workspace throughout the project. Codex helped translate the original product concept into a typed architecture, implement the simulator and console, investigate race conditions, strengthen the adapter and retry boundaries, build the animated doorway behavior, run the test suite, and generate the final narrated demonstration video in code.

The central product and safety decisions remained human-led: identity belongs above the hardware boundary, models propose rather than authorize, physical capabilities must be explicitly advertised, and safety interventions should always be visible to the operator.

Challenges

The hardest challenge was making safety an actual architectural boundary instead of a label placed over agent behavior.

Navigation exposed this immediately. A user can request a direct route that crosses a wall, so AXIOM must preserve the objective while replacing the unsafe path with an approved doorway route. The visualization also needed the door to visibly open; otherwise, the top-down view made a safe route look like the robot was simply walking through a wall.

Async execution introduced another class of problems. Cancellation and emergency-stop events had to invalidate stale planning or adapter responses so delayed work could never restart a stopped task. Retry counts also needed to represent real adapter failures and terminate safely after a bounded number of attempts.

Finally, I wanted the project to be honest about its scope. This MVP controls simulated bodies only. It demonstrates the software boundaries required for hardware integration without claiming a commercial robot connection or treating a software emergency stop as a certified physical safety system.

What I learned

I learned that portable AI identity is not simply a matter of copying memory between devices. It requires stable capability contracts, normalized state, explicit permissions, trustworthy audit history, and careful separation between reasoning and physical authority.

I also learned that safety explanations are part of the user experience. When the system modifies or rejects an action, showing exactly what happened builds far more trust than silently changing the agent’s behavior.

Most importantly, changing bodies should not mean changing who the agent is. The embodiment can change while the identity and its relationship with the user remain continuous.

What’s next

The next step is integrating AXIOM with an official manufacturer simulator, followed by tightly controlled bench testing with a minimal capability set.

Physical deployment would require independent hardware emergency stops, manufacturer-native collision avoidance, authenticated adapters, signed and expiring action envelopes, durable audit storage, watchdogs, role-based approval, formal hazard analysis, and regulatory review.

AXIOM should never replace a robot manufacturer’s motor control, balance system, torque limits, or physical safety mechanisms. Its role is to provide a portable, auditable identity and intent layer above them.

Your AI is portable. The robot is peripheral hardware.

How we built it

Challenges we ran into

Accomplishments that we're proud of

What we learned

What's next for Axiom // Embodiment Bridge

Built With

Share this project:

Updates