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).
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.
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 |
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.
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.