Command Center

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.

Overview

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.

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

Table queries use real in-memory filtering (numeric comparators, order, limit) and cite rows.

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. Explicitly ask to create a workflow when you want a proposal.

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.

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.

Persisted job status:

The execution card progress state is derived from the job when the in-process Agent event buffer is missing (other web instance, refresh): queued, working, awaiting_confirmation, succeeded, failed, canceled. 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 example mfa_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. 1

   Describe the outcome

   Include timing if it should run on a schedule.

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

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 retry route; session POST .../jobs/{id}/retry returns 202.
• v1 schedules do not use the api-contracts.v1 envelope and do not require a workspace-scoped key (any valid bearer is enough).
• Job blocked is on the type and cancel path; planners documented here complete to waiting_confirmation / terminal statuses.
• Progress live events exist only on the instance that ran the worker.

Next steps