Beyond Chatbots: The Tooling Layer for Agents

For most of 2023 and 2024, the interesting question in AI was "which model?". In 2026, the interesting question is "which tools?". A frontier model without good tools is a very well-read intern with no laptop. A mid-tier model with excellent tools quietly runs whole departments.

This is the tooling layer, and it is where a huge share of the real engineering work in AI now sits.

What "tools" actually means

In agent terms, a tool is any function the model can call: send an email, query a database, book a meeting, run a search, generate an image, execute code. The model decides when to call each tool and with what arguments. The tooling layer is everything you build to make that decision reliable.

That layer includes:

• Clear, well-typed function signatures.
• Concise descriptions that tell the model when not to use a tool.
• Return values shaped for downstream reasoning.
• Rate limits, retries, error surfaces the model can actually understand.
• Permission checks so a tool refuses to run for the wrong caller.

Why this matters more than the model choice

Swapping a Gemini model for a GPT model might change your quality by 5–15%. Rewriting your tools from "roughly works" to "designed for agents" routinely doubles task success rates on the same model. In blind evaluations across our client projects, tool quality has been the single biggest variable in the last year.

Design principles that work in production

A few things we have found repeatedly true:

1. Fewer, sharper tools beat many overlapping ones. If two tools could plausibly do the job, the model will flip a coin.
2. Descriptions should say when NOT to call. "Use only for invoices in GBP" saves you a hundred wrong calls.
3. Errors should coach the model. A 400 with the message "missing customer_id — did you mean to call get_customer first?" is worth ten silent failures.
4. Return the smallest useful payload. Large responses fill the model's context and degrade every subsequent decision.
5. Make dangerous tools two-step. A preview_send_invoice followed by a confirm_send_invoice is safer than a single send_invoice, and models handle it well.

Standards are finally arriving

Until recently, every framework had its own tool format. In 2026, protocols like MCP (Model Context Protocol) are quietly standardising how tools are described and served, which means the tools you build today have a real chance of being portable across models and frameworks tomorrow. That is a big deal — it means investment in your tooling layer compounds, rather than being rewritten every 18 months.

Where teams underinvest

Most teams spend 80% of their AI budget on model calls and 20% on tooling. The teams whose agents actually work in production spend closer to 50/50, and often shift further toward tooling over time. This is counter-intuitive if you have been paying attention to model release cycles — but the leverage is real.

FAQ

What is the difference between function calling and agent tooling?

Function calling is the mechanism a model uses to invoke a tool. Agent tooling is the entire design discipline around what tools you expose, how you describe them, how they fail, and how they combine. Function calling is the plumbing; tooling is the architecture.

Should I build my own tools or use off-the-shelf ones?

Both. Use off-the-shelf tools for generic tasks (web search, code execution, document parsing). Build your own for anything specific to your business — your CRM, your billing system, your internal knowledge base. That is where the moat lives.

Does the choice of model matter at all?

It does, but less than most teams think. Once your tooling is well-designed, a mid-tier model on good tools usually beats a top-tier model on poor tools. Choose the model for cost, latency and reasoning depth — then invest heavily in the tools.

The next few years of AI progress will be uneven. Model gains will slow; tooling gains will accelerate. The teams that treat their tool layer as a first-class engineering discipline — versioned, tested, documented, measured — will look, in retrospect, like the ones who took DevOps seriously in 2015.