> ## Documentation Index
> Fetch the complete documentation index at: https://docs.fim.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Execution Modes

> Standalone, Copilot, and Hub — three ways to deploy FIM One.

## Three modes

FIM One operates in three modes, determined by how the agent is deployed and used:

| Mode           | What it is                         | Delivery                | Example                                                   |
| -------------- | ---------------------------------- | ----------------------- | --------------------------------------------------------- |
| **Standalone** | General-purpose AI assistant       | Portal                  | Chat, search, code execution, knowledge base Q\&A         |
| **Copilot**    | AI embedded in a host system       | iframe / widget / embed | "Finance Copilot" embedded in ERP web UI                  |
| **Hub**        | Central cross-system orchestration | Portal / API            | Agent queries ERP, checks OA approvals, notifies via Lark |

The progression is natural: start standalone, embed into a host system as a Copilot, then set up a Hub for cross-system orchestration. The Copilot keeps running embedded; the Hub adds a central orchestration layer.

## Mode details

### Standalone (0 connectors)

The default mode. FIM One works as a full-featured AI assistant:

* Built-in tools: web search, Python execution, calculator, file operations, shell commands
* Knowledge base with RAG (PDF, DOCX, Markdown, HTML, CSV)
* Dynamic DAG planning for complex multi-step tasks
* Real-time streaming with DAG visualization

No external system access needed. Useful for general analysis, research, and code tasks.

### Copilot (embedded)

Embed FIM One into a host system's web UI. The agent works alongside users in their familiar interface — no context switching required. Copilot mode can use multiple connectors (e.g., the host system's DB + a notification service).

```mermaid theme={null}
flowchart LR
  subgraph Host["Host System (ERP / CRM / OA)"]
    Copilot["FIM One Copilot<br/>(iframe / widget)"]
  end
  Copilot -- Connectors --> DB["DB"]
  Copilot -- Connectors --> API["API"]
  Copilot -- Connectors --> Lark["Lark"]
```

Examples:

* **Finance Copilot**: Connected to Kingdee (金蝶) via DB connector → query financial statements, generate analysis reports
* **Contract Copilot**: Connected to contract management system via API connector → search contracts, extract clauses, assess risk
* **HR Copilot**: Connected to HR system via API connector → query employee info, generate statistics

The agent uses the same ReAct/DAG engine as Standalone mode, but now has access to real business data through the connector.

### Hub (central orchestration)

The Hub is a standalone portal (or API) that serves as the central intelligence layer. It's not embedded in any single system — instead, it connects to all of them. Users access it through the Portal UI or API.

```mermaid theme={null}
flowchart LR
  ERP --> Hub["FIM One Hub<br/>(AI orchestration)"]
  Database --> Hub
  Lark --> Hub
  CRM --> Hub
  OA --> Hub
  CustomAPI["Custom API"] --> Hub
```

Examples:

* "Check overdue contracts in CRM, cross-reference with ERP payments, notify finance team on Lark"
* "When OA approval completes, update contract status in CRM and log to audit database"
* "Query sales data from Salesforce, generate forecast using business DB, email summary to management"

Each connector is an independent bridge. Adding or removing one doesn't affect the others.

## Delivery methods

| Delivery            | Description                                        | Typical mode              |
| ------------------- | -------------------------------------------------- | ------------------------- |
| **Portal (Web UI)** | Built-in Next.js interface                         | Standalone, Hub           |
| **API (headless)**  | HTTP/SSE endpoints (`/api/execute`, `/api/stream`) | Hub (programmatic access) |
| **iframe / Embed**  | Injected into host system pages                    | Copilot                   |

Delivery and mode are related but not locked: you can access a Hub via API, or use a standalone agent through the Portal. But the typical pattern is Portal for Hub, embed for Copilot.

## Execution engines (internal implementation)

Under the hood, FIM One provides two execution engines:

| Engine           | Best for                  | How it works                                                       |
| ---------------- | ------------------------- | ------------------------------------------------------------------ |
| **ReAct**        | Single complex queries    | Reason → Act → Observe loop with tools                             |
| **DAG Planning** | Multi-step parallel tasks | LLM generates dependency graph, independent steps run concurrently |

```mermaid theme={null}
flowchart TD
  DAG["DAG Planning<br/>(orchestration layer)"]
  DAG --> step_1
  DAG --> step_2
  step_1 --> ReAct1["ReAct Agent"] --> Tools1["Tools"]
  step_2 --> ReAct2["ReAct Agent"] --> Tools2["Tools"]
  step_1 & step_2 --> step_3
  step_3 --> ReAct3["ReAct Agent"] --> Tools3["Tools"]
```

ReAct is the atomic unit; DAG is the orchestration layer. Both engines work in all three modes (Standalone, Copilot, Hub). In Hub mode, a single DAG step might call connectors to different systems.

## Two execution paradigms

FIM One provides two complementary paradigms for getting work done:

| Paradigm         | Orchestration                                                   | Best for                                               |
| ---------------- | --------------------------------------------------------------- | ------------------------------------------------------ |
| **Agent (Chat)** | LLM decides next step dynamically (ReAct or DAG)                | Exploratory tasks, conversations, flexible reasoning   |
| **Workflow**     | Fixed DAG defined at design time (visual editor, 26 node types) | Approval chains, scheduled ETL, multi-step automations |

**Agents** excel when the task is open-ended — "analyze this quarter's data and recommend actions." The LLM plans and adapts on the fly.

**Workflows** excel when the process is known and repeatable — "every Monday, pull invoices from ERP, run compliance checks, route exceptions to a reviewer." The visual editor lets you wire nodes (Agent, Connector, KB, LLM, HTTP, Code, Human Approval, Sub-Workflow) into a fixed DAG.

The two paradigms compose naturally: a Workflow can invoke an Agent at any step that needs flexible reasoning within an otherwise fixed pipeline. Agents cannot directly call Workflows — the relationship is one-directional.

<Tip>
  **When to choose which:** If you find yourself writing very specific, step-by-step instructions for an Agent, that process probably belongs in a Workflow. If the task requires judgment, exploration, or adapting to unexpected data, keep it as an Agent.
</Tip>