AgentBridge

Appearance

Module 1: The Tool-Agnostic Paradigm ​

1. Introduction: The "Swiss Army Knife" Enigma ​

Imagine you are building a robot. In the traditional way of doing things, if you wanted your robot to be able to use a screwdriver, you would weld a screwdriver onto its hand. If you wanted it to paint, you would weld a paintbrush. This robot is highly specialized. It is fantastic at screwing and painting, but if you suddenly need it to hammer a nail, you are out of luck. You have to take the robot back to the factory, cut off the paintbrush, and weld on a hammer.

This is how most "Agents" are built today. A developer hard-codes a specific function, say get_weather(), directly into the agent's code. The agent knows exactly what that function does, what arguments it takes, and how to use it. But the moment you want the agent to check your email instead, you have to rewrite the code.

The Tool-Agnostic Paradigm flips this model on its head. Instead of welding tools to the robot's hands, we give the robot human hands. The robot doesn't know what a "hammer" is until you hand it one. It looks at the hammer, reads the label that says "Use this to hit nails", and then it knows how to use it.

In technical terms, our Agent Logic (agent_orchestrator.py) contains zero hard-coded tools. It is a pure reasoning engine. It knows how to "call a tool" in the abstract, but it doesn't know which tools exist until the moment a user starts a conversation.

2. Why does this matter? ​

You might ask, "Why go through this trouble? Why not just write a really good GitHub Agent?"

The answer lies in Combinatorial Complexity.

Let's say we support 3 tools: GitHub, Slack, and Jira.

  • User A wants a "DevOps Bot" (GitHub + Jira).
  • User B wants a "Communication Bot" (Slack).
  • User C wants a "Super Bot" (All three).

If we built agents the traditional way, we might end up maintaining three different codebases or complex configuration files. Now imagine we have 100 tools. The number of possible combinations is astronomical. We cannot build a specialized agent for every possible user workflow.

By building a Tool-Agnostic Agent, we build the "Brain" once.

  • When User A logs in, we dynamically "inject" the definitions for GitHub and Jira into the Brain.
  • When User B logs in, we inject only Slack.

The codebase remains 100% identical for both users. The behavior changes entirely based on the context.

3. The "USB Port" for AI: Model Context Protocol (MCP) ​

This paradigm sounds great in theory, but how do we actually implement it? How can we write one piece of code that can talk to GitHub and Notion and a local SQL database, without writing custom integration code for each one?

Historically, this was the bottleneck. You would need a GitHubClient class, a NotionClient class, etc.

Enter the Model Context Protocol (MCP).

Think of MCP as the USB standard for AI tools. Before USB, if you wanted to connect a printer, you needed a parallel port. A mouse? A serial port. A keyboard? A PS/2 port. Every device needed a specific physical connector and a specific driver. After USB, everything plugs into the same rectangular port. The computer asks, "What are you?" and the device replies, "I am a mouse." The computer then knows how to treat it.

MCP does the same for our Agent. Instead of writing a GitHubClient, we write a generic McpClient.

  1. Our Agent connects to an MCP Server (running locally or remotely).
  2. The Agent asks: "What tools do you have?"
  3. The Server replies with a standard JSON definition:
    json
    {
  "name": "create_issue",
  "description": "Creates a new issue in the repository",
  "parameters": { ... }
}
  4. The Agent takes this JSON and says, "Okay, I now know how to create issues."

This is why you will see very little "business logic" in our backend code. We don't verify if a GitHub issue title is valid. We don't check if a Jira ticket exists. We simply act as a Router, passing messages between the LLM and the MCP Server.

4. Summary ​

Our Agent is not a specialist; it is a General Purpose Reasoner.

  • It creates scalability: We can add 1,000 new tools without changing a line of the agent's core code.
  • It creates personalization: Every user gets a custom agent assembled on-the-fly.
  • It relies on standards: MCP allows us to treat "Tools" as abstract data, not hard dependencies.

In the next module, we will verify this by looking at the Orchestrator — the actual Python code that implements this generic reasoning loop.