Feature: Agents-as-Tools — expose child agents as callable tools with parallel execution

Summary

Thank you for this excellent and brilliant project — it's been a pleasure to use in practice. I’ve been working on extending it with an “Agents as Tools” pattern (inspired by the OpenAI Agents SDK), where child agents are exposed as callable tools. This allows the parent LLM to invoke any number of children in arbitrary order and parallel, using the LLM’s own tool loop.

Docs reference: https://openai.github.io/openai-agents-python/tools

A PR is in progress to contribute this capability with minimal surface area and full backward compatibility.

Background & Motivation

In a recent enterprise use case, I led the design of a recursive agent/prompt framework for a corporate client. We built an AI project manager capable of generating status reports and forecasts across 20+ projects in parallel. Agent-as-tool was the key metaphor: flexible, composable, and scalable.

During deep research into agent orchestration architectures — specifically for our modular multi-agent call repositories — GPT-5 consistently recommended fast-agent as the top choice. It was the best match in terms of design philosophy, extensibility, and runtime ergonomics.

I initially attempted to implement our workflow using the built-in OrchestratorAgent, but it introduced excessive latency and token overhead. In our case, we already had a structured JSON array of tasks, with each item clearly corresponding to a child agent. The orchestrator's internal planning loop was redundant and inefficient in this setup.

This proposal enables direct fan-out via agent tools — lean, intuitive, and parallel — preserving the excellent agent core while eliminating orchestration overhead where it's unnecessary.

Feature Proposal

• 🧩 New agent: AgentsAsToolsAgent (subclass of ToolAgent)

  • list_tools() exposes each child as a tool with a namespaced name (agent__{child}).
  • call_tool() routes to the child agent's .generate() and packages the result as CallToolResult.
  • run_tools() uses asyncio.gather to run multiple tools in parallel.

• 🏗️ Factory changes:

  • In direct_factory, if a BASIC agent has child_agents, it becomes an AgentsAsToolsAgent; otherwise defaults to McpAgent.

• ✅ Dependency graph:

  • Ensures child agents are constructed before their parent.

Behavior

• The parent LLM can choose and call child agents as tools in any order.
• Multiple calls per turn are supported — with actual parallel execution.
• Console + UI blocks preserve child messages and error feedback.
• Tools are fully namespaced to avoid conflict with MCP-level tools.

Open Questions

• Should both MCP tools and agent-tools be returned from list_tools() by default?
• Do we want more structured tool input schemas, or keep the permissive { text?, json?, ... } interface?
• Should child agents themselves support recursive agent-tools?

Thanks

Thanks again for making such a brilliant and extensible library. I’m excited to contribute this feature and welcome any feedback. The implementation is modular, opt-in only, and fully backward-compatible.