When building an agent, we provide it with tools so that it can delegate work rather than solve everything on its own. For a well-defined operation, the tool can simply be a script-based function or an API. However, once the task becomes more open-ended, capturing the problem-solving logic in a predefined script becomes challenging. This raises a compelling question:
Can another agent become the tool?
The answer is yes, and this is the so-called "agent-as-a-tool" pattern. In this post, we’ll explore this pattern using the OpenAI Agents SDK, illustrated with a practical case study.
1. The Agent-as-a-Tool Pattern
As the name suggests, in this pattern, agents are treated as tools invoked by a manager agent. The manager agent oversees the overall task, while other agents act as specialists. When the manager requires assistance with a specific portion of the problem, it delegates that work to the relevant specialist agent.
The specialist agent solves the delegated task using its own instructions and tools. Once complete, the results are returned to the manager, who may continue coordinating other tasks or produce the final response. This is a concrete example of a multi-agent system.
This pattern is particularly useful when the boundary of a delegated task is clear, but the steps required to accomplish it are not. It provides a clear division of responsibility, allowing different specialists to be configured independently without burdening the manager agent with every implementation detail.
Now, let’s implement this pattern using the OpenAI Agents SDK.
2. Case Study: Planning a Long Layover
In this case study, we build an agentic system that helps travelers plan activities during a long layover—an increasingly common scenario in 2026, when long-haul flights often include extended stopovers. Imagine a family with a 10-hour layover in Munich, Germany. They want to leave the airport, do some sightseeing, and enjoy a good meal without risking their connecting flight.
To create a practical itinerary, the agent must answer several questions, such as:
- Is there enough time to leave the airport at all?
- What activities and dining options suit the travelers?
- What risks should the plan account for?
We can equip the agent with three purpose-built tools to help answer these questions. Here’s the agent configuration we want:
# pip install openai-agents
from agents import Agent, ModelSettings, OpenAIResponsesModel
from openai import AsyncAzureOpenAI
client = AsyncAzureOpenAI(
api_key=os.environ["OPENAI_API_KEY"],
azure_endpoint=os.environ["OPENAI_API_BASE"],
api_version=os.environ["OPENAI_API_VERSION"],
)
travel_planner_agent = Agent(
name="Travel planner",
instructions=(
"Create a travel plan for the user "
"using the available tools."
),
model=OpenAIResponsesModel(
model="gpt-5.4", # Assuming a 2026 model version
openai_client=client,
),
model_settings=ModelSettings(
reasoning={"effort": "medium"},
),
tools=[
logistics_tool,
local_experience_tool,
risk_tool,
],
output_type=LayoverPlan,
)The three tools serve distinct purposes:
logistics_tool: Checks whether the trip is feasible based on transportation and timing.local_experience_tool: Finds activities and food options suited to the travelers' preferences.risk_tool: Identifies potential risks and suggests ways to make the plan more robust.
The travel planner agent can call these tools and synthesize the responses into a final itinerary.
But here’s the optimal approach: instead of implementing these tools as traditional functions, we can implement them as sub-agents. Each tool becomes an agent with its own domain knowledge and specialized instructions. The manager agent then invokes these sub-agents as tools, following the agent-as-a-tool pattern. This approach is more powerful because each sub-agent can handle open-ended queries, adapt to surprises, and provide richer, more context-aware answers than a static script could.
3. Implementing Sub-Agents as Tools
In the OpenAI Agents SDK, converting a sub-agent into a tool is straightforward. You create an Agent for each specialist, then pass it to the manager agent's tools list. The SDK automatically wraps the agent as a tool, with the agent's description serving as the tool's documentation.
For example, our three tools could become:
LogisticsAgent()– An agent that evaluates the feasibility of leaving the airport based on current flight schedules, visa requirements, and transportation times.LocalExperienceAgent()– An agent that suggests sightseeing and dining options personalized to the travelers' interests and time constraints.RiskAgent()– An agent that analyzes potential pitfalls (e.g., traffic, security lines, weather) and recommends mitigation strategies.
Each sub-agent can be configured with its own model settings, tools, and output types, allowing for deep specialization.
from agents import Agent
logistics_agent = Agent(
name="Logistics Specialist",
instructions="Determine if a layover allows leaving the airport and returning in time. Use real-time data.",
tools=[transport_api, flight_status_api],
)
local_experience_agent = Agent(
name="Local Experience Specialist",
instructions="Recommend activities and restaurants near the airport, considering user preferences and available time.",
tools=[attractions_db, restaurant_finder],
)
risk_agent = Agent(
name="Risk Management Specialist",
instructions="Identify potential risks that could disrupt the layover plan and suggest contingency measures.",
tools=[weather_api, traffic_api],
)
# Manager agent with sub-agents as tools
travel_planner_agent = Agent(
name="Travel Planner",
instructions="Create a safe and enjoyable layover plan using the specialist tools.",
tools=[logistics_agent, local_experience_agent, risk_agent],
output_type=LayoverPlan,
)One critical nuance: when an agent is used as a tool, the SDK treats its generated output as the tool result. This means each sub-agent must be designed to return concise, structured responses that the manager can easily parse. We can enforce this by setting output_type for each sub-agent to a Pydantic model.
4. Why Does This Matter?
The agent-as-a-tool pattern offers key benefits:
- Modularity: Each specialist agent focuses on a narrow domain, making the system easier to maintain and extend.
- Adaptability: Sub-agents can use their own tools and reasoning to handle unpredictable inputs, unlike fixed scripts.
- Scalability: New capabilities can be added by simply creating new agent-tools, without modifying the manager logic.
- Clarity: The division of responsibility makes the overall system behavior more transparent and debuggable.
In 2026, as LLM agents tackle increasingly complex real-world tasks, patterns like agent-as-a-tool are becoming essential for building robust, production-grade systems. They allow developers to compose specialized capabilities without sacrificing control or performance.
5. Conclusion
We’ve seen how the agent-as-a-tool pattern leverages the power of sub-agents to create flexible, multi-agent systems. By treating agents as callable tools, we separate concerns, enhance adaptability, and enable more sophisticated problem-solving than traditional function-based tools allow.
With the OpenAI Agents SDK, implementing this pattern is both intuitive and powerful. Whether you’re building travel planners, customer support systems, or data analysis pipelines, consider whether your next tool should be a standard function—or an agent itself.