TECHNIQUE
Tool Use & Structured Output
Observed operators wrap proprietary systems, indexes, plugins, files, and graph services as callable tools inside LLM workflows rather than relying on standalone chat completions.
Expose non-LLM systems as callable tools, plugins, or APIs for an LLM or agent to use at runtime.
4 of 4 operators with teardown evidence show this practice.Wrap retrieval, graph, or knowledge-store access behind tool calls so the model can fetch grounded context or structured identifiers before search or answer generation.
3 of 4 operators with teardown evidence show tool/API wrapping around retrieval, graph, or knowledge access.Package tool calling inside higher-level orchestration frameworks rather than leaving the model to decide everything in one prompt.
3 of 4 operators with teardown evidence show tool use embedded in orchestration frameworks, workflows, or sub-agent routing.Maintain tool catalogs or reusable tool layers so multiple apps or workflows can share integrations.
2 of 4 operators with teardown evidence show reusable tool catalogs or tool layers.Use tools for actions and code execution, not only information retrieval.
2 of 4 operators with teardown evidence show callable tools that execute code, schedule actions, write files, or run coding agents.Adopt MCP or discuss MCP alongside tool-calling infrastructure.
2 of 4 operators with teardown evidence explicitly mention MCP in connection with tool calling or agent/client interaction.Every operator with direct teardown evidence exposes at least one proprietary or operational capability to the LLM through a tool, plugin, API, or tool-calling pattern.
Operators differ in what they wrap as callable tools.
APPROACH 01
Search, index, and graph services are wrapped so the model can retrieve context or structured IDs.
APPROACH 02
Business-system and external-API integrations are exposed as plugins or native/community tools.
APPROACH 03
Developer-workflow tools expose file reading, file writing, and coding-agent capabilities.
Operators differ in how tool calls are orchestrated.
APPROACH 01
Agentic execution with sub-agents, ReAct agents, graph executors, or structured workflow orchestration.
APPROACH 02
A query engine uses tool calling to classify intent, fetch external data, and construct search filters or embeddings.
Unconstrained agents can be unreliable in large codebases; Shopify reported that letting AI “roam free around millions of lines of code” did not work well and that non-determinism hurt reliability.
Advanced LLM use behind tool-calling systems can raise serving cost and infrastructure requirements; LinkedIn reported increased compute requirements and investment in GPU infrastructure, KV caching, and fused kernels.
Tool-wrapped retrieval still depends on content understanding quality; Dropbox reported that complex images need true multimodal understanding and audio clips need transcription before they are useful to the system.
| Name | Kind | When | Maturity |
|---|---|---|---|
| Provider-native function calling | service | tools defined as JSON schemas; the provider handles selection and arguments | commodity |
| Zod/Pydantic-derived tool schemas | library | tool definitions should come from the same types the code already uses | commodity |