Problem Statement
Right now, Multi-Agent Rooms act as highly effective deterministic "think tanks" where agents exchange text based on live context and persona prompts. While this is excellent for simulation, planning, and debate, the agents are entirely disconnected from the outside world. They cannot execute code, fetch live data, search the web, or perform physical actions.
To evolve Rooms into an active "Control Room" OS for operational workflows, agents require the native ability to reach out and utilize external tools during a live session.
Proposed Solution
Integrate the arpahls/skillware toolkit natively into the core session flow. By simply requiring pip install skillware, users should be able to equip AgentConfig objects with explicitly imported, job-specific skills.
Core requirements:
- Job-Based Skill Assignment: Each agent receives a unique sandbox of tools tailored to their persona. For example, a "Researcher" agent gets
web-search, while a "Data Analyst" gets a python-REPL execution environment, preventing overlapping capabilities or unauthorized tool calls.
- Tool Appointment & Execution Monitoring: The Session layer dynamically coordinates when an agent requests a tool, securely executes the specific
skillware logic, monitors the execution for hanging processes, and manages the callback.
- Robust Result Formatting:
skillware outputs must be parsed, cleaned, and seamlessly injected back into the visible session history. It needs to look good in the CLI and transcripts—indicating both the tool intent and the raw execution result (e.g., [EXEC] Querying server... -> [RESULT] 4 rows returned) before the agent synthesizes their final spoken response.
Alternatives Considered
- Relying entirely on passing raw JSON schemas to
litellm's native function calling on a per-user basis. However, this lacks the standardized, pre-packaged Python logic that skillware provides out of the box and forces users to write immense boilerplate.
- Forcing users to rely solely on the current "Custom Model Integrations" (
Bring Your Own Code) feature. While possible now, it forces users to write all tool-hooking manually rather than enabling it via a single configuration block.
Priority
High 🔴
Additional Context
This is a massive paradigm shift in architecture and shouldn't be executed in one monolithic PR.
Proposed practical execution phases:
- Phase 1: Update config.py to allow AgentConfig to accept a
skills: List[str] parameter.
- Phase 2: Connect
litellm generic tool calling mechanisms directly to actual skillware invocation during agent.generate_response() if skills are present.
- Phase 3: Overhaul the CLI wizard and session.py to gracefully render these async tool usage loops inside the terminal without cluttering the primary human conversation.
Problem Statement
Right now, Multi-Agent Rooms act as highly effective deterministic "think tanks" where agents exchange text based on live context and persona prompts. While this is excellent for simulation, planning, and debate, the agents are entirely disconnected from the outside world. They cannot execute code, fetch live data, search the web, or perform physical actions.
To evolve Rooms into an active "Control Room" OS for operational workflows, agents require the native ability to reach out and utilize external tools during a live session.
Proposed Solution
Integrate the arpahls/skillware toolkit natively into the core session flow. By simply requiring
pip install skillware, users should be able to equip AgentConfig objects with explicitly imported, job-specific skills.Core requirements:
web-search, while a "Data Analyst" gets apython-REPLexecution environment, preventing overlapping capabilities or unauthorized tool calls.skillwarelogic, monitors the execution for hanging processes, and manages the callback.skillwareoutputs must be parsed, cleaned, and seamlessly injected back into the visible session history. It needs to look good in the CLI and transcripts—indicating both the tool intent and the raw execution result (e.g.,[EXEC] Querying server... -> [RESULT] 4 rows returned) before the agent synthesizes their final spoken response.Alternatives Considered
litellm's native function calling on a per-user basis. However, this lacks the standardized, pre-packaged Python logic thatskillwareprovides out of the box and forces users to write immense boilerplate.Bring Your Own Code) feature. While possible now, it forces users to write all tool-hooking manually rather than enabling it via a single configuration block.Priority
High 🔴
Additional Context
This is a massive paradigm shift in architecture and shouldn't be executed in one monolithic PR.
Proposed practical execution phases:
skills: List[str]parameter.litellmgeneric tool calling mechanisms directly to actualskillwareinvocation duringagent.generate_response()if skills are present.