Conversation
Greptile OverviewGreptile Summary
Confidence Score: 1/5
Important Files Changed
Sequence DiagramsequenceDiagram
participant CLI as dimos CLI
participant MC as ModuleCoordinator
participant Agent as agents3.Agent
participant Mod as Other Modules
participant RPC as RPC (LCM)
participant MCP as MCP Bridge (stdio<->tcp)
CLI->>MC: deploy(Agent, modules...)
CLI->>MC: start_all_modules()
MC->>Mod: start()
MC->>Agent: start()
MC->>Agent: on_system_modules([RPCClient...])
Agent->>RPC: get_skills3() (on each module)
RPC-->>Agent: list[Skill3Info]
Agent->>Agent: create_agent(tools from Skill3Info)
Note over MCP: MCP expects a TCP server from MCPModule
MCP->>RPC: connect(host:port)
MCP-->>MCP: forwards JSON-RPC over TCP
Agent->>Mod: tool call via RpcCall (remote_name/class_name)
Mod-->>Agent: RPC response (or None if nowait)
Agent-->>CLI: publish messages/idle state
|
| result = tuple(self._bound_rpc_calls[m] for m in methods) | ||
| return result[0] if len(result) == 1 else result | ||
|
|
||
| @rpc |
There was a problem hiding this comment.
Tool schema generation bug
get_skills3() calls tool(attr).args_schema.model_json_schema() and then json.dumps(...). langchain_core.tools.tool() returns a Tool-like wrapper, and args_schema is not guaranteed to exist (or to be a Pydantic model with model_json_schema()), which will raise at runtime when enumerating skills. This needs to use a stable schema source (e.g., require __skill3__ functions to have an explicit Pydantic args_schema, or use StructuredTool.from_function(...).args_schema and then serialize that model/schema).
dimos/agents/agent.py
Outdated
| def _get_tools_from_modules( | ||
| agent: Agent, modules: list[RPCClient], rpc: RPCSpec | ||
| ) -> list[StructuredTool]: | ||
| skills = [skill for module in modules for skill in (module.get_skills3() or [])] |
There was a problem hiding this comment.
RpcCall target mismatch
_skill_to_tool() constructs RpcCall(..., name=skill.func_name, remote_name=skill.class_name, ...). remote_name is the module’s actor/service name used by RPCClient (typically module.actor_class.__name__), not an arbitrary class_name string returned by get_skills3(). If Skill3Info.class_name is the underlying Python class name (or differs from the deployed actor name), tool calls will be routed to a non-existent RPC endpoint. This should carry and use the actual RPC service name for the module instance that exposed the skill (or build the tool directly from the corresponding RPCClient instance rather than from a detached Skill3Info).
Additional Comments (2)
This blueprint still wires in |
54da1a1 to
8b1d0cd
Compare
96f2d0a to
ccbf5ad
Compare
Problem
We need a simpler base for agents so we can build long running tasks.
Closes DIM-447 ( https://linear.app/dimensional/issue/DIM-447/refactor-agents )
Solution
llm_init.py. The Agent is now a plain Module with a threaded message loop instead of an async coroutine-based one@skilldecorator"gpt-4o"or"ollama:qwen3:8b"or"huggingface:Qwen/Qwen2.5-1.5B-Instruct"llm_agent(), human_input()replaced with justagent(). Added demo-agent and demo-agent-camera blueprintsBreaking Changes
Quite a few breaking changes.
@skillnow does not support any arguments. All skills marked with it must return in a short time. They must return a string or an Image like before. If they want to return multiple things, they can return None and then useself.agent_spec.add_message(HumanMessage(...))to add a new message at any time.How to Test
...and prompt it anything like before.