Skip to main content

Three modes

FIM One operates in three modes, determined by how the agent is deployed and used:
ModeWhat it isDeliveryExample
StandaloneGeneral-purpose AI assistantPortalChat, search, code execution, knowledge base Q&A
CopilotAI embedded in a host systemiframe / widget / embed”Finance Copilot” embedded in ERP web UI
HubCentral cross-system orchestrationPortal / APIAgent 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

DeliveryDescriptionTypical mode
Portal (Web UI)Built-in Next.js interfaceStandalone, Hub
API (headless)HTTP/SSE endpoints (/api/execute, /api/stream)Hub (programmatic access)
iframe / EmbedInjected into host system pagesCopilot
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:
EngineBest forHow it works
ReActSingle complex queriesReason → Act → Observe loop with tools
DAG PlanningMulti-step parallel tasksLLM 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:
ParadigmOrchestrationBest for
Agent (Chat)LLM decides next step dynamically (ReAct or DAG)Exploratory tasks, conversations, flexible reasoning
WorkflowFixed 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.