Command Center
Workspace chat that plans typed Confluye Command actions, confirms mutations, and persists jobs.
The Confluye Command Center is the Home chat of a workspace. You ask, in plain language, to query tables, answer from knowledge, compose workflows, or connect tools. Confluye turns that into a typed plan and a durable command job.
Path names still use the legacy identifier fluxus-command (/api/fluxus-command,
/api/v1/fluxus-command/..., Prisma fluxusCommand*). Those strings are compatibility names.
Product copy and error text say Confluye Command.
HTTP contracts: Chat, Confluye Command. File bind/publish: Command artifacts. Global find and inbox: Search and notifications.
The command composer, assistant and files panel follow the active light, dark or system theme, with slate-blue surfaces that match the workspace sidebar. Built-in interface labels and template descriptions follow the selected interface language; your workflow names, messages and other saved content keep their original text. Built-in template previews also translate their step labels and descriptions for display. This does not rename or update the saved workflow nodes, tool identifiers or integration service names. Starting a built-in template also seeds its setup chat in the selected interface language. The standard prompt asks for a walkthrough of the linked workflow; its description remains context, rather than additional instructions to execute. Fixed explanation headings and configuration guidance follow that language, while saved workflow names, node text and configured values remain unchanged. English starter prompts also preserve a Spanish interface preference in the reply, including when you continue with a short answer such as “GMAIL”.
Select Home in the sidebar to open the welcome page and template catalog. Select Command Center to resume the workspace's remembered conversation. An explicit Home selection takes precedence over a saved conversation that finishes loading later.
Home has a centered welcome and a compact composer near the bottom. The workspace name appears in the composer's context strip. Open Files there to upload or select ready files, inspect Artifacts, or review Activity; select Files again to close the panel. Closing it preserves your file selections. The panel expands inside the composer, between the context strip and the message field. The + control attaches other workspace resources. In a conversation, your messages appear in neutral bubbles and assistant replies flow directly on the page. Both use the same reading size, with the composer below the conversation. The workflow preview moves below the conversation on narrower screens; on wide screens it sits beside the chat. Blocks shows readable block cards and their outgoing connections, including branch labels. Select Diagram to zoom, pan and fit the graph without editing its nodes. Use Open workflow after accepting to edit the saved workflow.
Use Copy message to copy an assistant reply; Copied confirms success, and a clipboard error appears beside the action. Your finished replies backed by an agent run also offer Like and Dislike. Feedback saved confirms that your rating was stored; the selection survives a reload, and choosing the other rating updates it. A failed save shows an error and lets you retry. Historical replies without an agent run offer copying only.
When a workflow needs an account connection, the reply shows a separate row for each required service, with its logo and a connection action. Select the service row to start setup, then return to the conversation to continue. Actions such as opening the workflow appear separately below those rows.
Recovering from a provider error
Each submitted request keeps the provider you explicitly selected. If that connection is missing, the chat reports its recovery steps instead of silently switching to another connected account.
A recognized Claude Code or Codex sign-in error names the provider and directs you to Settings → Integrations → Claude Code and Codex. Select Login under that provider, finish browser sign-in, then select Check. Return to the conversation and retry your message. Ask a workspace Admin or Owner if you cannot manage connections. One saved subscription connection serves the workspace's chat and workflow executions across web and worker services; you do not sign in separately on each service.
Rate limits, exhausted usage allowances, timeouts and a busy shared connection have different recovery messages. Follow that message instead of reconnecting an account for every failure. When the cause cannot be identified, the chat asks you to retry and use Check in the provider's settings if it continues. Raw provider output and credentials are not shown.
Workflow proposal preparation also distinguishes an incomplete response, an unavailable block and a plan that could not be connected completely. Your original request is retained for retry. A provider failure does not trigger a second request to repair the workflow's JSON output.
Clarifying questions appear as ordinary chat text. If preparation stops before any changes are made, the chat says so and offers a retry. If actions already ran, check Results and Activity in the conversation before retrying to avoid repeating those changes.
Overview
Use New chat in the sidebar to start a separate conversation. Home and Command Center can resume your last chat; choosing New chat keeps the independent draft selected while chat history finishes loading. On an initial page load, the composer becomes editable once the workspace navigation is ready, so typing does not disappear while the page connects its controls. The mobile workspace menu also becomes available once navigation is ready, so opening it is not interrupted by initial page loading.
The Run a workflow check starter inspects the available workflows and asks the agent to recommend one. Asking which workflow you should run is a read-only question; it does not start an execution. Running or changing a workflow requires a separate confirmed action.
An earlier chat's automatic title does not turn a repeated request into a reference to that chat. To refer to a chat by a title containing action words, quote the title or name its type, for example “Open chat Research and Export”. Separate questions in the same request still need their own answers; listing workflows alone cannot satisfy a question about documents. An introduction such as “in this chat” or “en este chat” keeps the following action words in your request, including when another action follows a comma. To use an action-word title as a source there, quote the title or introduce it with “chat named”.
Type a request in the Home composer. A planner chooses actions from a fixed registry:
- When the plan selects
knowledge.answer, Confluye runs the dedicated RAG path. It searches the bases you selected, or every authorized base when you selected all, and returns citations or an explicit evidence miss. - Other requests use the managed Agent provider or a workspace/personal BYOK provider to produce a typed plan, which Confluye validates before execution.
- If no AI provider is configured, deterministic intent detection still covers common actions (create a table, query a table, export a table) and reports model-dependent work as unavailable.
A general question does not claim that RAG ran unless the plan selected knowledge.answer.
Navigation (resource.open, settings.open) is a separate typed action, so words such as "open"
or "list" cannot divert an already-selected knowledge search.
You can name one source explicitly, for example “Use only the Knowledge Base "Release policy"”. That name must match one authorized base exactly. An unavailable or ambiguous explicit name returns an evidence miss instead of substituting another base. Bases selected in the composer remain the boundary for that lookup. A contextual source such as “According to the Knowledge Base for Release policy” also abstains when that base is unavailable. Use matching quotation marks around names; a double-quoted name can contain an apostrophe, such as “Customer's policies”.
An unquoted restriction such as “Use only the Knowledge Base Release policy” or “Only use the Knowledge Base Release policy” also selects that exact name. Contextual references retain a literal leading article when the complete name is available; for example, “According to the Knowledge Base for The Project Alpha” prefers that base over “Project Alpha”. Quoted names and names following named or called retain leading words such as “The Project”. A general request such as “Search all knowledge bases for OAuth permissions” searches the authorized selection; capitalized search terms alone do not restrict it to a named base, even when a base has the same name as the topic. Quoting the topic, as in “Search all knowledge bases for "OAuth permissions"”, keeps that broad scope. English “Knowledge Base” / “KB” and Spanish “base de conocimientos” use the same source rules. An evidence preface can name the base directly: “According to the Knowledge Base Finance, what is the deadline?” An unavailable direct or Spanish source also returns an evidence miss.
What it can do
Each registry action has a safety class (read, draft, mutating, destructive) and a
requiresConfirmation flag. Read/export/open actions run without a card. Draft and mutating
actions wait on a confirmation card (confirmationId prefix cnf_, TTL 300 seconds).
| Action id | Confirmation | Typical effect |
|---|---|---|
knowledge.answer | No | RAG answer with citations |
table.query | No | In-memory filter, sort, row citations |
table.exportCsv | No | CSV from selected rows/columns |
resource.open | No | Navigate to a resource |
logs.query | No | Real run history for a named workflow |
workflow.explain | No | Explain a workflow without changing it |
settings.open | No | Open a settings section |
table.create | Yes | Create a table |
table.setImage | Yes | Set or clear one record's image |
workflow.createDraft | Yes | Persist a draft workflow |
workflow.compose | Yes | Autopilot graph + optional schedule |
workflow.editWithCopilot | Yes | Copilot graph edits |
workflow.run | Yes | Execute a workflow |
workflow.deploy | Yes | Deploy the current version |
integration.connect | Yes | Start OAuth / setup |
schedule.createCommandJob | Yes | Recurring command prompt |
Table queries use real in-memory filtering (numeric comparators, order, limit) and cite rows.
For an image change, name the table, image column and row number, or an identifying column and value. If a record value is also the table name, use an explicit expression such as where Name is Products in addition to naming the Products table. Attach a ready image. A filename must identify one ready attachment; when filenames repeat, use an explicit file ID or keep only the intended attachment. Choose a specific row and attachment rather than alternatives such as “row 1 or row 2” or "a.png or b.png". Send one image change per Command request, for example "set image Photo to a.png in row 1 of Products". Send subsequent changes in separate requests and review each confirmation. For repeated record writes, use Table Write in a workflow. The selected attachment must match the requested change; unclear associations ask for clarification. Specify one table, one row and one image column for each change. Restate lists of tables, rows or image columns as separate changes before confirming. Use an explicit file ID if its name could be mistaken for part of the instruction. Quote a complete identifying value when it contains spaces. If the record value equals the attachment's filename, select the source separately, for example using file id file_1 and where Name is "a.png". A filename containing a table or column name does not select that destination; name the table and column separately. Review the selected filename and file ID on the confirmation before accepting. If preparation cannot identify one file or record, restate the request before confirming.
Recommendations and complete lists
Command Center distinguishes a recommendation from an exhaustive request. When a recommendation request does not include a number, it supports up to ten options by default and does not pad a shorter result. If you name categories, it keeps those categories in the answer. Words such as all winners or a complete list ask for an exhaustive list, with any known coverage limits stated in the answer. Asking for recommendations across several categories keeps that category scope. For example, a general request for Oscar-winning films covers the Oscar categories you asked about, not only Best Picture. The answer is formatted for the request so categories and supporting details remain easy to scan; it does not promise live web research unless a connected tool is selected and available.
Composing a workflow
The gallery's “Help me set up…” / “Walk me through…” starter asks for a read-only explanation, not creation. For an existing workflow, Confluye inspects that workflow; template guidance alone does not mean a workflow was saved.
Describe what you want to happen. You do not need to name nodes: “Quiero que todos los días a las 8 de la mañana, hora de Nueva York, me mandes por Telegram un resumen de noticias de tecnología” asks the agent to choose and connect the schedule, news retrieval, summary and delivery blocks. Missing accounts appear as connection requirements on the draft rather than preventing its construction. Composing a new workflow from a free-form request requires an available AI provider. If it is unavailable, Confluye preserves the request and asks you to configure a provider or explicitly choose a workflow template. It does not substitute a similar template, add that template's connectors or inherit its schedule.
You can include connection context in the same request, for example “I've connected Gmail; I need an automation that notifies me whenever mail arrives.” An event-driven goal such as “I want Gmail to reply whenever a new email arrives” also asks for a workflow proposal. Connecting the account and accepting that proposal are separate steps; a saved connection alone does not activate a workflow. For example, you can accept a Gmail-to-Telegram draft before either account is connected. Connect the accounts from the draft's pending requirements before running or activating the automation.
Answer the current workflow question with the requested time, name or account choice. You do not need to repeat the workflow goal or start your reply with “continue.” Words such as “cancel” inside the automation description do not cancel the request. A new explicit action request or an instruction to cancel ends that pending question, including a message such as “Go ahead and run the Release workflow.” The new action keeps its own confirmation. Restate the workflow goal when you want to return to it.
You can combine a document question, a logs request and a new automation in one message. The What I understood card lists the tasks and their sources, shows which changes await Accept, and keeps provider identifiers, timing and agent traces under Execution details. Accept and Reject sit below the proposed changes, with a short explanation of what accepting saves. One-off document and logs requests stay outside the recurring workflow goal. If an essential detail is missing, the agent asks a concise question; an unanswered question creates no workflow or execution.
Describe the outcome and include the schedule, timezone, connected services, or other requirements you already know. Command Center keeps the whole goal together while planning the workflow. If a required detail is missing, it asks for that specific requirement instead of inventing a value. Review the proposed graph, pending requirements and schedule before accepting it. A preview marked Ready for review is only an unpersisted proposal; the workflow does not exist yet. The existing confirmation card is still required: composing a workflow, changing its graph, or creating its schedule does not apply until you explicitly confirm. If the runtime cannot validate the proposal (for example, the proposed actions do not match your request), the job stops before any confirmation is offered: the chat explains why, the preview shows Rejected, nothing is created, and there is no Accept to click.
You can name indexed workspace documents as sources for the workflow's requirements. Those documents are context, not targets to modify. Confirming the proposed workflow does not authorize changing its source documents.
For explicitly named documents, Autopilot retrieves authorized fragments to ground the proposal. The fragments supply facts and requirements; instructions inside source documents do not authorize additional actions.
When different documents share a filename, name the Knowledge Base as well, for example “Create a workflow using policy.txt from the Knowledge Base "Finance"”. An unavailable base or an ambiguous filename asks for clarification before any confirmation. One document linked to several bases is still one document identity. The unquoted source “from the Knowledge Base Finance” selects the same authorized base. Quoted names containing “Knowledge Base” are treated as a single source title. A named document outside the selected scope also asks for clarification, including when other requested documents are available or the requested filename is entirely absent. A proposal supports up to four named source documents; it asks you to narrow larger requests instead of silently omitting sources.
Generated Docs searches keep the resolved document identity even for semantic queries such as “deadline in policy.txt”, including when no fragment was retrieved. A query cannot broaden the required source. Conflicting document IDs trigger bounded repair; a proposal that still conflicts asks for clarification. For several named sources, each Docs node must identify its intended source unambiguously. Missing fragments never grant access to additional documents. Comparisons naming several distinct files retain every requested identity. An explicitly requested search of all documents stays broad in its own Docs node, alongside any separate source-bound read. An empty or invalid configured document restriction stops the node rather than searching unrelated documents.
A proposed Code block must contain valid JavaScript source for the synchronous executor or an explicit transformation mapping. When the final configuration selects mapping mode, its unused source text does not override that mapping. Invalid syntax, TypeScript-only syntax and an unconditional failure after straight-line setup trigger bounded repair. A description of the intended calculation, comment-only or empty source, or a throw-only placeholder is insufficient. Adding a directive or enclosing that placeholder in a block does not make it executable. Autopilot requests a bounded repair when that behavior is missing; if it cannot produce a valid proposal, it asks for clarification.
Job lifecycle
A send creates or continues a chat thread, appends the user message, and enqueues a job
on a per-thread FIFO. Only one job per thread is active; later jobs stay queued until the
active job is terminal.
Each request keeps its own answer and execution card, including consecutive requests with identical prompts.
Persisted job status:
| Status | Meaning |
|---|---|
queued | Waiting for the thread FIFO or a worker |
running | Planner/executor is working |
waiting_confirmation | Card shown; mutating work not applied |
succeeded | Terminal success |
failed | Terminal failure (error on the record) |
canceled | Terminal cancel |
blocked | Planning stopped or the confirmation expired; recoverable blocks offer Retry |
While the request runs, the chat shows the current activity and recent stages: checking workspace
context, choosing actions, preparing a knowledge search, preparing log lookups, or connecting a workflow.
These messages describe observed actions, not private model reasoning. Activity is persisted with the
job so polling another web instance or refreshing still shows the worker's latest stage. An agent
planning pass finishing does not mean the job completed; the job's terminal state remains authoritative.
The API-key safe-content projection continues to omit activity text and tool payloads. Confirm, cancel, and retry update the same job family
(retry creates a new id with attempt + 1 and retryOfJobId).
There is no HTTP token stream for Command. Clients poll
GET /api/fluxus-command/jobs/{id} (session) or GET /api/v1/fluxus-command/jobs/{id} (API key).
Confirmation card lifecycle
- Accept / Confirm disables both buttons while the request is in flight, so a double click cannot burn the single-use confirmation.
- The card shows Expires in m:ss. Confirmations last 300 seconds. The countdown is a display of the server's deadline, not the decision: when it reaches zero the card asks the server whether the confirmation is still open and shows a short "checking with the server" note. Expired appears once the server itself settles the confirmation, the job settles into a recoverable block on that poll (or on the worker's periodic sweep), the chat message explains what happened, and Retry asks for a fresh proposal. Because the server's clock decides, a device whose clock is fast will not retire a confirmation the server still accepts, and one whose clock is slow will not keep an already-closed confirmation actionable.
- If the network drops or the server answers with a 5xx while confirming, the client does not send a second Confirm automatically. It checks the current job status without resending. If that status confirms the action was accepted, the card updates normally. Otherwise it shows the current outcome or a recovery alert. An uncertain response alone does not mark the job Failed.
- If an unexpected confirmation error occurs, the button is released and a visible recoverable alert appears so you can check status and decide next steps.
- If the confirmed execution fails, the chat refreshes to the failed job and the preview panel shows Failed; the
error banner carries the server
errorCode(for examplemfa_required).
Run history from chat
Ask about executions in plain language ("¿Por qué falló la última ejecución de Resumen diario?", "How did the last
runs of Weekly digest go?"). logs.query reads the workspace's real run history, filters by the workflow you name
and by a status implied by the question (failed, succeeded, running), and answers in your language with one citation
per run plus the Open Logs chip. Run citations are intended to open the corresponding run detail in Logs,
including after you reload the chat; document citations still open their document. This citation behavior is the
implemented contract pending a new deployment. When several workflows match the name, it asks which one
you meant; when the workflow has no runs, it says so instead of quoting a workspace-wide count.
A workflow you name explicitly, in quotes ("…", “…”, «…») or after named / called / llamado, is resolved
only by its exact name or id against the whole workspace, even when the chat context did not list it. If no workflow has
that name, the answer says so and cites no runs when the request is unambiguous; when a safe token collision blocks
binding, the chat asks for clarification instead of substituting another workflow whose name appears inside yours, or
the workspace-wide history. Quote the full name when it has several words; an unquoted partial name is reported as not
found rather than guessed. A trailing time or status phrase is not read as part of an unquoted name, so
"runs for workflow called Billing Sync from yesterday" resolves the workflow Billing Sync; inside quotes every word
belongs to the name.
A question can also scope the read in time, and the two shapes mean different things. Calendar expressions —
today/hoy, yesterday/ayer and an exact ISO date such as 2026-09-10 — cover that whole local day, from
midnight to midnight in your workspace time zone, so a day that a daylight-saving change makes 23 or 25 hours long is
still one whole day. Rolling expressions — last N hours/last N days (últimas N horas, últimos N días) and
last hour/última hora — cover exactly that much elapsed time counted back from now and end at now, never at a
midnight, so they never reach into the future. The answer states the range it used. Anything else
that reads as a time expression — last week, since Monday, 3 days ago, an ambiguous numeric date like 9/10, a
part of a day like last night, or two different windows in one question — is not guessed: the chat says which
expression it could not pin down and offers the forms it accepts, rather than answering with unfiltered runs. A
question with no time wording behaves exactly as before.
Workflow Autopilot
Ask for a workflow from a goal. The primary action is workflow.compose.
- 1
Describe the outcome
Include timing if it should run on a schedule.
- 2
Review the proposed graph
Autopilot validates nodes and connections and shows the graph diff. Scheduled proposals include a typed
Schedule:line (cron + timezone). - 3
Accept or reject
Accept persists the validated workflow and schedule, then the preview changes to Created. You can use its Open workflow button or the success message's Open <workflow> action to open the persisted canvas. Reject / cancel leaves neither. A proposal the runtime could not validate also shows Rejected and creates nothing; it never offers Accept.
Scheduled commands
A command job schedule stores title, prompt, cron, timezone, enabled flag, and optional
threadId. Due processing uses the same machinery as Scheduled Tasks
(processDueFluxusCommandSchedules, claim on nextRunAt, limit 1–100, default 25). Each fire
re-sends the stored prompt through sendWorkspaceChatMessage (creates a thread if needed).
HTTP: GET/POST /api/fluxus-command/schedules (session) and
/api/v1/fluxus-command/schedules (bearer). There is no HTTP PATCH/DELETE for command
schedules; update/delete exist only on the service.
Surfaces that send work
| Surface | Creates thread + user message | Enqueues job | Idempotency |
|---|---|---|---|
POST /api/chat | Yes | Yes | Required Idempotency-Key |
POST /api/v1/chat | Yes | Yes | Required; workspace key |
POST /api/fluxus-command | Yes | Yes | Not required |
POST /api/v1/fluxus-command/jobs | No (existing threadId) | Yes | Required; workspace key; 202 |
v1 job create does not append the user chat line. Use Chat if you need the transcript.
Gaps
- Session Command POST has no attachment field and no idempotency; Chat does (max 10 file ids).
- v1 jobs have no
retryroute; sessionPOST .../jobs/{id}/retryreturns202. - v1 schedules do not use the
api-contracts.v1envelope and do not require a workspace-scoped key (any valid bearer is enough). - Job
blockedis on the type and cancel path; planners documented here complete towaiting_confirmation/ terminal statuses. - Progress live events exist only on the instance that ran the worker.
Reading responses
Responses preserve Markdown paragraphs, lists, code and tables. Wide tables scroll inside the message so they remain usable on narrow screens. Copy message keeps the original Markdown text.
Recovering an interrupted request
If the agent stops before finishing a request, the conversation reports that stop instead of claiming the plan completed. Review any completed steps before deciding how to continue. A workflow proposal that fails preparation does not become a pending mutation; a later valid proposal still needs your confirmation.
