When Your AI Agent Needs to Phone a Friend: Patterns for Tool Calling

You know what's funny about building AI agents? The hardest part isn't the AI. It's figuring out when to let them use tools.

I've been working on a client project where we're building an agent that manages infrastructure deployments. Simple enough, right? The agent needs to check server status, restart services, maybe trigger a build. Standard DevOps stuff.

But here's the thing — giving an AI unrestricted access to production infrastructure is... well, let's just say my client wasn't thrilled when I suggested it. And honestly? They were right.

The Problem Nobody Talks About

Most tutorials show you how to connect tools to your LLM. They don't show you how to prevent your agent from becoming a very expensive chaos machine.

I learned this one the hard way last year. We built an agent that could manage GitHub repositories — create issues, close PRs, comment on discussions. Standard stuff. We deployed it, and within an hour it had commented on 47 issues with variations of "I'll look into this" and then... did nothing. Because we hadn't taught it when NOT to use tools.

The client was understanding. Mostly. After we fixed it.

Pattern One: The Permission Model

Here's what actually works — treat tool access like you'd treat database permissions in a multi-tenant app.

Your agent shouldn't get a binary yes/no on tool access. It needs gradations. Can it READ from this API? Sure. Can it WRITE? Maybe. Can it DELETE? Better ask a human first.

I build this with three tiers:

• Green tier: Read-only, low-risk operations. Check status, list resources, fetch data.
• Yellow tier: Writes that are reversible. Create a draft, update metadata, add a comment.
• Red tier: Destructive operations. Deploy to production, delete resources, send emails to customers.

Green tier? The agent can use these freely. Yellow tier? It needs to explain why first (I actually make it justify the call in its reasoning). Red tier? Always requires human approval.

Pattern Two: The Dry-Run Dance

Something about this approach clicked when I tried it on that infrastructure project...

Before any write operation, we make the agent run a dry-run first. It calls the tool with a flag that says "show me what you WOULD do, but don't actually do it." Then it presents the results to the user: "If I run this command, here's what will happen..."

You'd be surprised how often the agent catches its own mistakes at this stage.

And honestly, users love it. It feels collaborative instead of scary. The agent isn't just doing things TO your infrastructure — it's working WITH you.

Pattern Three: Tool Chains, Not Tool Calls

This pattern showed up on three different projects last month, so I know it's real.

Instead of giving your agent direct access to tools, give it access to tool chains — predefined sequences that include validation steps.

Example: Instead of a "deploy" tool that just... deploys, we created a "safe_deploy" chain:

1. Run tests
2. Check current production status
3. Verify no other deployments in progress
4. Create a backup
5. Deploy
6. Run smoke tests
7. Rollback if smoke tests fail

The agent calls one tool. But that tool enforces a safe workflow. It can't skip steps. It can't override the safety checks.

This saved us twice already. Once when the agent tried to deploy during another team's maintenance window. Once when it tried to deploy code that hadn't passed CI yet.

Pattern Four: The Audit Trail

Make everything loggable. Not just "the agent called this tool" — log WHY it called it.

We modified our tool-calling interface to require a reasoning parameter. The agent has to explain its logic before it can use the tool. This gets logged.

Why? Because when something goes wrong (and it will), you need to understand the agent's decision-making process. Was it following instructions correctly but with bad data? Was it misunderstanding the task? Did it hallucinate a reason to use the tool?

You can't debug what you can't see.

Here's what I keep telling my team — the reasoning log is more valuable than the action log. Actions tell you what happened. Reasoning tells you why. And "why" is what you need to fix the agent's behavior.

What Actually Matters

Tool calling isn't about connecting APIs to LLMs. That's the easy part. The hard part is building the guardrails, the safety nets, the "are you SURE?" moments.

Your agent should be powerful but not reckless. Capable but not autonomous in the scary sense.

I think the best agent systems feel less like automation and more like collaboration. The agent can do things... but it checks in. It explains. It asks permission when it should.

And yeah — sometimes that means sacrificing pure automation for safety. But after watching an agent try to delete a production database because it "thought it was a test environment"? I'm okay with that trade-off.

Where to Start

If you're building agents with tool access:

1. Start with read-only tools. Get comfortable with those first.
2. Add writes slowly, one at a time.
3. Log everything, especially the reasoning.
4. Build dry-run modes into your tools from day one.
5. Don't give destructive access without human approval. Just don't.

The goal isn't to make your agent fully autonomous. The goal is to make it a reliable collaborator.

Building AI agents that actually work in production? That's what we do at NerdSnipe. If you're wrestling with tool-calling patterns or just want to talk through your agent architecture, reach out.