Part 4/6: Tool Design and Inter-Agent Context Sharing: A Collection of Practical Patterns

Introduction: Recap of the Previous Part and the Purpose of This Article

In Part 3, we explained the division of roles between the orchestrator and sub-agents in Claude Team Agent, as well as the mechanisms for task delegation. In this article, we go one step further and introduce tool design patterns tailored to real-world business use cases, along with implementation techniques for sharing context and state between agents, complete with sample code.

---

1. Core Principles of Custom Tool Definition

In Anthropic's Claude Agent SDK, tools are defined using JSON Schema and are invoked autonomously by the agent. The quality of tool design determines the overall reliability of the agent. [Source: https://docs.anthropic.com/en/docs/agents-and-tools/tool-use/overview]

There are three principles common to good tool definitions.

• Single responsibility: Limit each tool to a single function and minimize side effects
• Idempotency: Design tools to return the same output for the same input, ensuring safety during retries
• Explicit schema: Describe usage conditions and prohibited conditions in natural language in the description field to prevent the model from making incorrect calls

tool_definition = {     "name": "search_internal_docs",     "description": "Performs a full-text search of the internal knowledge base. Do not use this for searching the external web.",     "input_schema": {         "type": "object",         "properties": {             "query": {"type": "string", "description": "Search query"},             "top_k": {"type": "integer", "default": 5}         },         "required": ["query"]     } } 

---

2. Reusable Tool Generation Pattern: Implementing a Data Analysis Agent

In the case study where NVIDIA's NeMo Agent Toolkit achieved first place on the DABStep benchmark, a "Reusable Tool Generation" architecture was adopted, in which agents dynamically generate Python code, register it as tools, and reuse it. [Source: https://huggingface.co/blog/nvidia/nemo-agent-toolkit-data-explorer-dabstep-1st-place]

When implementing this pattern with a Claude Agent, the following flow is effective.

1. The orchestrator receives a data analysis task
2. A code-generation sub-agent dynamically generates a Python function
3. The generated function is registered as a tool and called again in subsequent steps

generated_tools = {}  def register_dynamic_tool(name: str, func_code: str):     exec(func_code, generated_tools)     return name in generated_tools  # Example usage inside the agent loop if tool_name in generated_tools:     result = generated_tools[tool_name](**tool_input) 

This approach allows agents to autonomously expand their toolset without data scientists having to manually add tools.

---

3. Memory Sharing Between Agents: Three Implementation Patterns

One of the greatest challenges in multi-agent systems is the propagation of context between agents. By using the following three patterns according to the situation, you can select the optimal solution for each use case.

Pattern A: Shared External Storage (Persistent Memory)

This approach leverages external storage such as the Storage Buckets provided by Hugging Face Hub, allowing multiple agents to access a common key-value store. It is well-suited for long-term research tasks and research automation that spans multiple sessions. [Source: https://huggingface.co/blog/storage-buckets]

import json, boto3  def write_shared_context(bucket, key, data: dict):     s3 = boto3.client("s3")     s3.put_object(Bucket=bucket, Key=key, Body=json.dumps(data))  def read_shared_context(bucket, key) -> dict:     s3 = boto3.client("s3")     obj = s3.get_object(Bucket=bucket, Key=key)     return json.loads(obj["Body"].read()) 

Pattern B: Message Passing (Short-Term Context)

When the orchestrator delegates a task to a sub-agent, it injects a summary from the preceding agent into the system prompt. This is highly token-efficient and is suited for sequential processing pipelines such as code review.

Pattern C: Structured State Object

This involves defining an AgentState dataclass that all agents reference, and saving updates and snapshots at each step. It improves state visibility and debuggability, making it effective for complex branching workflows such as data analysis pipelines.

from dataclasses import dataclass, field from typing import Any  @dataclass class AgentState:     task_id: str     completed_steps: list[str] = field(default_factory=list)     artifacts: dict[str, Any] = field(default_factory=dict)     errors: list[str] = field(default_factory=list) 

---

4. Recommended Pattern Matrix by Business Use Case

Use Case	Tool Strategy	Memory Sharing Pattern
Research automation	Dynamic tool generation + web search	External storage (persistent)
Code review	Static toolset (AST analysis, linter)	Message passing
Data analysis	Reusable Tool Generation	Structured state object

For research automation, a proven pattern involves agents writing intermediate artifacts (summaries, citation lists) to external storage, which a separate agent then reads to continue deeper investigation. For code review, passing PR diffs and comment histories sequentially as messages allows for efficient use of the context window.

---

5. Pitfalls in State Management and How to Address Them

When multiple agents update the same state, race conditions can occur. The following countermeasures should be implemented.

• Optimistic locking: Verify a version number when updating state, and retry on conflict
• Event sourcing: Record change events rather than the state itself to ensure reproducibility
• Timeout settings: Set an upper limit on the wait time for sub-agent responses to prevent deadlocks

---

Summary and Preview of the Next Part

In this article, we systematically covered everything from the design principles of custom tool definitions, to three types of memory sharing patterns, to implementation guidelines by business use case. The reusable tool generation architecture significantly boosts the performance of data analysis agents, but it also requires simultaneously hardening state management.

In Part 5, we will take up one of the core themes of this series: "error handling and autonomous recovery." We plan to explain in detail, with implementation code, the mechanisms by which agents learn from failures and dynamically adjust their retry strategies.

---

Category: LLM | Tags: Claude Agent, マルチエージェント, ツール設計, 状態管理, LLM実装