feat (agents): custom harness CLI

Problem

DimOS has no first-class CLI / harness for interacting with a running robot. The existing tooling routes everything through MCP clients / servers, which adds unnecessary overhead for native dimos skills.

Solution

Build out a CLI-native custom harness (similar to OpenClaw, Claude Code) for DimOS. This harness would own the reasoning loop, context management, and tool calling -- directly over RPC instead of the existing MCP client/server architecture. This will enable developers to interact with their robots in a steerable, interruptible, and controllable way.

Entry point

Expose a new chat command (e.g. dimos chat) in the existing dimos/robot/cli/dimos.py controller. On startup, the harness starts a session by connecting to the running blueprint via Dimos.connect() (errors if not found) and discovering all available skills via SkillsProxy. The new session should have fresh context and a unique session id.

Features

Context management
The harness will enforce a token-aware sliding window (trimmed oldest-first) when the context limit is approached. Agent memory (episodic memory) could be used for longer-term context.

Native skill dispatch
All skills are discovered through SkillsProxy and dispatched over RPC instead of MCP.

Parallel skill dispatch
The harness will have the capability to dispatch multiple concurrent tool calls (dependent on skill lanes or careful system instructions)

Session management
Each session starts with fresh context; unique session ids allow for resuming later (similar to claude).

Streaming
Agent responses are streamed back to the terminal to assist with perceived latency.

Observability
Stream back progress indicators, thought chunks, and tool call invocations so the developer has insight into the agent's execution and planning.

Main reasoning loop

The CLI will expose a standard readline prompt. On each submission, the harness runs a simple, interruptible ReAct loop:

_stop = False

while _stop == False:
     1. add user message to chat history
     2. trim conversation history if context threshold is hit
     3. call LLM with context, system prompt, available tools
     4. if the LLM does not call any tools, return message (stream to terminal), wait for next input
     5. if the LLM does call tool(s), dispatch via SkillsProxy, collect results, update history, continue loop (step 2)

If the user executes ctrl c, we would short circuit by setting _stop = True

Note - this stop mechanism is only agent-level; see Open Questions for more on robot-level control.

Available Commands (WIP)

• /reload-tools - if a blueprint is updated mid session, the tool cache will be invalidated
• /tools - print all available skills with signatures and descriptions
• /clear - reset conversation history, fresh context
• /help - list all available commands
• /exit - quit the session

Open questions

1. Do we have a standard "kill switch" mechanism for the robot's runtime? If so, we can expose a /kill command to stop the robot as a safety measure.

Start with dimos/robot/cli/dimos.py and trace the existing CLI entry points, then read the Dimos.connect() and SkillsProxy APIs mentioned in the issue. Define the chat session around fresh context, skill discovery, streaming, interruption, and the listed commands; done means a running blueprint can be interacted with through the new CLI-native loop without MCP.