AZMX AI

Engineering · 2026-05-28 · 8 min read

Mastering AI Agent Tool Use Patterns

Moving beyond simple chat to reliable, tool-augmented agents that interact with local filesystems and remote APIs.

The transition from LLM chat to agentic action depends entirely on how a model handles tool use patterns. Whether using a ReAct loop or a directed acyclic graph, the primary failure point is rarely the model's reasoning, but the lack of strict boundaries and observability in the tool execution layer.

The Evolution of Tool Use Patterns

Most AI agents follow a variation of the ReAct (Reason + Act) pattern. The model generates a thought, selects a tool, observes the output, and repeats until the goal is met. While effective for simple tasks, production-grade agentic workflows now demand more sophisticated patterns to avoid infinite loops and catastrophic failures.

1. The Loop-and-Observe Pattern

This is the baseline for tools like Aider or Cline. The agent proposes a shell command or a file edit, the system executes it, and the stdout/stderr is fed back into the context window. The critical failure mode here is the 'hallucination loop,' where an agent repeatedly attempts the same failing command because it ignores the error message.

2. The Approval-Gated Execution Pattern

Autonomous tool use is dangerous without a human-in-the-loop (HITL). The approval-gated pattern intercepts the tool call before execution. This is a non-negotiable requirement for any agent with rm -rf or git push capabilities. By forcing a manual confirmation for every shell operation, the risk of accidental data loss is mitigated.

3. The Specialized Sub-Agent Pattern

Rather than one monolithic agent attempting to manage a whole project, the sub-agent pattern delegates specific toolsets to specialized instances. For example, one sub-agent may only have access to grep and find for discovery, while another has write access to the editor. This limits the blast radius of any single model error.

Standardizing Tool Interoperability with MCP

Historically, tool use was fragmented. Every agent developer wrote custom wrappers for every API. The Model Context Protocol (MCP) has standardized this by decoupling the agent from the tool server. MCP allows agents to discover tools via stdio or HTTP, meaning a single MCP server can provide database access to multiple different agents regardless of the underlying LLM.

Modern implementations now treat tools as pluggable resources. Instead of hard-coding a read_file function, the agent queries an MCP server to see what capabilities are available in the current environment.

Comparing Agentic Architectures

Different tools prioritize different patterns based on their target user:

  • Cursor and Windsurf: Focus heavily on the IDE-integrated pattern, where the tool is primarily a sophisticated LSP (Language Server Protocol) wrapper.
  • Claude Code and Aider: Lean into the terminal-centric pattern, treating the shell as the primary tool for environment manipulation.
  • AZMX AI: Implements a hybrid approach. It uses a native Rust backend to manage a real PTY terminal and a CodeMirror 6 editor, ensuring that tool use is not simulated but happens in a legitimate system process. By combining BYOK (Bring Your Own Key) with a strict deny-list for .env and .ssh files, it enforces a security-first tool use pattern.
# Example of a secure tool execution flow
1. Agent requests: "Read .env file"
2. Security Layer: Check deny-list -> Match found (.env)
3. Action: Block execution and return "Access Denied" to LLM
4. Agent: Adjusts strategy to look for config.example.json

Managing State and Memory

Tool use is useless if the agent forgets the result of the previous call. Project memory patterns, such as maintaining a persistent AZMX.md or a TODO.md file, allow agents to track state across sessions. This transforms the agent from a stateless function into a persistent collaborator that understands the current trajectory of the codebase.

The Context Window Constraint

A common mistake in tool use patterns is flooding the context window with massive tool outputs (e.g., dumping a 2,000-line log file). Effective patterns implement output truncation or summarization steps. The agent should first call a head or tail command, then decide if it needs to read the full file.

Implementing Tool Use in Production

To implement these patterns reliably, follow these technical constraints:

  1. Strict Schema Validation: Use JSON Schema to validate tool arguments before they hit the shell.
  2. Timeout Enforcement: Never allow a tool call to run indefinitely. Implement a hard timeout (e.g., 30 seconds) for all shell operations.
  3. Identity Isolation: Run tools in a restricted environment or container to prevent the agent from escalating privileges on the host machine.
  4. Audit Logging: Every tool call, its arguments, and the resulting output must be logged for post-mortem analysis.

For those building their own workflows, exploring the documentation on MCP and agentic boundaries is a critical first step. Whether you use a managed service or a sovereign platform like AZMX AI, the goal is to move the intelligence to the model and the safety to the system.

One window. The whole loop.