# Hub orchestration methodology

How Marketlinx DIGITAL designs AI and automation around HighLevel — not around a chatbot.

---

## The mistake most people make

They start with the AI: pick a model, write a prompt, bolt a widget onto the site. The CRM, telephony, calendars and workflows stay disconnected. The agent improvises because it has no tools, or it hallucinates because it has no grounding.

**Orchestration is not "which LLM".** It is how judgment, rules and data move through a system you can audit.

---

## The hub model

**HighLevel sits at the centre** as the communications hub: phone, SMS, email, chat, social, calendar, payments — one contact record.

Around it:

| Layer | What it does | Examples |
|-------|----------------|----------|
| **Bridge** | Brings external systems onto the same record | API v3, webhooks, OAuth, **MCP servers** |
| **Logic (rules)** | Deterministic automation — if X then Y | Workflows, n8n, scheduled jobs |
| **Logic (judgment)** | Conversations that need context and tools | Super Agents, Conversation AI, Voice AI |
| **Operator** | Humans and desktop AI building/maintaining the stack | You, your team, **Cursor**, **Claude Desktop** |

The agent is not the centre. The **record** is the centre.

---

## Four phases (every build, including AI)

Same method as client engagements — documented on `/engagement/`:

### 1. Audit

Map what exists before adding intelligence:

- Pipelines, fields, tags — are they consistent?
- What workflows fire today? Any duplicates or silent failures?
- Where does data enter (forms, calls, imports)?
- What external systems must the agent reach?
- What must **never** be automated (billing, legal, clinical)?

Output: written architecture record — not a slide deck.

### 2. Stage

Design in a sandbox sub-account or staging location:

- Scope **one job per agent** (qualify, book, triage — see skill library)
- Attach **narrow** knowledge bases (one doc = one decision)
- Wire **MCP tools** with least privilege — read before write
- Define **handoff triggers** and who receives them
- Run test conversations with real edge cases

Output: staged plan you sign off before production traffic.

### 3. Apply

Deploy in slices:

- One channel at a time (e.g. web chat before Voice AI)
- One tool at a time (lookup contact before book appointment)
- Validate each slice against live-ish data
- CRM notes on every automated action

Nothing touches live customer data until you sign off the phase.

### 4. Hand back

You keep the account and the data:

- Skill files and prompts documented
- MCP server URLs, scopes and env vars recorded
- Escalation path tested with a real human
- Monitoring: what to watch when the model or API changes

---

## Three types of orchestration

Use the right layer for the job. Mixing them causes pain.

### A. Workflow orchestration (deterministic)

**Use when:** the rule is fixed and the data shape is known.

- Lead comes in → tag → assign → send template → wait → branch on reply
- Webhook received → transform → upsert contact → trigger workflow
- n8n cron → fetch RSS → publish JSON (see resources changelog pattern)

**Do not use when:** the customer asks something outside the script.

### B. Agent orchestration (judgment + tools)

**Use when:** natural language, variable intent, but actions must be real (book, tag, lookup).

- Super Agent with skill library + MCP tools scoped to one sub-account
- Voice AI with grounded KB and explicit transfer to staff
- Hand off when: anger, policy, three failed KB lookups, tool error twice

**Do not use when:** a workflow would suffice — agents are slower and cost more per turn.

### C. Desktop AI orchestration (build and operate)

**Use when:** you are designing, debugging or extending the stack — not when a customer is waiting on the phone.

- **Cursor** — code, configs, marketplace apps, MCP server development, site builds
- **Claude Desktop** — research, architecture drafts, document review, MCP-connected ops

Connect both to MCP servers (HighLevel, Fathom, Supabase, custom APIs) so the model **calls tools** instead of guessing.

**Do not use when:** the task should be a production agent — desktop AI is for operators, not end customers.

---

## MCP's role

MCP (Model Context Protocol) is the **typed bridge** between desktop or hub agents and your systems.

Without MCP: the model describes what it would do.  
With MCP: the model **does** it — with permissions, structured errors and an audit trail.

Typical MCP servers in a HighLevel build:

| Server | Used for |
|--------|----------|
| HighLevel (native or custom) | Contacts, calendars, opportunities, notes |
| Custom middleware | Legacy DB, internal APIs, reconciliation |
| Productivity | Fathom transcripts → CRM fields, docs search |
| Infrastructure | Deploy logs, queue depth, health checks |

**Rule:** one server = one bounded domain. Do not give one MCP server god-mode across everything.

---

## Orchestration checklist (before go-live)

- [ ] Hub configured (setup guide steps 1–7) before agents (step 8)
- [ ] Each agent has **one primary job** and a skill file
- [ ] Knowledge base split by scope; anti-hallucination footers on sensitive docs
- [ ] MCP tools: read-only first; writes need confirmation or narrow scope
- [ ] Handoff path tested; CRM note template in place
- [ ] Workflow handles what the agent should **not** decide
- [ ] Desktop MCP config separate from production agent credentials
- [ ] Audit → stage → apply → hand back documented for the client

---

## Further reading on this site

- [Agent skill library](/resources/agent-skills/)
- [Prompt library](/resources/prompts/)
- [Architecture diagrams](/resources/diagrams/)
- [MCP & APIs service](/services/mcp-and-apis/)
- [Super Agents](/services/super-agents/)
- [How engagement works](/engagement/)