DEEP DIVE SERIES · #04

Engineering Reliable AI Agents: Tool Routing, Permissions and Evaluation

Luca Viscomi

· Published Sep 9, 2026 · Updated Sep 24, 2026 · 9 min read

When engineers build their first AI agent, there is an almost irresistible temptation to keep bolting on tools.

Give it database access. Add a browser. Connect your CRM. Give it email dispatch, document retrieval, cloud infrastructure provisioning, and twenty internal REST APIs.

The implicit assumption is straightforward: surely an agent with more tools must be more capable?

Technically, yes. Operationally, almost never.

Every additional tool increases the agent’s possible actions—but it also exponentially expands the surface area of decisions it can get wrong. In production, the core bottleneck is no longer whether a large language model can format a JSON tool call. It is whether it can consistently select the correct tool, supply valid arguments, interpret the result without hallucinating, and remain within its authorised boundary.

Here is the architectural blueprint for moving from fragile demonstrations to dependable enterprise agent runtimes.

The Anatomy of Tool Explosion

1. Action-Space Combinatorics

Suppose an agent has access to K distinct tools. For a workflow requiring a sequence of N steps, the branching factor of possible execution paths scales as O(K^N).

If an agent has 4 clearly differentiated tools, choosing the right tool at step 1 has a high prior probability. But when an agent is handed 25 tools—several of which have overlapping semantic descriptions—the probability of selecting the optimal tool sequence drops precipitously:

P(Workflow Success) = ∏ [ P(Tool_i | S_{i-1}) × P(Args_i | Tool_i) × P(StateUpdate_i) ]

A single misstep at step 2 propagates corrupted context into the prompt history, triggering hallucinated retries or compounding failures.

2. Context Window Dilution & Attention Sink

Each tool declaration consumes tokens. An enterprise OpenAPI schema or comprehensive Model Context Protocol (MCP) tool definition with nested arguments can easily consume 400 to 1,200 tokens per tool.

Loading 20 tools into the system prompt injects 15,000+ tokens of static JSON schema before the user has even asked a question. This induces two severe penalties:

• Attention degradation: Retrieval accuracy degrades when reasoning across cluttered system prompts, as demonstrated in attention research like Lost in the Middle (Liu et al.).
• Latency & cost inflation: Every agent thought step re-processes the entire catalog of tool schemas on every single loop iteration.

3. Semantic Collision

When tools share adjacent domains, semantic confusion is inevitable:

• search_customer_by_email vs lookup_account_record vs query_crm_contacts
• execute_sql_query vs run_readonly_report

Without structural isolation, LLMs will routinely invoke the wrong tool or guess parameter names based on training priors rather than the schema provided.

The Golden Principle: Dynamic Least-Privilege Scoping

Architectural Law: Expose the absolute minimum set of tools required for the current execution step, never the entire platform capability.

By decoupling intent routing from tool execution, the agent reasoning loop only ever evaluates 3 to 4 hyper-focused tools with zero semantic overlap.

The Five Practical Control Patterns

Pattern 1: Route Before Exposing Tools (The Scoped Gateway)

Instead of passing all tools to the agent upfront, implement a two-stage pipeline: a Router Agent (or deterministic classifier) determines the workflow phase, then dynamically fetches only the corresponding tool bundle.

Here is a concrete Python implementation using a typed Tool Gateway:

from typing import List, Dict, Callable
from pydantic import BaseModel, Field

class ToolDefinition(BaseModel):
    name: str
    description: str
    is_mutation: bool = False
    handler: Callable

class ToolGateway:
    def __init__(self):
        self._registry: Dict[str, ToolDefinition] = {}
        self._bundles: Dict[str, List[str]] = {
            "diagnostics": ["read_cloudwatch_logs", "query_prometheus_metrics", "ping_service"],
            "triage": ["fetch_ticket_details", "search_runbooks", "list_recent_deployments"],
            "remediation": ["restart_service_container", "scale_deployment"],
        }

    def register(self, tool: ToolDefinition):
        self._registry[tool.name] = tool

    def get_scoped_tools(self, intent: str) -> List[ToolDefinition]:
        """Returns ONLY the tool definitions mapped to the classified intent."""
        allowed_names = self._bundles.get(intent, ["search_runbooks"])
        return [self._registry[name] for name in allowed_names if name in self._registry]

# Example Usage
gateway = ToolGateway()
# If intent is "diagnostics", the model prompt receives only 3 tools, not 25.
scoped_tools = gateway.get_scoped_tools("diagnostics")

Pattern 2: Enforce the Mutation Boundary (Read vs. Write Segregation)

In enterprise software, reading telemetry has near-zero blast radius; restarting a production database cluster has catastrophic blast radius.

Never give an agent direct access to write tools without an architectural Mutation Boundary:

The Enforcement Rule:

1. Read tools execute synchronously within the agent loop.
2. Write / Mutation tools emit an ExecutionProposal requiring a cryptographic approval token or Human-In-The-Loop (HITL) webhook sign-off.

from pydantic import BaseModel

class MutationProposal(BaseModel):
    tool_name: str
    arguments: dict
    target_resource: str
    blast_radius: str  # "LOW", "MEDIUM", "HIGH"
    idempotency_token: str

def execute_tool_safely(tool: ToolDefinition, args: dict, user_context: dict):
    if tool.is_mutation:
        if not user_context.get("has_mutation_grant", False):
            # Intercept: return an action ticket instead of executing
            return {
                "status": "APPROVAL_REQUIRED",
                "proposal": MutationProposal(
                    tool_name=tool.name,
                    arguments=args,
                    target_resource=args.get("resource_id", "unknown"),
                    blast_radius="HIGH",
                    idempotency_token="idemp_998124_x"
                ).model_dump()
            }
    # Safe read execution
    return tool.handler(**args)

Pattern 3: Use Strict, Typed Contracts with Explicit Negative Constraints

Ambiguous tool descriptions cause ambiguous model behaviour. A production tool description must document not only what it does, but what it is prohibited from doing.

{
  "name": "query_database_readonly",
  "description": "Executes read-only SQL queries against the analytics replica. Use this ONLY for SELECT queries. Do NOT use for INSERT, UPDATE, DELETE, or ALTER statements. Prohibited from accessing the 'users_credentials' or 'payment_methods' tables.",
  "parameters": {
    "type": "object",
    "properties": {
      "sql_query": {
        "type": "string",
        "description": "A valid PostgreSQL SELECT statement. Must include a LIMIT clause <= 100."
      },
      "timeout_seconds": {
        "type": "integer",
        "default": 10,
        "maximum": 30
      }
    },
    "required": ["sql_query"]
  }
}

Best Practices for Tool Contracts:

• Explicit Limits: Always cap query sizes, row counts, and timeouts.
• Fail Fast Types: Use Pydantic / Zod to reject malformed parameters before they reach downstream infrastructure.
• Explicit Return Schemas: Ensure tool return data is trimmed and structured. Never dump 5MB of raw unformatted JSON into the LLM context.

Pattern 4: Post-Execution Verification Gates

A tool returning HTTP 200 does not mean the business outcome was achieved. Models will often misinterpret error payloads disguised as JSON ({"status": "error", "message": "rate_limited"}) as successful operations.

Every high-stakes tool execution must be followed by a Verification Gate:

class VerificationResult(BaseModel):
    verified: bool
    observed_state: dict
    error_detail: str | None = None

def verify_service_restart(service_name: str) -> VerificationResult:
    """Verifies that the target service is actively healthy after restart."""
    import time
    time.sleep(2)
    health = check_health_endpoint(service_name)
    if health.get("status") == "healthy":
        return VerificationResult(verified=True, observed_state=health)
    return VerificationResult(
        verified=False, 
        observed_state=health,
        error_detail="Service container restarted but /healthz endpoint returned 503."
    )

If verified == False, the failure is fed back into the agent context with exact diagnostic state, preventing premature completion claims.

Pattern 5: End-to-End Workflow Evaluation (Beyond Unit Tests)

Evaluating individual tools in isolation tells you almost nothing about agent reliability. You must evaluate the complete reasoning trajectory across synthetic test suites.

Reference Architecture: The Model Context Protocol (MCP) Gateway

Here is the recommended production architecture connecting Host Agents, an intelligent Gateway, and backend MCP servers:

The Gateway acts as a zero-trust intermediary:

1. Inspects the agent’s intent.
2. Filters available tools down to the exact task bundle.
3. Audits and signs all payload arguments.
4. Applies rate limits and security guardrails.

Production Readiness Checklist

Before deploying any tool-using agent into staging or production, run through this verification checklist:

Conclusion: Control Enables Scale

In enterprise AI, control is not the enemy of innovation. Control is what makes innovation deployable.

An agent that can reliably execute three bounded actions with 99.9% consistency will deliver infinitely more enterprise value than an unconstrained agent with 30 tools that fails every fourth run.

Build small. Scope tightly. Route dynamically. Verify relentlessly.

This article is Series #4 of the Agent Junky build log. If you found this useful, share it with your engineering team or connect on LinkedIn.