Skip to content

PATTERN Cited by 1 source

Tool-decoupled agent framework

Define agent tools as ordinary code functions + signatures + a short docstring, and let the LLM infer input format, output shape, and interpretation from the signature. Prompts and tools are independently swappable — the framework owns LLM connection, parsing, and conversation state, while engineers evolve each axis without rewriting the other.

Intent

Collapse the two common iteration bottlenecks in agent development:

  • Prompt changes force tool-code changes (tool's input/output format encoded in prompt) → every prompt tune is a refactor.
  • Tool changes force prompt changes (prompt hardcodes tool docs) → every tool addition requires a prompt rewrite.

By treating the function signature + docstring as the contract, both axes iterate independently.

Mechanism

  1. Tool = normal function. Language-native types, a short docstring describing what it does and when to use it.
  2. Framework reads the signature + docstring and presents the tool to the LLM. The LLM infers how to format inputs and interpret outputs.
  3. Prompts are separate declarative artifacts. Swapping a prompt doesn't touch tool code; adding a tool doesn't require editing prompt strings.
  4. Infrastructure (LLM client, parser, conversation state, retries, logging) lives in the framework — written once, amortized across all tools.
  5. Evaluation — the framework plugs into a judge-LLM / snapshot-replay harness (see patterns/snapshot-replay-agent-evaluation) so both prompt and tool changes are regression-tested automatically.

Why it matters

  • Fast iteration. Tuning prompts or swapping tools is a small local change with measurable impact, not a plumbing rewrite.
  • Low per-tool cost. Adding a tool = writing a function + docstring. No bespoke parser or LLM-glue code.
  • Enables specialization. With cheap tool onboarding, it's tractable to spin up per-domain agents (DB, traffic, storage, network) that collaborate — see patterns/specialized-agent-decomposition.
  • Non-expert contribution. Domain engineers contribute tools without needing LLM expertise; framework authors tune prompts without needing deep domain knowledge.

Tradeoffs

  • Docstring quality becomes load-bearing. A bad docstring degrades the agent silently — the LLM picks the wrong tool or mis-formats inputs.
  • Implicit contract. Because the I/O schema is inferred, debugging "why did the agent call this tool wrongly?" can require prompt-level inspection.
  • Framework coupling. Once you've standardized on one framework, switching (e.g., DsPy → LangChain) requires re-authoring the contract surface.

Seen in

  • sources/2025-12-03-databricks-ai-agent-debug-databases — Databricks' Storex framework is explicitly "DsPy-inspired": Scala classes + function signatures + short docstrings. The framework decouples prompt iteration from tool implementation and owns parsing, LLM connections, and conversation state. This decoupling is called out as the key iteration enabler that lets the team spin up specialized agents per domain.
Last updated · 200 distilled / 1,178 read