Use this file to discover all available pages before exploring further.
Goal: Build an all-in-one agent platform for Global × China enterprises — delivered through three progressive modes: Standalone (portal assistant), Copilot (embedded in host system), Hub (central cross-system orchestration).Principles: Provider-agnostic (no vendor lock-in), minimal-abstraction, protocol-first, connector-first (integration is the core value).
FIM One is an all-in-one agent platform that serves three progressive delivery modes:
Standalone → Your own AI assistant (Portal)Copilot → AI embedded in a host system (iframe / widget / embed)Hub → Central cross-system orchestration (Portal / API)
Cross-system orchestration is the core differentiator. Enterprise clients have legacy systems — ERP, CRM, OA, finance, HR — that need to talk to each other through AI:GTM path: Land and Expand
Step
Mode
What happens
Land
Copilot
Embed into one system, prove value inside their UI
Expand
Copilot → Hub
Roll out to more systems; Hub mode aggregates them
Tracked bugs that are reproducible in production but not yet fixed. Each entry names the symptom, the suspected surface area, and the workaround (if any). Items move to a version section once a fix is scoped and scheduled.
Agent editor shows unsaved-changes warning on entry without any edit. Opening an existing agent via /agents/[id] and immediately clicking back triggers the “Unsaved changes” dialog even when no field was touched. The dirty check diffs 20+ fields against the loaded agent payload, so one asymmetric default between state init and dirty compare is enough to cause a phantom mismatch — current suspicion is one of the nested model_config_json / notification / approval-routing fields, possibly from undefined vs null vs "" normalization. Reproduces on org-scoped agents in particular. Workaround: dismiss the dialog (Discard and leave) — no data loss since nothing actually changed. Attempted fix (cb40c86a) removed a related orphan-badge flicker on the resource pickers but did not resolve this.
Saving an agent edit can fail with Input should be 'initiator', 'agent_owner' or 'org_members'. Pydantic rejects the confirmation_approver_scope field at the /api/agents/{id} PUT boundary even though every stored value in the database is one of the three valid literals. Suspicion: the frontend as "initiator" | "agent_owner" | "org_members" cast is a compile-time-only promise, so a legacy or unexpected runtime string (possibly from a template, import, or older migration) can slip through setConfirmationApproverScope and be echoed back verbatim. Workaround: explicitly re-select a value in the Approval → Approver Scope dropdown before saving.
Playground stop-and-retry shows transient visual artefacts that a page refresh always clears. Three concurrent render sources — activeConversation.messages (DB snapshot), the SSE messages stream, and the optimistic pendingQuery placeholder — are not collapsed into a single derived state, so between clicking “Retry” and the paired assistant response landing, the UI can (a) briefly render the same query twice in the pre-stream window, (b) drop prior orphan user bubbles from the retry history while hasLiveMessages is true and before the snapshot reloads, and (c) flicker in the narrow window between the SSE “done” event and the next selectConversation refresh. Data is never lost — every user message (including aborted retries) is persisted in conversation.messages, carried into the next LLM call via normalize_alternating_messages, and rendered correctly after refresh via HistoryTurn.orphanUserContents introduced in the 48ba08c6 render fix. For context, Claude’s own web UI exhibits an analogous class of bug — stopping mid-response and immediately sending a follow-up query sometimes forks the follow-up as a sibling-edit branch of the first query rather than appending it as a new turn — so this is a known hard problem in optimistic-UI + SSE + persisted-history designs, not a FIM-One-specific defect. A proper fix requires collapsing the three render sources into a single derived state; deferred until a broader Playground state-machine refactor.
Models configuration documentation page with extended thinking setup per provider
SSE Protocol v2: real-time answer streaming with delta_reasoning, usage fields, and split done/suggestions/title/end events; SQLite pool size 5 -> 20
AI Builder expansion: 7 new builder tools (GetSettings, TestConnection, ImportOpenAPI for connectors; ListConnectors, AddConnector, RemoveConnector, SetModel for agents), is_builder flag on agents, builder prompt auto-refresh, SSRF guard
SSE v2 frontend: streaming dot-pulse cursor, DAG re-plan round snapshots as collapsible cards, DAG layout decoupled from step states
AI Builder concept documentation page with connector and agent builder guides
Organization system: full CRUD with role-based membership (owner/admin/member), admin management UI
Database Connectors (Phase 1-3): direct SQL access to PG/MySQL/Oracle/SQL Server + Chinese legacy DBs; schema introspection, AI annotation, read-only query execution, encrypted credentials, 3 tools per connector (list_tables, describe_table, query)
Three model roles (General/Fast/Reasoning) with per-tier env config isolation; fast model no longer inherits main model settings
StepOutput dataclass replacing plain string step results for structured data and artifact passing
Tool cache for DAG execution — identical tool calls cached per-run with async lock stampede prevention (DAG_TOOL_CACHE)
Per-step LLM verification with 1 retry on failure (DAG_STEP_VERIFICATION)
Auto-routing: fast LLM classifies queries as ReAct or DAG; /api/auto endpoint; frontend 3-way mode toggle (AUTO_ROUTING)
Shadow Market Organization + Resource Subscriptions: Built-in Market org (shadow, no auto-join) replaces Platform org; resources discovered via marketplace browsing and explicitly subscribed (pull model); Market API for subscribing to shared resources; publish-to-Market always requires review; Resource subscriptions table; org-based resource sharing replacing global visibility
Agent Auto-discovery and Sub-agent Binding: discoverable flag on agents; sub_agent_ids whitelist; CallAgentTool for delegating tasks to specialist agents
MCP Server Credentials + Per-User Override: mcp_server_credentials table; PUT /api/mcp-servers/{id}/my-credentials endpoint; allow_fallback flag for credential fallback behavior
Connector/KB Toggle: POST /api/connectors/{id}/toggle and POST /api/knowledge-bases/{id}/toggle for suspending/resuming resources
Standalone KB Conversations: kb_ids field on conversations for direct KB chat without agent binding
Publish review UI: Org-level publish review system — review toggle per org, ReviewsSheet with approve/reject workflow, status badges on resource cards, review notice in publish dialog, resubmit for rejected resources
Connector Progressive Disclosure (Phase 1-2): single ConnectorMetaTool replaces per-action tools; system prompt receives lightweight stubs only (name + 1-line description, ~30 tokens/connector vs ~250 tokens/action); agent calls discover(connector) to load full action schema on demand — schema only loads when the model selects a connector, keeping the prompt prefix stable for caching. Follows the deferred tool-loading pattern common in modern agent frameworks. execute subcommand; feature flag for backward compatibility.
Agent Skill System + Compact Instructions: On-demand skill loading for agent instructions — Skill model (name, content/SOP, optional scripts) attached to agents; referenced in system prompt by name only (~10 tokens/skill); agent calls read_skill(name) to load full content on demand. Reduces per-conversation instruction token cost by ~80% while allowing richer SOP libraries. Counterpart to ConnectorMetaTool’s progressive disclosure applied at the instruction level. Enables the “指令 + 工具 + 技能” differentiation story. Also adds compact_instructions field to Agent model — per-agent compression priority list injected into ContextGuard when compacting (e.g., “preserve order IDs and amounts, drop raw API responses”), replacing the current static generic prompt. Follows the Compact Instructions convention widely adopted in modern agent frameworks.
Workflow Phase 2 Nodes: Iterator, Loop, VariableAggregator, ParameterExtractor, ListOperation, Transform, DocumentExtractor, QuestionUnderstanding, HumanIntervention — 9 advanced node types with full frontend + backend + 150 new tests (275 total). Node retry with exponential backoff, safe expression evaluation. Stats panel with success rate bar. 12 built-in templates. Pane context menu (Paste, Select All, Fit View, Auto Layout).
Workflow Phase 3 Nodes: SubWorkflow + ENV — 2 new node types (25 nodes total), 14 new tests (306 total), 14 built-in templates. SubWorkflow: full DB-backed nested workflow executor with target workflow selection, variable mapping, and configurable depth limit to prevent infinite recursion. ENV: reads encrypted environment variables with key picker and fallback defaults. Full frontend (node components, config panels, palette entries, minimap colors). Per-node execution statistics panel (success rates, durations, failure counts sorted worst-first). getNodeStats API client + NodeStatEntry type. Keyboard shortcuts dialog (? key).
Workflow Scheduled Triggers: Per-workflow cron configuration with timezone, default inputs, and next-run-at calculation. Preset cron buttons, 30 trigger tests.
Workflow API Triggers: Public per-workflow API keys (wf_ prefix) for external execution without user auth, with rate limiting. API key management dialog with generate/regenerate/revoke, trigger URL, and cURL/JS examples.
Workflow Batch Execution: POST /batch-run with up to 100 input sets, configurable parallelism (1-10), collapsible per-item results, JSON export. 14 batch execution tests.
Workflow Execution Log Viewer: Real-time chronological SSE event stream in the run panel with timestamps, color-coded badges, and event type filter toggles.
Workflow Run Stats: Backend batch-fetches run counts and success rates via GROUP BY subquery; frontend displays stats on workflow cards with color-coded success rate indicators.
Workflow Scheduler Daemon: Background async service polling every 60s for due cron-based workflows. Croniter timezone support, semaphore concurrency, last_scheduled_at tracking, webhook delivery. 14 tests.
Workflow Import Conflict Resolver: Detects unresolved agent/connector/KB/MCP references during import. Batch DB queries with visibility filtering, frontend toast warnings. 17 tests.
Workflow Test-Node Execution: Isolated single-node testing with mock variables, integrated into editor (config panel Test button + context menu). 23 tests.
Workflow Version Diff: Side-by-side blueprint comparison with node/edge change detection, color-coded indicators (added/removed/modified).
Workflow Run Management: Delete individual runs (DELETE /runs/{run_id}) and clear all completed runs (DELETE /runs), with frontend confirmation dialogs.
Workflow Run Replay Overlay: “View on Canvas” button in run history to overlay past execution results on the canvas, showing per-node status and output without re-executing.
Workflow Favorites/Pinning: Star/pin workflows to the top of the list with localStorage persistence.
Workflow Run History Export: Export run history as JSON file download with full run metadata and per-node results.
Admin Workflows Management: Admin panel tab for managing all workflows across users — list, toggle active/inactive, delete with confirmation. Batch endpoints for delete, toggle, and publish with audit logging.
Workflow Templates System: WorkflowTemplate ORM model with admin CRUD, public listing/clone API, and 5 seed templates auto-inserted on first startup.
Workflow Inline Validation Badges: Real-time per-node ValidationBadge on canvas with error/warning tooltips for immediate visual feedback during editing.
Workflow Execution Trace Viewer: Timeline-based trace viewer Sheet with engine trace_level parameter and per-node variable snapshots for step-through debugging.
Workflow Rate Limiting and Timeout: Per-user WorkflowRateLimiter (sliding window 10 runs/min, 3 concurrent) and default 10-minute global run timeout.
Workflow Blueprint System: Visual workflow editor for designing and executing multi-step automation blueprints — Workflow / WorkflowRun ORM models, full CRUD + SSE execution API, import/export, duplicate, blueprint validation endpoint, WorkflowEngine with topological sort + semaphore-based concurrency + condition branching and 12 node types (Start, End, LLM, ConditionBranch, QuestionClassifier, Agent, KnowledgeRetrieval, Connector, HTTPRequest, VariableAssign, TemplateTransform, CodeExecution), VariableStore with {{node_id.output}} interpolation and env.* namespace, error strategies per node (STOP_WORKFLOW / CONTINUE / FAIL_BRANCH) with per-node timeout and advanced config UI, React Flow v12 visual editor with drag-and-drop palette + node config panel + variable picker combobox + add-node-on-edge + auto-layout (ELK.js) + run history sheet, Dify-style compact node design with ring-based run status styling and animated edge transitions, 4 built-in starter templates (Simple LLM Chain, Conditional Router, Knowledge-Augmented QA, HTTP API Pipeline) with template picker dialog and GET /templates + POST /from-template API, stats endpoint, ?run=true URL param auto-open, subprocess-based code execution security, 105-test suite (templates, eval namespace flattening, blueprint validation warnings, node/edge deletion, import/export/duplicate, deadlock detection, multi-condition branching)
Operation audit: detailed logging of who did what — admin review log audit tab added (publish review trail per org/resource)
Semantic Schema Annotations: extend connector schema fields with semantic_tag, description, and pii flags; annotations surfaced in LLM tool descriptions so the agent understands field intent without guessing from column names
Agent Core Phase 0 — Compact prompt upgraded to 9-section structured format; empty tool result protection (descriptive message instead of (no output)); anti-loop prompt + cycle detection threshold lowered to 2; domain classifier + pre-flight DB config resolution parallelized (400–1100 ms saved per request); SSE end event sent immediately after answer, with title/suggestions moved to background tasks
Agent Core Phase 1 (Context Anti-Bloat) — MicroCompact rule-based old tool result cleanup (keep last 6); REACT_TOOL_RESULT_BUDGET=40000 aggregate cap; reactive compact on context overflow (auto-compact to 50% budget and retry instead of crashing)
Agent Core Phase 2 (Speed) — Keyword-based tool pre-selection (skips LLM call on obvious matches, 200–500 ms saved); SharedHttpClient LLM connection pooling; completion check skipped for answers >200 tokens; FallbackLLM wraps primary+fast with automatic failover on 429/503/529/connection errors
Intelligent Document Processing (Vision-Aware) — Adaptive document handling: PDF pages rendered as images via PyMuPDF for vision-capable models (GPT-4o, Claude 3/4, Gemini), text-only fallback via pdfplumber. Per-model supports_vision flag. Modes via DOCUMENT_PROCESSING_MODE, DOCUMENT_VISION_DPI, DOCUMENT_VISION_MAX_PAGES. DOCX/PPTX embedded image extraction. Multi-turn vision persistence across conversation turns. Smart PDF processing (text-rich pages extract text + images; scanned pages render as full-page PNG). Pre-built sandbox image (Dockerfile.sandbox) with common data-science packages for --network=none code execution
File integrity guardrail — System prompt rule prevents the agent from substituting unrelated file contents when a target file is unreadable; uploaded files now include file_id in message context for direct read_uploaded_file access
System prompt section registry with cache breakpoints — Memoized PromptRegistry splits system prompts into stable prefix + dynamic suffix; cache-capable providers (Claude, Bedrock Anthropic, Vertex Claude) receive cache_control: {"type": "ephemeral"} on the prefix for ~60-80% per-turn input token savings. Non-cache providers get a single concatenated message (zero behavior change)
Prompt cache observability — cache_read_input_tokens and cache_creation_input_tokens tracked through UsageSummary → TurnProfiler → done_payload.cache field. Structured turn_cache log line per turn. Doubles as relay cache-honesty probe
Conversation recovery MVP — Synthetic tool_result rows persist after interrupted turns; POST /chat/resume replays cached SSE events from a monotonic cursor; frontend useSseResume hook auto-reconnects with exponential backoff (300ms → 1s → 3s, max 3 attempts) and “Reconnecting…” indicator
Thinking-block persistence with signature — reasoning_content + Anthropic signature persisted in metadata_["thinking"] and replayed on subsequent turns; fixes HTTP 400 signature mismatch on Claude 4 multi-turn conversations
Provider-aware reasoning replay policy — Centralized reasoning_replay_policy() in core/prompt/reasoning.py gates serialization per provider family: Claude replays thinking blocks with signature; DeepSeek-R1/Qwen-QwQ/Gemini-thinking/o-series drop reasoning_content on outbound (previously leaked, breaking provider KV caches and violating API docs)
Feishu Channel (Phase 1 subset) — Org-scoped Channel resource with Fernet-encrypted credentials; FeishuChannel supports interactive card send + callback (signature verification + URL challenge); Settings → Channels management UI (list, create/edit with dirty-state protection, details with copyable callback URL, test-send); CRUD API (/api/channels) and event callback endpoint (/api/channels/{id}/callback). Shipped early for 2026-04-24 roadshow
Agent Hook System (live in ReAct + DAG runtime) — PreToolUseHook / PostToolUseHook abstraction in src/fim_one/core/hooks/; agents declaring hooks.class_hooks in model_config_json have hooks instantiated and registered per chat session. First consumer FeishuGateHook posts an Approve/Reject card to the linked Feishu group when an agent calls a requires_confirmation=True tool, blocks execution, and resumes or aborts based on verdict
Configurable confirmation gate (inline OR channel) — Every agent gets an Approval section with three routing modes (Auto / Inline only / Channel only), approver-scope selector (initiator / owner / anyone in org), per-tool override, and explicit approval-channel picker. Auto mode gracefully falls back to an inline approval card when no channel is linked. POST /api/confirmations/{id}/respond shares a single decision-recording path with the Feishu webhook
Per-agent task completion notifications — Long-running ReAct or DAG agents can push a summary card to the org’s channel when a task finishes. First consumer of the generic outbound notification pattern
Hook Approval Playground — Channels details sheet has a “Test Approval Flow” action that exercises the full production path (genuine ConfirmationRequest row, real Feishu callback, status transitions) — same code path a production hook uses
Contributor-friendly i18n CI fallback — .github/workflows/i18n-sync.yml translates EN → ZH/JA/KO/DE/FR on master after PR merge and auto-commits with [skip ci]; contributors no longer need LLM_API_KEY locally. Pre-commit locale-edit guard refuses manual edits to generated locale files (ALLOW_LOCALE_EDIT=1 override for legitimate translation fixes). End-to-end verified via smoke-test push
Exa integration docs — Dedicated Integrations section with a first-class Exa page covering the full Exa search surface (neural / fast / deep-reasoning / instant), filtering, content retrieval, and three tuned presets
Xinchuang (信创) database support — Database Connector now lists KingbaseES (人大金仓), HighGo (瀚高), and DM8 (达梦) alongside PostgreSQL/MySQL. PG-compatible drivers reuse asyncpg; DM8 uses dmPython. scripts/test_xinchuang_dbs.py verifies live connectivity from the CLI
Channels + Hook System architecture docs — docs/architecture/hook-system.mdx explains the three hook points and walks through FeishuGateHook end-to-end; existing architecture pages cross-link; README lists Messaging Channels as a first-class capability
Hardening — Duplicate Feishu callback clicks produce a replacement card instead of double-deciding; concurrent callback clicks resolved via conditional UPDATE ... WHERE status='pending' rowcount check; pending approvals auto-expire after CHANNEL_CONFIRMATION_TTL_MINUTES (default 24h) via background sweeper; Settings → Channels respects org role (members see read-only UI); parallel tool-call aggregator handles providers that reuse index=0 for every delta; session-expiry redirect preserves query string
Stripe billing MVP — Free + Pro tiers; Checkout, Customer Portal, webhook lifecycle; /settings?tab=billing; admin plan/subscription CRUD; quota enforcement respects each user’s plan
Admin-controlled billing feature flag — system_settings.billing_enabled gates the entire Stripe pipeline so private deployments without Stripe credentials never surface a non-functional payment UX
Per-user unlimited quota — empty inherits global default, 0 grants unlimited; previously both collapsed into the same state
Translation glossary as single source of truth — scripts/translation-glossary.md consolidates per-locale rules; pre-commit unconditionally refuses manual edits to generated locale files
License + governing law migrated to FIM Labs Pte. Ltd. (Singapore); SIAC arbitration in English; new top-level NOTICE file
Playground follow-up suggestions restored, opt-in per agent
Goal: Production-grade operations + four pillars closing the gap between “instructions the agent might follow” and “guarantees the system enforces” — Trace Layer (see what happened) · Hook System (enforce what must happen) · Agent Workspace (persistent files + handoff) · IM Channel (agents live where users work).
MCP Connection Pooling — pool STDIO with per-user env isolation; share httpx.AsyncClient for SSE/HTTP. Target ≤100 ms warm-start, O(1) HTTP connections per server
Goal: Zero-restart connector addition, Package ecosystem, and embedded delivery.
Connector Progressive Disclosure (Phase 5): Semantic-Guided Tool Selection (entity extraction from query → Ontology Registry lookup → connector set reduction; 90%+ token reduction for 50+ connector deployments); Scale mode for batch/ETL connectors; CLI-style universal connector <name> <action> <params> interface
Cross-Connector Entity Alignment (Ontology Registry): define shared entity types (Customer, Order, Asset) with field mappings across connectors; DAGPlanner auto-resolves cross-system JOIN keys; enables cross-connector queries (e.g., “customers in Salesforce who ordered in Shopify”) without hardcoded field names
Hot-plug connectors: upload OpenAPI spec, AI generates config, live in 5 minutes (no restart)
Marketplace Redesign Phase 1 — Solutions + Components: Two-tier Market model (Solutions: Agent/Skill/Workflow; Components: Connector/MCP Server); scope selector (Global Market / org); unified subscription model (org auto-appear removed); KB removed from Market scope; data migration backfills subscriptions for existing org members
Market Package System: Distributable resource bundles for the Marketplace — replaces per-type “marketplace” with a unified packaging layer. fim-package.yaml manifest declares: metadata (name, version, description, author, license, tags, min_fim_version), entry point (primary Skill or Agent), resource list (agents, skills, connectors, KBs, MCP servers, workflows) with config references, inter-package dependencies (semver ranges), required credentials (mapped to connector refs for install-time collection), and user-configurable variables with defaults. Two consumption modes: (1) install — batch-create all resources + auto-wire internal references via ID substitution; installation linked to source for version update notifications; POST /api/market/packages/{id}/install; (2) fork — clone as user-owned editable copies with no update link (this IS the template mode); POST /api/market/packages/{id}/fork. Additional endpoints: publish (POST /api/market/packages with review workflow), uninstall (DELETE /packages/{id}/uninstall with dependency check + modified-resource confirmation), version history (GET /packages/{id}/versions), upgrade (POST /packages/{id}/upgrade with per-resource diff preview). Dependency resolver for nested package requirements with conflict detection. PackageInstallation table tracks installed packages per user with resource ID mapping for uninstall/upgrade. Coexists with individual resource publishing — Package is a composition layer, not a replacement; a single Connector is still publishable standalone. Example dependency tree: Package: contract-review → Skill: contract-review (entry point) → Agent: contract-analyst + Agent: risk-scorer → KB: legal-clauses + Connector: docusign-api + MCP: pdf-extractor + Workflow: contract-approval-flow
Creator Program: Marketplace monetization layer — creator profiles with portfolio pages, per-package analytics (installs, forks, active users, ratings/reviews), affiliate commission tracking when packages drive new subscriptions. Paid package tier with pricing, purchase flow, and approval workflow. Creator dashboard with install trends, revenue reporting, and user feedback. Public creator API for programmatic package publishing (CI/CD for package authors). Community features: package comments, Q&A, changelogs per version
Embeddable widget: <script src="fim-one.js"> injected into host page
Admin plan management (P4) — admin/billing/{plans,subscriptions} CRUD(shipped in v0.8.6)
Admin-controlled billing feature flag (P5) — system_settings.billing_enabled gates the Stripe pipeline; idempotent activation seeds Free+Pro, sets default plan pointer, backfills users; toggle off/on is pure flag flip after activation(shipped in v0.8.6)
Reconciliation + e2e + go-live (P6) — nightly subscriptions ↔ stripe.Subscription.list() reconcile script for missed-webhook recovery; full-stack happy-path / cancel-mid-period / past-due regression tests; switch from test-mode stripe_price_id to a live price_id; smoke test on staging with a real card.
Team plan (Stripe seats) — Per-seat pricing via stripe.Subscription.quantity, integrated with Organization membership. Lets companies subscribe to one team-wide plan with N seats; quota and feature flags resolve through the seat group rather than the individual user. Builds on the v1.0 Stripe MVP and the existing Organization model.
Group-level token quota for non-billing deployments — Enterprise / private deployments without Stripe configure organization-level token budgets. Quota chain extends to override > group > plan > default; group resolution uses max(user_quota, group_quota) so individual VIPs aren’t constrained by the team cap. Lands alongside the Team plan so the same primitives serve both billed and self-hosted topologies.
Impact: Enterprises deploy FIM One from zero to multi-system orchestration in days. Package system creates a creator ecosystem — solution authors publish composite bundles (Skill + Agents + Connectors + KBs + Workflows), enterprises install with one click, creators earn from adoption. Install/fork duality covers both “use as-is” and “customize from template” use cases in a single mechanism.
Per the Orthogonality Strategy, these features are shipped and working but will not receive new capabilities (bug fixes only):
Feature
Version
Why frozen
ReAct Agent
v0.1, v0.9
Models now have native tool calling. Mid-loop self-reflection (v0.9) prevents goal drift in long chains. Tool observation synthesis quality improved (8K chars, configurable via REACT_TOOL_OBS_TRUNCATION)
DAG Planning / Re-Planning
v0.1, v0.5, v0.7.5
Model reasoning capabilities improving; decomposition becoming single-shot. Per-step verification shipped in v0.7.5 (DAG_STEP_VERIFICATION). Hardened: cascade failure propagation, verifier status fix, planner tool descriptions, full replan history, whitelist-based tool cache. 14 engine constants exposed as ENV vars — no further planning primitives planned
Memory (Window, Summary, Compact)
v0.2, v0.5
Context windows growing (200K+); less need for external memory management
RAG pipeline
v0.5
Providers building retrieval natively (OpenAI file_search, Gemini Search Grounding)
Grounded Generation
v0.5
Models improving at citations; 5-stage pipeline adds diminishing value
Per the Orthogonality Strategy, these would be high-effort and face absorption risk:
Feature
Why deferred
Multi-Agent Orchestration (deep hierarchies)
Providers building natively (OpenAI Swarm, Google A2A, and similar multi-agent offerings). FIM One’s CallAgentTool covers the one-level delegation case; event-triggered background agents are covered by Scheduled Jobs in v0.9
Agent Self-modifying Skills (Procedural Memory)
Agents updating their own skill.md during execution — high complexity, safety/audit surface area. Depends on Agent Skill System (v0.8) shipping first. Re-evaluate if enterprise customers request self-improving agents explicitly
Agent Workspace (Tool Output File Offloading)
Promoted to v0.9. The value is selective reading, not context capacity — cross-framework validation confirmed. Original deferral reasoning (“200K+ windows reduce urgency”) was wrong.
Cross-Session Long-Term Memory
Context windows growing rapidly (200K–2M); providers adding built-in memory (OpenAI memory, Gemini context caching); high implementation cost vs diminishing differentiation value. Re-evaluate when enterprise customers explicitly request it
Memory Lifecycle (TTL, quotas)
Depends on cross-session memory; deferred together
Active Context Compression Tool (agent-triggered)
Explicitly frozen with ContextGuard (v0.5). Context windows at 200K+ reduce value. Will not be revisited unless context costs become a major enterprise complaint
Browser Automation / Computer Use
High maintenance cost (DOM changes, anti-bot, sandboxing). Industry converging on Computer Use mode (Anthropic, OpenAI Operator, Google Mariner) and MCP browser tools (Puppeteer/Playwright MCP). Consume via MCP integration, don’t self-build. Re-evaluate when stable Computer Use MCP standard emerges
Web Push Notifications
Browser-native push via Service Worker + VAPID. Overlaps with IM Channel Integration (v0.8) which covers enterprise-preferred channels (Lark/Slack/WeCom/Email). IM push has higher enterprise value; Web Push is a nice-to-have for Portal-only users. Re-evaluate after IM Channel ships — if users request browser notifications beyond IM coverage
Multi-user workflow collaborative editing
Real-time co-editing of the same workflow blueprint (Figma/Notion style) with cursor awareness, conflict resolution, and per-node lock. High implementation cost (CRDT / OT, presence infra), unclear enterprise demand over today’s “one editor at a time + version diff” model. Re-evaluate if multiple enterprises specifically request shared live editing
Per-node workflow execution permissions (RBAC on run)
Fine-grained authorization inside a single workflow run — e.g. “node X requires role finance_approver to execute”. Today authorization happens at the workflow level (who can trigger) and at the connector level (whose credential runs); per-node RBAC adds a third axis with material complexity and no active customer request
Cross-org workflow sharing with live updates
Subscribe to a workflow from another org and receive upstream updates without re-forking. Today subscribe = fork (snapshot), so breaking upstream changes never propagate. Live updates would require upstream-compatible schema evolution + conflict resolution; high maintenance cost. Re-evaluate if enterprises ask for “shared workflows across subsidiaries”
Marketplace moderation: How to validate community packages and individual resources? Automated scanning for credential leaks in package configs? (v1.0)
Token economics: How to price multi-user, multi-agent scenarios? (v1.0)
Package versioning: Breaking changes in installed packages — auto-upgrade with migration scripts, or manual approval per update? Dependency diamond problem resolution? (v1.0)
Package pricing: Free vs paid tiers, commission rates for Creator Program, payment provider integration? (v1.0)
Package credential UX: Install-time credential collection — wizard-style step-by-step or deferred setup? Credential sharing across packages that use the same connector type? (v1.0)
Telemetry opt-out: How to honor privacy preferences? (v0.8)
Connector versioning: How to manage breaking changes in connector APIs? (v0.8)
Connector authorization tier selection: how does an admin discover which tier applies to a given upstream system? Auto-probe (try per-user API key → fall back to login-ticket → fall back to shared-DB) vs. explicit declaration in the connector spec? How do we express “this connector supports Tier 2 but the admin chose to operate in Tier 1” in the UI without confusing non-technical admins? (v0.9)
Integration vs Connector duality: when a Feishu binding is simultaneously an SSO provider AND an API-call surface, how do we present it in Settings? One object with three toggles, or three separate bindings that share a credential? Implications for uninstall semantics (does revoking SSO kill the Connector?) (v0.9)
