By James Aspinwall, co-written by Alfred Pennyworth (my trusted AI) — March 10, 2026, 11:02
Most AI integration stories start the same way: someone plugs an LLM into a tool, gets excited, then hits a wall. The agent can do too much, or too little. It has no memory of who asked, no sense of what’s allowed, and no awareness of what else is happening in the business.
We built two products to solve two different problems. They share a platform, a permission system, and an architecture — but they serve fundamentally different use cases.
The Connector
The Connector is the simplest version of the idea: give a user’s AI agent access to everything that user already has access to. No more, no less.
You’re using Claude for Mac, or ChatGPT Desktop, or whatever agent you prefer. You connect it to your company’s Connector instance. From that moment, your agent can reach the same third-party apps and internal resources you can — your CRM, your task management system, your monitoring dashboards, your databases. It sees what you see. It’s blocked from what you’re blocked from.
How it works:
The Connector exposes tools over MCP (Model Context Protocol). When your agent connects, it authenticates as you. The platform looks up your permission keys — the same ones that govern your web dashboard access, your API access, everything — and filters the available tools down to exactly what you’re allowed to touch.
Your agent asks to query the CRM. The Connector checks: does this user have CRM access? If yes, run the query. If no, reject it. Same logic, same permission boundary, same audit trail as if you’d done it yourself through the web interface.
There is no separate “agent permissions” layer. There is no admin granting the AI special access. The agent inherits your identity. Period.
What it’s good for:
- A salesperson asking their agent to pull pipeline numbers, draft follow-up emails, and update contact records — all through natural conversation
- A developer asking their agent to check monitoring alerts, query logs, and create tasks — without switching between six browser tabs
- Anyone who wants their AI assistant to actually do things in the systems they already use, with zero new access provisioning
The Connector is reactive. It waits for you to ask. It does what you tell it. It operates within your boundaries. Think of it as giving your AI assistant the same keycard you carry.
The Orchestrator
The Orchestrator is a different animal entirely.
Where the Connector serves one user and their agent, the Orchestrator runs multiple agents as a coordinated workflow. It doesn’t wait for someone to ask — it acts on events.
An email arrives. The Orchestrator reads it, determines which customer it’s from, updates their record in the CRM, drafts a response, alerts the account manager, schedules a follow-up task for next week, and notifies the support team — all without a human initiating anything.
How it works:
The Orchestrator manages a set of agents, each with its own access, its own resources, and its own goals. One agent watches the inbox. Another manages the CRM. A third handles scheduling. A fourth sends notifications. They coordinate through the platform, passing tasks and context between each other using Google’s A2A (Agent-to-Agent) protocol.
Each agent operates under its own permission boundary. The email-watching agent can read incoming messages but can’t modify the CRM. The CRM agent can update records but can’t send emails. The notification agent can push alerts but can’t access customer data. Least privilege, enforced at the platform level.
This matters. When an orchestrated workflow touches five systems, you need to know exactly which agent accessed which resource, with what authority, at what time. The audit trail isn’t a nice-to-have — it’s the entire point.
What it’s good for:
- Automated intake workflows: lead comes in, gets enriched, scored, routed, and followed up — across CRM, email, task management, and Slack
- Incident response: monitoring alert fires, relevant logs get pulled, stakeholders get notified, a post-mortem task gets created, all within seconds
- Customer lifecycle: contract renewal approaching, agent checks usage data, drafts a renewal proposal, schedules a meeting, and alerts the account team
- Any business process that currently requires a human to notice an event, then manually update three systems and notify two people
The Difference
| Connector | Orchestrator | |
|---|---|---|
| Serves | One user and their agent | Multiple agents in a workflow |
| Triggered by | User request | Events (email, webhook, schedule, alert) |
| Permissions | Inherits the user’s access | Each agent has its own access |
| Protocol | MCP | MCP + A2A |
| Personality | Reactive assistant | Autonomous coordinator |
| Goal | Make the user faster | Make the process run itself |
The Connector makes you more productive. The Orchestrator makes you less necessary — at least for the routine stuff.
Same Foundation
Both products run on the same platform. Same access control system. Same audit logging. Same supervision trees keeping everything alive. Same permission keys governing what every agent, user, and workflow can touch.
This isn’t two products bolted together. It’s two modes of the same system. A user who connects their Claude agent through the Connector is using the same permission infrastructure that governs the Orchestrator’s automated workflows. Promote a Connector tool to an Orchestrator agent and it carries its permission model with it.
The access control layer is the product. Everything else is just the shape of the door you walk through.
What This Means for Your Business
If you have people spending their day copying data between systems, answering routine emails, and updating spreadsheets after every meeting — that’s Orchestrator territory. Automate the workflow, let the agents handle the plumbing.
If you have knowledge workers who need fast access to information scattered across a dozen tools — that’s Connector territory. Give their AI assistant the same access they have, and let them work through conversation instead of tab-switching.
Most companies need both. Start with the Connector — it’s the easier win, and it builds trust in the system. Then identify the repetitive workflows that eat your team’s time, and hand those to the Orchestrator.
The goal isn’t to replace your team. It’s to stop making them do work that a well-governed set of agents can handle faster, more reliably, and at 3 AM on a Sunday.