Skip to main content
An agent is not the robot. The physical system stays what it always is in DimOS: modules exchanging streams, composed by a blueprint. An agent is one more module in that blueprint - an LLM loop that listens for human text, picks tools, and calls them. The tools are ordinary module methods marked with @skill. β€œAgent native” means robot capabilities are toolized for an LLM, not that the whole OS is an agent. Skills are the product surface; the agent is one client of them. You are another: every skill can be called from the CLI with no LLM involved.

The control loop

The agent does not continuously subscribe to camera, LiDAR, or odometry streams. Perception reaches the LLM pull-based, through skills: when the agent wants to see, it calls a skill like observe() and gets an image back as a tool result. This keeps the LLM loop cheap and makes every observation explicit in the conversation history. McpClient (dimos/agents/mcp/mcp_client.py) is a Module with exactly three streams:
  • human_input: In[str] - text from dimos agent-send, the web chat, or humancli
  • agent: Out[BaseMessage] - the agent’s responses (text, tool calls, images)
  • agent_idle: Out[bool] - signals when the agent is waiting for input
At startup it connects to McpServer, lists the available tools, and exposes them to the LLM. McpServer in turn discovers every @skill-annotated method across all deployed modules via RPC.

Vocabulary

A real agentic stack

dimos run unitree-go2-agentic composes (from dimos/robot/unitree/go2/blueprints/agentic/):
The system prompt gives the Go2 agent its persona (β€œDaneel”, dimos/agents/system_prompt.py) and, more importantly, policy matched to the skills that actually exist on this robot. A G1 stack ships a different prompt because it ships different skills.

Talking to the agent

Models

Where to go next