Architecting Model-Agnostic AI Agents: Decoupling the LLM "Brain" from Tooling and Orchestration

In the rapidly evolving landscape of Large Language Models (LLMs), dependency is a significant business risk. Recent industry observations have highlighted a troubling trend: providers like Anthropic have been known to quietly degrade model performance without prior announcement, and OpenAI has faced scrutiny for silently routing paying users to cheaper, less capable model variants. For developers and business owners running mission-critical automated workflows, these "silent updates" can lead to catastrophic failures in agentic logic, directly impacting revenue and operational stability.

To mitigate this, we must move away from model-dependent architectures and toward a decoupled, modular stack. The goal is to build an agent where the "Brain" (the LLM) is a swappable configuration rather than a hardcoded dependency.

The Three-Layer Agent Architecture

A robust AI agent does not consist of a single model; rather, it is comprised of three distinct, independent layers: the Brain, the Hands, and the Loop.

1. The Brain (The LLM)

The Brain is the reasoning engine. By utilizing OpenRouter, we can abstract the model layer. OpenRouter provides a unified API interface, allowing us to access Claude, GPT, Gemini, and emerging models like MiniMax through a single API key. This abstraction allows us to swap the underlying model by changing a single line of code, ensuring that if one provider's performance degrades, the agent can be re-routed to a different provider instantly.

2. The Hands (The Tooling Layer)

The Hands represent the agent's ability to interact with the external world. Rather than writing complex, custom authentication flows, OAuth logic, and token refresh cycles for every third-party integration, we utilize the Zapier SDK. This provides access to over 9,000 applications (including Gmail, Slack, and Google Sheets) through a standardized interface. By leveraging the SDK, the agent's ability to "act" remains constant, regardless of which "Brain" is currently processing the logic.

'3. The Loop (The Orchestration Layer)

The Loop is the execution logic—the TypeScript code that manages the lifecycle of a request. It listens for a trigger, passes the context to the Brain, executes the necessary tools via the Hands, and processes the output. Using Claude Code, we can implement this orchestration in a highly concise manner—often in under 70 lines of TypeScript.

Technical Implementation: The Gmail-to-Slack Triage Agent

To demonstrate the efficacy of this decoupled stack, let's look at the implementation of an automated inbox triage agent. The objective is to monitor unread Gmail messages, reason over their content, and post a summarized takeaway to a specific Slack channel.

The Tech Stack

• Language: TypeScript
• Runtime/Execution: tsx
• Orchestration: Claude Code (for rapid development)
• Tooling Interface: Zapier SDK
• Model Gateway: OpenRouter
• Environment Management: dotenv

Implementation Workflow

The development process begins with setting up the "Hands." Using the Zapier SDK, we authenticate via OAuth to establish connections with Gmail and Slack. Once authenticated, the SDK allows us to list and interact with these connections programmatically.

The core of the agent is a single TypeScript file (agent.ts). The implementation follows a Proxy Pattern to bind the specific tools (Gmail and Slack) to the agent's execution loop. The code structure is as follows:

1. Environment Initialization: Loading API keys for OpenRouter and Zapier via dotenv.
2. SDK Initialization: Initializing the createZapierSDK instance and resolving the specific connection IDs for Gmail and Slack.
3. The Execution Loop:
   • The agent queries the Gmail connection for unread messages.
   • The content is passed to the LLM (the Brain).
   • The LLM performs reasoning (triage, summarization, or action determination).
   • The agent utilizes the Slack connection to post the resulting summary.

Using Claude Code, we can prompt the system to generate this entire logic. A single prompt can instruct the AI to build the agent.ts file, implement the imports, initialize the Zapier SDK, and define the tool-calling loop.

Example Execution Output

When running the agent via npx tsx agent.ts, the terminal output demonstrates the reasoning process:

• Action: slack_user_lookup (identifying the recipient).
• Action: gmail_read_unread (retrieving recent emails).
• Reasoning: The model analyzes the 20 unread emails, filtering out newsletters and noise.
• Action: slack_post_message (sending the final recap).

Strategic Model Selection: Optimizing for Cost and Performance

The true power of this architecture is revealed during the "Model Swap." Because the tools and the loop are decoupled, we can select a "Brain" based on the specific complexity of the task, optimizing for both latency and cost.

By utilizing this stack, we can run 90% of our routine, low-complexity tasks on Gemini or MiniMax, reserving the expensive, high-reasoning models like Claude Opus only for critical, high-stakes decision-making.

Conclusion: Building for Resilience

The takeaway for any AI engineer or business owner is clear: The agent is not the model; the agent is the architecture.

By separating the Brain, the Hands, and the Loop, you stop being a hostage to a single provider's roadmap. You are no longer vulnerable to silent model degradations or sudden API changes. You are building a resilient, programmable loop where the model is simply a configurable setting. This is the only way to build sustainable, scalable AI operations in an era of unpredictable provider updates.