Skip to main content

​
Copilot vs Hub

The architecture supports two integration scales: Copilot embeds into a host system’s UI. Users interact with AI without leaving their familiar interface. It can use multiple connectors (host DB + notification service, etc.). Hub is a standalone portal that connects all systems. It’s not embedded in any single system — it’s the central intelligence layer where systems meet AI. Same connector architecture, different delivery. A Copilot uses the same ConnectorToolAdapter as a Hub.

​
Core Principle

The client changes zero code. FIM Agent bridges into their systems proactively — reading their databases, calling their APIs, pushing to their message bus. The client provides only credentials and network access.

​
Three-Layer Architecture

Each layer has a distinct responsibility:
LayerOwnsChanges when…
PlatformOrchestration, multi-tenant, UINew platform features ship
Connector Governance LayerEnterprise governance policiesSecurity/compliance requirements change
MCP ProtocolTransport, tool interface standardNever (open standard)
Legacy SystemBusiness data and logicNever (that’s the whole point)

​
Why MCP as the Transport Layer

Adapters are implemented as MCP Servers. This is a deliberate architectural choice:
  • Reuse: FIM Agent already ships an MCP Client (v0.3). Adding a legacy system adapter reuses the same infrastructure as adding any MCP tool.
  • Standard protocol: MCP is an open standard. No proprietary protocol to invent or maintain.
  • Ecosystem: Third-party MCP Servers (databases, APIs, SaaS tools) work out of the box.
  • Process isolation: Each MCP Server runs as a separate process. A misbehaving adapter cannot crash the platform.

​
What MCP alone does not provide

The Connector Governance Layer adds enterprise governance that raw MCP lacks:
ConcernMCPConnector Governance Layer
Read-only enforcementNoread_only flag on operations; write blocked by default
Audit loggingNoEvery tool call recorded (timestamp, user, tool, params, result)
Auth passthroughNoProxy host-system auth; agent acts on behalf of logged-in user
Confirmation gateNoWrite operations require human approval (SSE confirmation_required)
Circuit breakerNoConnection failure triggers graceful degradation
Operation classificationNoOperations tagged as read/write/admin with per-level policies

​
Why not invent a custom protocol

Protocol is commodity. The technical value is in the adapters themselves (domain knowledge, schema mapping, edge-case handling) and the governance layer (audit, auth, safety). Inventing a transport protocol would add maintenance cost without adding capability. Stripe uses HTTPS; Docker uses cgroups; FIM Agent uses MCP.

​
Deployment Model

Everything runs in a single Docker Compose deployment. The client installs nothing.
All provided by FIM Agent. Client provides only:
  • Database credentials (read-only account recommended)
  • API endpoints and keys (if available)
  • Network whitelist access
Access hierarchy: FIM Agent adapts to whatever access the client can provide:
What client hasHow FIM Agent connects
API with documentationHTTP API adapter (best case)
API without documentationHTTP API adapter + manual schema mapping
Database access onlyDatabase adapter (direct SQL, read-only by default)
Database + message busDatabase adapter + message push adapter

​
Agent-Connector Decoupling

The agent sees connectors as ordinary tools. It does not know or care whether a tool is built-in, a third-party MCP Server, or a legacy system connector. This means:
  • Adding a new system = adding a connector config. Agent code does not change.
  • Removing a connector = removing the config. No code changes.
  • The same agent can use built-in tools and connectors in a single task.

​
Hot-Plug Evolution

VersionHow to add a new connectorRestart required?
v0.6Write a Python MCP Server with Connector Governance Layer, add to docker-composeRedeploy
v0.8Write a YAML/JSON config, platform generates MCP ServerRestart
v1.0Upload OpenAPI spec, AI generates config automaticallyNo restart (hot-plug)
Enterprise deployments are “implement once, run for months” — hot-plug is a v1.0 convenience, not a v0.6 requirement.

​
Data Flow Example

User: “Check all overdue contracts from the finance system and push a summary to Lark.” 
1. User sends message via Portal / API

2. FIM Agent (ReAct mode):
   Think: I need to query the finance DB for overdue contracts, then push to Lark.

3. Act: contract_query(status="overdue", days_past_due=">30")
   → Connector Governance: audit log, read_only check (pass)
   → MCP Server: translates to SQL
   → Client DB: SELECT * FROM contracts WHERE status='overdue' AND ...
   ← Returns 7 overdue contracts

4. Think: Found 7 overdue contracts. I'll summarize and push.

5. Act: lark_push(message="7 overdue contracts found: ...")
   → Connector Governance: audit log, write operation → confirmation gate
   → User approves via Portal
   → MCP Server: POST to Lark webhook
   ← Push successful

6. Answer: "Found 7 overdue contracts. Summary pushed to Lark group."

​
Connector Standardization Levels

LevelVersionApproachWho builds it
Level 1v0.6Python MCP Server with Connector GovernanceFIM Agent developer
Level 2v0.8YAML/JSON config, platform auto-generates MCP ServerImplementation engineer (no Python needed)
Level 3v1.0Upload OpenAPI/Swagger spec, AI generates configAI (with human review)

​
Relationship to Existing MCP Ecosystem

FIM Agent’s MCP Client (shipped in v0.3) already supports third-party MCP Servers. Legacy system adapters are simply domain-specific MCP Servers built with the Connector Governance Layer for enterprise governance. The Connector Governance Layer does not replace MCP — it extends MCP with the governance layer that enterprise legacy system integration requires.