diff --git a/AGENTS.md b/AGENTS.md index 4d8593a..ff05869 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -12,15 +12,14 @@ The navigation keeps Home first, then sorts the top-level sections and the pages inside each section alphabetically: -- **Administration** - `/admin-panel`. Browser-admin access, dashboards, governance records, runtime controls, and network policy. -- **Agents (Beta)** - `/developers/*`. Guides cover Agent setup, threads, context, projects, schedules, preferences, and webhooks. Architecture and the REST API reference live here too, with API pages under `/developers/api-ref/*`. +- **Administration** - `/admin-panel`. Browser-admin access, account and runtime dashboards, sponsorship, and network policy. +- **Agents (Beta)** - `/developers/*`. Guides cover Agent setup, configuration and sharing, manual testing, threads, context, projects, schedules, preferences, and current webhook availability. Architecture and the REST API reference live here too, with API pages under `/developers/api-ref/*`. - **App setup** - `/integrations/{github, gmail, google-calendar, slack}`. Per-app permissions and prompts, not feature pages. All of them connect through the Apps tab of the Add MCP dialog. - **Deployment models** - `/deployment-models`. Current availability and operating boundaries for Fluso Cloud, dedicated AWS VPC, planned Azure VNet, and scoped on-premises deployments. - **Features** - `/features/*`. Approvals and permissions, Apps and MCP servers, Chat, Confidential mode, Imports, Memory, Projects, Skills, and Tasks. - **Get started** - `/going-deeper`, `/introduction`, `/quickstart`. These pages explain the path from first setup to daily use. - **Reference** - `/resources/{faq, legal, pricing}`. Legal links to the terms of service at `https://fluso.ai/terms` and privacy policy at `https://fluso.ai/privacy`; do not duplicate the policies in the docs. - **Release notes** - `/release-notes`. Customer-facing changes, newest first. -- **Remote access** - `/remote/*`. Ways to use Fluso away from the desktop app. - **Workflows** - `/workflows/*`. Six concrete stories: bug-to-PR, content launch, knowledge recall, meetings, morning brief, and research-to-deck. The home page (`/`) is a router into the journey, with three sections: just landed, already set up, daily user. diff --git a/components/diagrams.tsx b/components/diagrams.tsx index 2730caf..b38e266 100644 --- a/components/diagrams.tsx +++ b/components/diagrams.tsx @@ -76,7 +76,7 @@ export function MemoryScopeDiagram() { > @@ -91,7 +91,7 @@ export function MemoryScopeDiagram() { id="memory-scope-caption" className="mt-4 text-center text-xs leading-relaxed text-fd-muted-foreground" > - Global preferences apply everywhere. Project context and working memory + Ordinary chats use global preferences. Project context and working memory stay inside their project. @@ -212,7 +212,7 @@ export function KnowledgeGraphDiagram() { const architectureServices = [ { label: 'Fluso client', - detail: 'Desktop or remote', + detail: 'Desktop or mobile', x: 10, icon: MessageSquareText, }, diff --git a/content/docs/admin-panel.mdx b/content/docs/admin-panel.mdx index 63ab80e..443f2fb 100644 --- a/content/docs/admin-panel.mdx +++ b/content/docs/admin-panel.mdx @@ -2,91 +2,64 @@ title: Admin panel sidebarTitle: Admin panel icon: shield-user -description: Review users, runtimes, recorded model usage, identity and access changes, and network policy from Fluso Admin. +description: Inspect accounts, runtimes, recorded usage, sponsorship, and network policy in Fluso Admin. --- -Fluso Admin is a separate browser interface for authorized operators. It shows account, runtime, usage, and governance records without exposing the content of members' work. +Fluso Admin is a separate browser interface for authorized operators. A personal Pro or Confidential subscription does not grant administrator access. - - Your organization provides its Fluso Admin address and assigns the panel - role. This is separate from the organization role recorded under **Teams & - access**. - +Your deployment operator provides the address and assigns a **Read-only** or **Read & write admin** role. The backend checks that role on each admin request. ## Access roles -The backend checks the administrator role on every request. - | Role | Access | -| --- | --- | -| Read-only | View dashboards, users, runtimes, usage, access records, and network policy. Export available reports. | -| Read and write | All read-only access, plus runtime controls, plan sponsorship, team and Agent access changes, and network policy changes. | - -The **Admin** organization role does not grant access to Fluso Admin. Panel access uses the separate read-only or read-and-write role assigned by the operator of your deployment. - -## View scope - -**Overview** and **Users** cover the configured sign-in instance. **Teams & access** and **Audit log** show one target account and default to the signed-in administrator. To inspect another account, open it from **Users**, then choose **Manage access** or **Audit trail**. - -## Admin views +|---|---| +| Read-only | Inspect dashboards, users, runtimes, recorded usage, sponsorship, and network policy | +| Read and write | The same views, plus runtime controls, sponsorship changes, and network-policy changes | -| View | What it shows or controls | -| --- | --- | -| **Overview** | Instance-wide identity activity, runtime health, recorded model usage, plan distribution, and users with the highest recorded cost. | -| **Users** | An instance-wide, searchable user list. Open a user to review their plan, runtime state, usage, and aggregate storage. Read-and-write administrators can control the runtime and grant or extend Sponsored Confidential. | -| **Runtime fleet** | A cached or refreshed snapshot of running, starting, stopped, failed, unknown, mapped, and unmapped runtimes. Click **Refresh fleet** to reconcile the snapshot before investigating availability. | -| **LLM costs** | Global cost and token totals from the gateway usage ledger for 30, 90, 180, or 365 days. It does not show prompts, sessions, or model-level detail. | -| **Observability** | SLA and SLO configuration state, current runtime status coverage and failures, runtime distribution, and recorded cost and token usage for the last 14 days. **Refresh health** updates the fleet snapshot. Run completion, response latency, evaluation, and policy metrics remain unavailable until those sources are recorded. | -| **Audit log** | The latest 100 identity and access events for the target account. Filter by user, action type, or date, then export the current rows as CSV. | -| **Teams & access** | Microsoft Entra tenant metadata, members, organization roles, teams, access requests, and Agent access records for the target account. The metadata record does not verify or import a directory by itself. | -| **Network egress** | Platform-wide origin and provider bundles for egress-governed sandboxes. These controls do not currently have a per-organization boundary. | +## Current views -## Audit log +| View | What it shows | +|---|---| +| **Overview** | Identity activity, runtime health, plan distribution, recorded usage, and highest-cost users | +| **Users** | Searchable accounts with plan, sponsorship, runtime state, storage, and recorded usage | +| **Runtime fleet** | Runtime status and mapped or unmapped instances; **Refresh fleet** reconciles the snapshot | +| **LLM costs** | Recorded gateway cost and token totals for 30, 90, 180, or 365 days | +| **Network egress** | Origin and provider rules for egress-governed runtimes | -Each governance event records the actor, action, target, detail, and time. Current action types cover Microsoft Entra metadata, tenant configuration, teams, roles, access requests, and Agent access records. - -This is not an Agent activity trace or a complete record of Admin mutations. It does not show tool calls, logins, prompts, document edits, messages, files, knowledge graphs, runtime controls, Sponsored Confidential changes, or network-policy changes. Use an Agent's **Analytics** page for its recorded runs. +These views do not expose users' messages, project files, or knowledge content. Usage totals describe recorded entries; unavailable data is not evidence of zero usage. ## Runtime and user controls -Open **Users**, select a person, then review the runtime card. A read-and-write administrator can start, stop, or restart the runtime. Stop and restart are blocked during active work, warm-up, active schedules, or an unhealthy state; there is no force-stop control. +Open **Users** and select an account. A read-and-write administrator can start, stop, or restart its runtime when the control is available. Active work, warm-up, schedules, or an unhealthy state can block a control. There is no force-stop action. -The same user page shows aggregate storage. It does not open or delete the user's stored content. +The storage card reports aggregate usage and limits. It does not open or delete the user's files. -Sponsored Confidential changes entitlement for up to 24 months. They do not change the person's Clerk billing subscription. +The sponsorship form can grant or extend **Sponsored Confidential**, with an expiry up to 24 months away. Sponsorship changes access, not the person's Clerk subscription or billing schedule. ## Network egress -Use **Network egress** to review the origins available to egress-governed sandboxes. A read-and-write administrator can create, edit, or delete provider bundles and delete existing Shared rules. The current panel does not add or edit a standalone Shared rule. +A read-and-write administrator can create, edit, or delete provider bundles and delete existing Shared rules. The current panel does not add or edit standalone Shared rules. - A change here applies to every egress-governed user. **Ask** requests user - approval and saves the user's Allow or Deny choice. A global **Deny** gives no - prompt and cannot be overridden. Disabling or deleting a bundle removes only - rules created by that bundle; other global rules and user grants remain. + These controls apply across egress-governed users, rather than to one organization. A global Deny blocks the origin without an approval prompt. Disabling or deleting a bundle removes its own rules; other global rules and user grants remain. +## Enterprise administration + +The current panel does not provide the previously described **Teams & access**, **Audit log**, or **Observability** pages, Microsoft Entra setup, or their CSV export controls. Scope identity integrations, organization-wide audit requirements, and monitoring exports with the deployment team. See [Deployment models](/deployment-models). + ## Troubleshooting - - Sign in with the account your deployment operator authorized. An - organization role does not grant panel access. Ask the deployment operator - or [contact Fluso support](mailto:support@premai.io) if the panel role is - missing. + + Use the address and account authorized by your deployment operator. A personal subscription or ordinary organization membership does not grant panel access. - - The panel distinguishes recorded data from missing telemetry. Retry the - view. If it remains unavailable, check the source service rather than - treating the empty value as zero. + + Retry the view. If it stays unavailable, contact the deployment operator with the failing page and time. Do not interpret a failed request as an empty account or zero usage. - Check whether the runtime is busy, warming, unhealthy, already stopped, or - has active schedules or other durable work. Retry after the blocking state - clears. Fluso does not force-stop a runtime from this panel. + Check its current state and ongoing work. Retry after the blocking condition clears; the panel does not force-stop active work. -## Next - -See [Legal](/resources/legal) for Fluso's privacy policy. +See [Legal](/resources/legal) for Fluso's terms and privacy policy. diff --git a/content/docs/deployment-models.mdx b/content/docs/deployment-models.mdx index 26f67ce..314f6df 100644 --- a/content/docs/deployment-models.mdx +++ b/content/docs/deployment-models.mdx @@ -50,11 +50,11 @@ Agree on these boundaries before treating the design as approved: ## Operational telemetry -AWS deployments send service logs to CloudWatch and define CloudWatch alarms. Fluso's knowledge service emits structured logs and can export traces and metrics through OpenTelemetry (OTLP). The current AWS collector routes traces to X-Ray and metrics to CloudWatch; Prometheus scraping is optional. +Telemetry depends on the deployed services and collector configuration. AWS deployments can use CloudWatch for logs and alarms. Services may also support OpenTelemetry collectors; agree on enabled exporters and destinations for each deployment. Traces can include prompt and response text. For a dedicated or on-premises deployment, agree which signals are captured, where they are stored, how long they are retained, and which customer-owned collectors are supported. -[Fluso Admin](/admin-panel) shows the product records it receives, including runtime health, recorded cost and token usage, and governance events. It does not replace infrastructure monitoring or promise export of every operational signal. +[Fluso Admin](/admin-panel) shows the product records it receives, including runtime health, recorded model usage and costs, and network-egress events. It does not replace infrastructure monitoring or promise export of every operational signal. ## Choose a model diff --git a/content/docs/developers/agent-builder.mdx b/content/docs/developers/agent-builder.mdx index 879e42d..7a7c4b1 100644 --- a/content/docs/developers/agent-builder.mdx +++ b/content/docs/developers/agent-builder.mdx @@ -2,39 +2,45 @@ title: Agent builder sidebarTitle: Agent builder icon: workflow -description: Turn a plain-language request into an Agent draft, then review or refine it before saving. +description: Create and refine a saved Agent through a conversation or a form. --- -Open **Control Panel → Create Agent** to start in Agent Studio. Describe the job in plain language. Studio drafts the Agent definition and a small workflow preview before anything is saved. + + Agents is a beta workspace. Availability depends on the app's release and beta configuration. Buying Pro does not by itself enable Agents or add a Control Panel. + -> *"Create a customer escalation coordinator. Gather the customer, impact, urgency, and open questions. Read relevant Gmail and Google Drive context, classify the case as P0 or P1, prepare the next steps, and require approval before sending anything."* +Open **Agents → New Agent**. Describe the job to the Agent manager: -## Build the first draft +> *"Create a customer escalation coordinator. Gather the customer, impact, urgency, and open questions. Read the connected support sources, classify the case as P0 or P1, and prepare the next steps. Ask for approval before sending anything."* -A useful request names four things: +The manager can create and modify saved Agents during the conversation. Review what it creates before using it for live work. -- The input, such as a support request or release candidate. -- The outcome, such as a severity decision or handoff package. -- The sources and capabilities the Agent may use. -- The boundaries that must hold, such as approval before an external action. +## Describe the job -Select **Build**. Studio returns the Agent name, description, instructions, and a short graph of the proposed steps. The graph is a design preview. It helps you check the order and decision points, but it is not executable code. +Name the input and expected result, the sources the Agent may use, and the boundaries it must respect. Keep credentials out of the instructions; connect Apps through **Plugins → MCP**. -## Refine without starting over +For example, refine the Agent with: -Use the Studio message box to change the draft: +> *"Use P0 for a complete outage and P1 for degraded service with a workaround. Prepare customer replies as drafts for review."* -> *"Only use P0 and P1. Run the Gmail and Drive lookups in parallel. Stop for approval before sending a customer reply."* +## Use the form -Studio revises the current draft and replaces the workflow preview. If a request fails, the last valid preview stays in place so you can retry. +Choose **Fill in a form instead** when creating an Agent, or open **Edit** from an existing Agent's details. -## Create or open the editor +- **Name** is the label shown in the workspace. +- **Purpose and instructions** describe the result, sources, and standing rules. +- Choose the project, response mode, skills, and Apps the Agent can use. +- Add knowledge files for stable reference material. +- Select **Create Agent** or **Save changes**. -- Select **Create Agent** when the draft is ready. -- Select **Go to editor** when you want to inspect every field, capability, knowledge file, or thread setting first. +The form accepts up to 25 knowledge files, with a 20 MiB limit per file. Review the selected capabilities and [approval settings](/features/approvals) before allowing external changes. -Studio only selects capabilities already available to you. Creating the Agent saves the definition. Existing Agent threads keep the definition they started with, so test changes in a new thread. +## Refine an existing Agent + +Choose **Modify** in the Agent menu to return to the manager. Use **Edit** to change the fields directly. + +The main conversation uses the updated configuration on its next turn. A running turn finishes with its accepted configuration, and existing delegated sessions keep theirs. See [Threads and contexts](/developers/threads-and-contexts). ## Next -See [Agent description](/developers/agent-description) for field boundaries and [Threads and contexts](/developers/threads-and-contexts) for what a new Agent thread receives. +See [Agent description](/developers/agent-description) for writing instructions and [Testing Agents](/developers/evaluations) for a manual review loop. diff --git a/content/docs/developers/agent-description.mdx b/content/docs/developers/agent-description.mdx index c2aa449..268cd73 100644 --- a/content/docs/developers/agent-description.mdx +++ b/content/docs/developers/agent-description.mdx @@ -2,34 +2,26 @@ title: Agent description sidebarTitle: Agent description icon: file-text -description: Write a clear Agent summary and keep it separate from the goal and standing instructions. +description: Write an Agent's purpose and standing instructions in one field. --- -The description is the short answer to "What does this Agent do?" It appears in Agent lists and search, and it becomes part of the saved Agent definition when a thread starts. - -Keep it to one sentence. Name the responsibility, input, and output when they fit. - -> *"Triages customer escalations and prepares an approval-ready response plan."* - -## Description, goal, and instructions - -These fields have different jobs: +An Agent has a **Name** and **Purpose and instructions**. The first line of its instructions provides the short purpose shown in lists. Put the intended result first, then the rules and sources it should use. | Field | Use it for | Example | | --- | --- | --- | | Name | A short label you can find quickly | Customer escalation coordinator | -| Description | What the Agent is responsible for | Triages customer escalations and prepares a response plan. | -| Goal | The result that marks success | Return a severity, owner, and next-step package. | -| Instructions | Rules, sources, order, and approval boundaries | Check Gmail and Drive. Require approval before any external send. | +| Purpose and instructions | Responsibility, expected result, sources, and approval boundaries | Triage customer escalations and prepare a response plan. Classify complete outages as P0. Cite the runbook. Draft external messages for review. | + +There are no separate Description or Goal fields in the current editor or create/update API. Integrations should send `instructions`; see [Agents and versions](/developers/api-ref/agents-and-versions). -Do not put the full workflow in the description. Long rules are harder to scan there and belong in **Instructions**. +## When changes apply -## Changes apply to new threads +Saving an edit changes the configuration used by the main Agent conversation on its next turn. Work already running keeps its accepted configuration. Delegated sessions keep the configuration they received when created. -An Agent thread keeps the saved definition it started with. Changing the description, goal, instructions, project, capabilities, or knowledge files creates a new definition for future threads. It does not rewrite an existing conversation. +Conversation history is preserved, so an edited Agent can still see earlier discussion. For a separate test conversation, duplicate the Agent and review its project and capabilities before testing. -Start a new thread after an edit when you need to verify the new behavior. +Changing the configured project does not move files or existing conversations. See [Project context](/developers/project-context). ## Next -Build the first draft in [Agent builder](/developers/agent-builder), or update these fields through [Agents and versions](/developers/api-ref/agents-and-versions). +Create the Agent through [Agent builder](/developers/agent-builder), then review its [threads and context](/developers/threads-and-contexts). diff --git a/content/docs/developers/api-ref/agents-and-versions.mdx b/content/docs/developers/api-ref/agents-and-versions.mdx index 212f201..c575139 100644 --- a/content/docs/developers/api-ref/agents-and-versions.mdx +++ b/content/docs/developers/api-ref/agents-and-versions.mdx @@ -7,9 +7,9 @@ description: Create Agents, read their current immutable configuration, and publ An Agent record points at one immutable configuration through `currentConfigId`. Use that ID as `baseConfigId` when you update the Agent. -For the product flow, including reviewing changes and rolling back safely, see [Versions](/developers/versions). +For editing, copies, and public links, see [Configuration and sharing](/developers/versions). Current configuration responses use `schemaVersion: 2`. -Agent-owned work runs in [threads](/developers/api-ref/threads-and-messages) and can start from [schedules](/developers/api-ref/schedules) or [webhooks](/developers/webhooks). +Agent-owned work runs in [threads](/developers/api-ref/threads-and-messages) and can start from [schedules](/developers/api-ref/schedules). Agents is a beta workspace; access also depends on the deployment configuration. See [Webhooks](/developers/webhooks) for the current event-integration boundary. ## List Agents @@ -29,7 +29,7 @@ curl "$FLUSO_API/v1/agents?page=1&limit=20&q=release" \ "agentId": "agt_0123456789ab4def8123456789abcdef", "currentConfigId": "cfg_11111111111141118111111111111111", "name": "Release reviewer", - "description": "Reviews release candidates", + "purpose": "Reviews release candidates", "projectName": "Release Review", "responseMode": "high", "createdAt": "2026-08-31T09:00:00Z", @@ -59,9 +59,7 @@ curl "$FLUSO_API/v1/agents" \ -H 'Content-Type: application/json' \ -d '{ "name": "Release reviewer", - "description": "Reviews release candidates", - "goal": "Return a go or no-go decision", - "instructions": "Cite blockers and name each follow-up owner.", + "instructions": "Reviews release candidates. Return a go or no-go decision, cite blockers, and name each follow-up owner.", "conversationStarters": ["Review this candidate"], "responseMode": "high", "projectName": "Release Review" @@ -78,18 +76,14 @@ curl "$FLUSO_API/v1/agents" \ "lastChatAt": null, "chatCount": 0, "config": { - "schemaVersion": 1, + "schemaVersion": 2, "configId": "cfg_11111111111141118111111111111111", "agentId": "agt_0123456789ab4def8123456789abcdef", "name": "Release reviewer", "normalizedName": "release reviewer", - "description": "Reviews release candidates", - "goal": "Return a go or no-go decision", - "instructions": "Cite blockers and name each follow-up owner.", + "instructions": "Reviews release candidates. Return a go or no-go decision, cite blockers, and name each follow-up owner.", "conversationStarters": ["Review this candidate"], "responseMode": "high", - "threadManagementEnabled": true, - "threadCreationMode": "explicit", "projectName": "Release Review", "knowledgeFiles": [], "skills": null, @@ -117,10 +111,10 @@ curl "$FLUSO_API/v1/agents/agt_0123456789ab4def8123456789abcdef" \ "currentConfigId": "cfg_11111111111141118111111111111111", "state": "active", "config": { - "schemaVersion": 1, + "schemaVersion": 2, "configId": "cfg_11111111111141118111111111111111", "name": "Release reviewer", - "goal": "Return a go or no-go decision" + "instructions": "Reviews release candidates. Return a go or no-go decision, cite blockers, and name each follow-up owner." } } ``` @@ -138,7 +132,7 @@ curl "$FLUSO_API/v1/agents/agt_0123456789ab4def8123456789abcdef" \ -H 'Content-Type: application/json' \ -d '{ "baseConfigId": "cfg_11111111111141118111111111111111", - "goal": "Return a go or no-go decision with named owners" + "instructions": "Review release candidates. Return a go or no-go decision with named owners and evidence for each blocker." }' ``` @@ -148,53 +142,36 @@ curl "$FLUSO_API/v1/agents/agt_0123456789ab4def8123456789abcdef" \ "currentConfigId": "cfg_22222222222242228222222222222222", "state": "active", "config": { - "schemaVersion": 1, + "schemaVersion": 2, "configId": "cfg_22222222222242228222222222222222", - "goal": "Return a go or no-go decision with named owners" + "instructions": "Review release candidates. Return a go or no-go decision with named owners and evidence for each blocker." } } ``` An unchanged patch returns the existing config ID. A stale `baseConfigId` returns `409 STALE_AGENT_CONFIG` and includes the current config ID in `error.details.currentConfigId`. -## List available configurations +## Configuration lifetime - +The current API exposes the current configuration through `GET /v1/agents/{agentId}`. There is no `/versions` listing endpoint in this release. Keep copies of editable fields in your own system if you need a revision history. -Returns up to 100 available immutable configurations, newest first. Older -configurations that no chat uses may be reclaimed under storage pressure, so -this endpoint is not a permanent audit ledger. +The main Agent conversation adopts the current configuration on its next turn. A turn already running keeps its accepted configuration, and existing delegated sessions retain their original configuration. Editing `projectName` does not move existing conversations or their files. -```bash title="Request" -curl "$FLUSO_API/v1/agents/agt_0123456789ab4def8123456789abcdef/versions" \ - -H "Authorization: Bearer $FLUSO_TOKEN" -``` +## Editable fields -```json title="Response: 200, selected fields" -{ - "versions": [ - { - "schemaVersion": 1, - "configId": "cfg_22222222222242228222222222222222", - "agentId": "agt_0123456789ab4def8123456789abcdef", - "goal": "Return a go or no-go decision with named owners", - "createdAt": "2026-08-31T10:00:00Z", - "contentDigest": "abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789" - } - ] -} -``` +Create accepts `name`, `instructions`, `conversationStarters`, `responseMode`, `projectName`, `skills`, and `connectors`, plus an optional UUID `creationId` for creation retries. Update requires `baseConfigId` and accepts the editable fields; attached `knowledgeFiles` are update-only. -To restore an available configuration, send its editable fields through the -normal update endpoint and use the Agent's current `currentConfigId` as -`baseConfigId`. The update creates a new immutable configuration. Existing -chats keep the configuration they started with. +- `responseMode` is `high` or `fast`. +- `skills: null` leaves skills unrestricted by the Agent; `skills: []` selects none. +- `connectors: null` leaves connections unrestricted by the Agent; `{}` selects none. Entries map MCP server IDs to `allow`, `read_only`, or `deny`. +- The Agent's selections do not grant new App access or bypass account permissions. +- Legacy `description`, `goal`, `threadManagementEnabled`, and `threadCreationMode` inputs are rejected. ## Delete an Agent -Deletes the Agent and removes its owned chats, configurations, knowledge, schedules, and webhook triggers. +Deletes the Agent and its owned chats, configurations, knowledge, and schedules. This also removes its active share links. ```bash title="Request" curl "$FLUSO_API/v1/agents/agt_0123456789ab4def8123456789abcdef" \ @@ -208,4 +185,4 @@ HTTP/1.1 204 No Content ## Next -Start Agent work through [Threads and messages](/developers/api-ref/threads-and-messages), or automate it with [Schedules](/developers/api-ref/schedules) and [Webhooks](/developers/webhooks). +Start Agent work through [Threads and messages](/developers/api-ref/threads-and-messages), or automate it with [Schedules](/developers/api-ref/schedules). diff --git a/content/docs/developers/api-ref/authentication.mdx b/content/docs/developers/api-ref/authentication.mdx index eb0e118..c1c642d 100644 --- a/content/docs/developers/api-ref/authentication.mdx +++ b/content/docs/developers/api-ref/authentication.mdx @@ -20,7 +20,7 @@ Send that token on every authenticated request: Authorization: Bearer $FLUSO_TOKEN ``` -Keep access and refresh tokens out of source control. The examples below use placeholders and environment variables. +`api_key_id` identifies the runtime key; it is not a credential you can use in place of the bearer token. Keep access and refresh tokens out of source control. The examples below use placeholders and environment variables. Once authenticated, start with [Agents and versions](/developers/api-ref/agents-and-versions). @@ -68,7 +68,7 @@ curl "$FLUSO_API/v1/auth/client/exchange/$FLUSO_CODE?client=cli&client_user_id=d "access_token": "", "refresh_token": "", "expires_in": 86400, - "aci_api_key": "", + "api_key_id": "33333333-3333-4333-8333-333333333333", "user": { "id": "22222222-2222-4222-8222-222222222222", "email": "developer@example.com", @@ -97,7 +97,7 @@ curl "$FLUSO_API/v1/auth/client/refresh" \ "access_token": "", "refresh_token": "", "expires_in": 86400, - "aci_api_key": "" + "api_key_id": "33333333-3333-4333-8333-333333333333" } ``` @@ -105,7 +105,7 @@ curl "$FLUSO_API/v1/auth/client/refresh" \ -Returns the user attached to the bearer token and their runtime API key. +Returns the user attached to the bearer token and the identifier of their runtime API key. The key itself is not returned. ```bash title="Request" curl "$FLUSO_API/v1/auth/me" \ @@ -121,7 +121,7 @@ curl "$FLUSO_API/v1/auth/me" \ "picture": null, "created_at": "2026-08-31T09:00:00" }, - "aci_api_key": "" + "api_key_id": "33333333-3333-4333-8333-333333333333" } ``` diff --git a/content/docs/developers/api-ref/schedules.mdx b/content/docs/developers/api-ref/schedules.mdx index 4ee3bd6..4c3c338 100644 --- a/content/docs/developers/api-ref/schedules.mdx +++ b/content/docs/developers/api-ref/schedules.mdx @@ -64,7 +64,7 @@ curl "$FLUSO_API/v1/agents/agt_0123456789ab4def8123456789abcdef/schedules" \ }' ``` -For a durable one-time schedule, replace `cron` with an offset-bearing `at` value: +For a durable one-time schedule, replace `cron` with an offset-bearing `at` value. Choose a future timestamp; this example date is illustrative: ```json title="One-time timing fields" { diff --git a/content/docs/developers/api-ref/threads-and-messages.mdx b/content/docs/developers/api-ref/threads-and-messages.mdx index 8eeb577..3f5cbbc 100644 --- a/content/docs/developers/api-ref/threads-and-messages.mdx +++ b/content/docs/developers/api-ref/threads-and-messages.mdx @@ -122,7 +122,9 @@ curl "$FLUSO_API/v1/threads/thread_release/messages?project_id=Release%20Review" Starts or queues a turn and streams UI message events until the request settles. -Use a new thread ID for the first Agent-backed turn. The accepted send creates and binds that thread; an ordinary thread cannot later be converted. +First read `GET /v1/agents/{agentId}/chats`. Reuse the main conversation's `threadId` and `projectName` when one exists. Only use a new thread ID if the Agent has no main conversation: the first accepted send creates and binds it. A second top-level conversation for the same Agent is rejected, and an ordinary thread cannot later be converted into an Agent conversation. + +The example below assumes this Agent has no main conversation yet. ```bash title="Request" curl -N "$FLUSO_API/v1/chat" \ diff --git a/content/docs/developers/architecture.mdx b/content/docs/developers/architecture.mdx index 999819d..acd9048 100644 --- a/content/docs/developers/architecture.mdx +++ b/content/docs/developers/architecture.mdx @@ -35,14 +35,14 @@ Project working memory belongs to its project. Agent configuration and chat hist Components can change where the code defines an explicit contract: -- Runtime compute sits behind a `SandboxProvider` contract. Current implementations cover local Docker and AWS ECS. +- Runtime compute sits behind a `SandboxProvider` contract. The managed runtime uses AWS Lambda MicroVMs. The provider contract also has local Docker and AWS ECS implementations. - Models resolve through a provider-scoped catalog. Current provider paths cover PCCI and OpenRouter; the catalog does not promise that every model works through every provider. - Managed apps and custom servers meet the runtime through MCP and the same tool-policy boundary. A source can change while the protocol stays fixed, though tool names and semantics can still differ. - Services can move behind their HTTP contracts when the replacement preserves authentication, response shape, and failure behavior. ## Governed external context -An MCP server advertises tools. User policy decides whether each tool is allowed, denied, or requires approval. Organization policy separately governs network egress. Read-only classification can permit low-risk reads without turning every MCP connection into a read-only connection. +An MCP server advertises tools. User policy decides whether each tool is allowed, denied, or requires approval. Network policy separately governs outbound access. Read-only classification can permit low-risk reads without turning every MCP connection into a read-only connection. External data stays under the source system's own controls until an approved tool reads it. Fluso may then persist selected outputs in chat history, project files, or knowledge records according to the requested work and platform policy. diff --git a/content/docs/developers/evaluations.mdx b/content/docs/developers/evaluations.mdx index 4a7f32e..e8f947e 100644 --- a/content/docs/developers/evaluations.mdx +++ b/content/docs/developers/evaluations.mdx @@ -1,61 +1,36 @@ --- -title: Agent evaluations -sidebarTitle: Evaluations +title: Testing Agents +sidebarTitle: Testing Agents icon: flask-conical -description: Test one response or a short conversation before relying on an Agent for live work. +description: Manually check an Agent's responses and approval boundaries before using it for live work. --- -Evaluations answer a practical question: does this Agent handle an important case the way you expect? Save a test once, run it after an Agent change, and compare the result with earlier runs. +The current Agents interface does not include the earlier Evaluations screen, saved Check/Simulation tests, or automatic scores. You can test behavior in an Agent conversation and compare the results yourself. -Open an Agent and select **Evaluations**, then select **Add test**. +## Define an observable result -## Choose the test type +For an escalation Agent, use a synthetic case: -| Type | Use it for | What runs | -| --- | --- | --- | -| **Check** | One clear decision or response | One prompt and one Agent response | -| **Simulation** | A conversation that depends on follow-up details | A starting message, then one participant reply per line | +> *"This is a test case: checkout is unavailable for every customer. Classify the severity, identify missing context, and draft the internal escalation. Do not send messages or change any external system."* -Use a check when one answer is enough to judge the behavior. Use a simulation when the Agent should ask questions, keep a decision consistent, or reach a safe handoff over several turns. +Before running it, write down what you expect: a P0 classification, named missing details, and a draft that has not been sent. -## Example: test an escalation Agent +For a conversation test, add one follow-up at a time. Check whether the Agent retains the facts and adjusts its result when the situation changes. -Create this check: +## Review tools and shared context -- **Name:** `P0 escalation` -- **Prompt:** `Production checkout is down for every customer.` -- **Expected outcome:** `Classifies the incident as P0, identifies missing context and a next owner, and does not send an external message.` -- **Evaluation guidance:** `The response must stop for approval before any external action.` + + These are normal Agent turns. They can use connected Apps, write project files, and affect memory. Calling a request a test does not disable tools. Review capabilities and approval settings first; use a separate project and synthetic data when isolation matters. + -Then create this simulation: +A duplicate Agent gives you a separate main conversation, but can still use the same project and connections. Select a suitable project and use **Ask me first** with Ask rules for external writes you need to review. -- **Name:** `Delayed P1 customer` -- **Starting message:** `Our enterprise checkout workflow is severely degraded and customers cannot complete purchases.` -- **Participant replies:** one line each: `It affects our European stores.`; `We have a workaround, but it is slow.`; `When can you escalate this?`; `Please draft an acknowledgement.` -- **Expected outcome:** `Keeps the incident at P1, gathers the customer, impact and urgency, prepares an acknowledgement and internal escalation, and stops for approval.` +## Repeat after an edit -Write the expected outcome as observable behavior. Prefer “classifies as P0 and names the next owner” over “handles the incident well.” Add guidance only for a boundary that is easy to miss. +1. Keep the test prompt and expected result in a file you control. +2. Record the Agent's instructions and result before editing. +3. Save the change, then repeat the case. The main conversation uses the new configuration on its next turn. +4. For an independent conversation, duplicate the updated Agent and review its project and capabilities. +5. Compare correctness, missing information, and approval behavior. Restore the earlier instructions manually if needed. -## Run and review - -Select **Run** beside a test. The result shows: - -- Passed or failed and a score out of 100. -- A short explanation of what met or missed the expected outcome. -- The Agent response, or the full transcript for a simulation. -- A link to the evaluation thread. -- Score history after the same test has completed more than once. - -The run uses the Agent's current saved version. The run record keeps that version ID, so results from before and after an edit remain distinguishable. - -Evaluation runs cannot call tools or update Agent memory. They test the response safely; they do not send messages, change external data, or train the Agent. Edit the Agent or test definition yourself, then run the test again. - -## A useful release loop - -1. Add checks for the decisions that must never regress. -2. Add one short simulation for the main handoff or follow-up flow. -3. Run them before editing the Agent and note the results. -4. Save the Agent change and run the same tests again. -5. Open a new Agent thread for a final live test, including any tool approval you expect a person to review. - -If the change performs worse, use [Versions](/developers/versions) to restore the last known-good setup. +See [Configuration and sharing](/developers/versions) for copies and [Approvals](/features/approvals) for tool rules. diff --git a/content/docs/developers/project-context.mdx b/content/docs/developers/project-context.mdx index 068d467..f8c71d1 100644 --- a/content/docs/developers/project-context.mdx +++ b/content/docs/developers/project-context.mdx @@ -5,9 +5,9 @@ icon: folder-open description: See how an Agent's configured project affects files, working memory, and new threads. --- -Every Agent is assigned to one project. New Agent threads start in that project and use its files and project working-memory summaries. +Every Agent has a configured project. Its main conversation starts in that project and can use its files and working-memory summaries. Delegated sessions use their parent conversation's project. -Changing the Agent's project affects new threads. Existing threads stay with the project and Agent definition they started with. +Changing the configured project does not move an existing conversation or its files. The main conversation can adopt updated instructions on its next turn while keeping its original project. Existing delegated sessions keep both their project and saved configuration. ## Three project layers diff --git a/content/docs/developers/schedules.mdx b/content/docs/developers/schedules.mdx index 687f532..d89b646 100644 --- a/content/docs/developers/schedules.mdx +++ b/content/docs/developers/schedules.mdx @@ -7,9 +7,9 @@ description: Wake an existing Agent thread with a saved message once or on a rec A schedule saves a future message for one existing Agent thread. When it becomes due, Fluso sends that message to the same thread as a separate follow-up turn. -A schedule does not create a new Agent or a new conversation. It wakes the thread with its saved Agent definition, history, and project scope. +A schedule does not create a new Agent or a new conversation. It wakes the thread with its history and project scope. The main conversation uses the current Agent configuration; a delegated session keeps the configuration it started with. -To create or manage schedules from an Agent chat, enable thread management for that Agent. +Open the Agent's **Routines** section to review its schedules, or ask the Agent to manage them in chat. ## One-time and recurring schedules @@ -38,4 +38,4 @@ If a recurring turn is still queued, running, or waiting for approval, Fluso doe ## Next -Use [Schedules](/developers/api-ref/schedules) for the REST endpoints, [Webhooks](/developers/webhooks) for event-driven turns, and [Runs](/developers/api-ref/runs) to inspect each accepted turn. +Use [Schedules](/developers/api-ref/schedules) for the REST endpoints, [Webhooks](/developers/webhooks) for the current event-integration options, and [Runs](/developers/api-ref/runs) to inspect each accepted turn. diff --git a/content/docs/developers/threads-and-contexts.mdx b/content/docs/developers/threads-and-contexts.mdx index 1c7f10e..0f31f68 100644 --- a/content/docs/developers/threads-and-contexts.mdx +++ b/content/docs/developers/threads-and-contexts.mdx @@ -2,86 +2,56 @@ title: Threads and contexts sidebarTitle: Threads & contexts icon: messages-square -description: Understand which Agent settings, conversation history, project data, and files reach each thread. +description: Understand the main Agent conversation, delegated sessions, and their shared project context. --- -A thread is one conversation with a saved Agent. Its context is assembled from several sources with different lifetimes. +Each saved Agent has one main conversation. Open the Agent in the workspace to continue it. The Agent can delegate bounded tasks into separate sessions when work needs its own conversation. -## Start a new chat with an Agent - -In the Agents workspace, find the Agent in the left sidebar and select the **+** beside its name. You can also open the Agent and select **New thread** in the top right. - -The new chat opens with that Agent's saved name, instructions, knowledge, Apps, and project. Send the first request as you would in an ordinary chat. For example: - -> *"A customer says checkout is unavailable for their whole company. Classify the incident, list the missing details, and prepare the internal escalation. Do not contact anyone yet."* - -Use one thread for one case or outcome. Start another thread for a different customer, incident, or piece of work. This keeps the conversations separate while both can still use files and working memory from the Agent's configured project. - -If you edit the Agent, start a new thread to test the change. A thread keeps the Agent setup it started with; it does not switch versions midway through a conversation. +> *"Review this customer incident. Gather the impact and missing details, then prepare an internal escalation. Do not contact anyone yet."* ## Context map -| Source | Scope | What happens in a new thread | +| Source | Main conversation | Delegated session | | --- | --- | --- | -| Agent definition | Saved Agent configuration | Captured when the thread starts | -| Conversation history | One thread | Starts empty | -| Agent knowledge files | Agent configuration | The configured list is captured at start | -| Project files | Configured project | Shared with other threads in that project | -| Project working memory | Configured project | Recent summaries can be recalled | -| Child task message | One child thread | Only the sent message is added, not the parent transcript | - -The Agent definition includes its name, description, goal, instructions, allowed capabilities, project, and knowledge files. Editing that setup changes new threads. Existing threads keep the configuration they started with. +| Agent instructions, capabilities, and knowledge-file selection | Current saved configuration on the next turn | Configuration captured when the session was created | +| Conversation history | Continues across turns | Its own history; a fork also starts with completed parent context | +| Project files | Conversation's project | Parent's project | +| Project working memory | Recent project summaries can be recalled | Recent project summaries can be recalled | +| Delegated task | Your request and follow-ups | The task message sent by the parent | -## Ordinary chat context is different +Editing an Agent does not change work already running. The main conversation picks up the new configuration on its next turn; an existing delegated session keeps its saved configuration. -Ordinary project chats can use global user preferences, project instructions, and `context.md`. Saved Agent threads use the Agent's saved definition instead. They can still use project files and working-memory summaries shared by the project. +Ordinary chats can use global preferences, project instructions, and `context.md`. Saved Agent conversations use their own instructions instead, while retaining access to project files and working-memory summaries. ## Keep contexts isolated -### What stays in one thread +Each conversation keeps its messages and turn state. Project files and working memory can still be shared, so separate conversations are not separate file sandboxes. -- Its messages and attached-file references. -- In-progress turn state and temporary session data. -- The Agent definition captured when the thread started. +The current Agent interface does not create several independent top-level chats for one Agent. Duplicate the Agent when you need a separate setup and main conversation. Choose a different project as well if its files and working memory should be separate. -A new thread does not receive another thread's conversation history. - -### What threads can share - -Threads started from the same Agent can use the same knowledge files and capabilities. Threads in the same project can also use its files and short working-memory summaries. If two threads edit the same resource at once, their changes can conflict. - -### When to start a new thread - -Start one when the topic or customer changes, when a task needs its own history, or when independent work can progress separately. Keep the current thread when the next step depends on its full conversation. +Changing an Agent's configured project does not move an existing conversation or its files. See [Project context](/developers/project-context). ## Use parent and child threads -A top-level Agent thread can create direct child threads for separate tasks. Each child receives a bounded task and works in its own conversation. The hierarchy has one level: a parent can create several children, but a child cannot create another child. - -### Choose when children are created - -| Setting | Behavior | -| --- | --- | -| Off | The Agent cannot manage other threads. | -| Explicit | The Agent creates a child only when you ask or its instructions require one. This is the default. | -| Proactive | The Agent may create direct children for distinct tasks that can progress independently. | +A main Agent conversation can create direct child sessions for bounded work. A child cannot create another child. The parent can follow up with its children and receive their results. -### Give a child enough context +The Agent's session tool supports two ways to start a child: -A child sees the task message, not the parent's transcript. Include the task, source material, constraints, approval boundaries, and expected result. Its final result returns to the parent automatically; only the parent that created it can send follow-up work, cancel it, or delete it. +- A fresh session receives the task message and the Agent/project context, without the parent's transcript. +- A fork also receives the parent's completed context at the fork point. It does not inherit unfinished work from the current turn. -### Work in parallel safely +Give each task an expected result, necessary sources, and approval boundaries. Use independent sessions for read-only research or different outputs; coordinate changes to shared files in one conversation. -Use separate children for read-only research or changes to different outputs. Keep changes to the same files or shared APIs in one thread, then combine the work there. +Thread creation is guided by the task and Agent instructions. The current editor has no Off, Explicit, or Proactive thread-management selector. ## Pick the right scope -- Put stable Agent behavior in **Instructions**. -- Put read-only reference material in Agent knowledge files. -- Put finished and working files in the configured project. -- Start a new thread for a clean conversation. -- Use a child thread only when the task can progress with the context you send it. +- Put stable Agent behavior in **Purpose and instructions**. +- Add reference material as knowledge files. +- Keep working files in the conversation's project. +- Delegate a bounded task when it needs a separate conversation. +- Duplicate an Agent for an independent main conversation. ## Related guides -Read [Project context](/developers/project-context) and [User preferences](/developers/user-preferences) for the remaining context boundaries. See [Threads and messages](/developers/api-ref/threads-and-messages) for the public thread API. +Read [Project context](/developers/project-context) and [User preferences](/developers/user-preferences) for the remaining boundaries. See [Threads and messages](/developers/api-ref/threads-and-messages) for the API. diff --git a/content/docs/developers/user-preferences.mdx b/content/docs/developers/user-preferences.mdx index 106762f..9386e34 100644 --- a/content/docs/developers/user-preferences.mdx +++ b/content/docs/developers/user-preferences.mdx @@ -19,12 +19,12 @@ Use these scopes instead: | Need | Put it here | | --- | --- | -| A rule for every new thread of one Agent | Agent **Instructions** | +| A standing rule for one Agent | Agent **Instructions** | | A correction for the current request only | Your message in that thread | | A preference for ordinary chats | `/preferences.md` | | Reference material for an Agent | Agent knowledge files | -A direct request in an Agent thread can change the current response, but it does not rewrite the saved Agent definition. Edit the Agent and start a new thread when the change should persist for that Agent. +A direct request in an Agent thread can change the current response, but it does not rewrite the saved Agent definition. Edit the saved Agent when the change should persist. Its main conversation uses the updated instructions on its next turn; existing delegated sessions keep their earlier configuration. ## Read or edit the file diff --git a/content/docs/developers/versions.mdx b/content/docs/developers/versions.mdx index 38ac4bc..a937e29 100644 --- a/content/docs/developers/versions.mdx +++ b/content/docs/developers/versions.mdx @@ -1,68 +1,52 @@ --- -title: Agent versions -sidebarTitle: Agent versions +title: Agent configuration and sharing +sidebarTitle: Configuration & sharing icon: git-compare-arrows -description: Review, restore, export, import, and share an Agent's saved setup. +description: Update an Agent, duplicate it, and publish or revoke a share link. --- -Fluso keeps saved Agent configurations as versions. A version records the Agent fields used by a thread, including its instructions, response mode, knowledge-file list, Apps, project, skills, and thread settings. +Saving an Agent creates a configuration snapshot. The main conversation uses the current snapshot on its next turn; existing delegated sessions keep the snapshot they started with. -Open the Agent, select its name in the top bar, then select **Version history**. +Use **Modify** in the Agent menu or **Edit** in its details to change the setup. The current interface has no Version history or rollback screen. Keep a copy of instructions you may want to restore, then save those fields again if needed. API updates use `currentConfigId` to detect conflicting edits; see [Agents and versions](/developers/api-ref/agents-and-versions). -## Review what changed - -The newest entry is marked **Current**. Expand **changes** on an entry to compare it with the version saved immediately before it. Each entry also shows when it was saved and a short configuration ID. +## Move an Agent between workspaces -Use this history when an edit changes an Agent's behavior unexpectedly. It lets you identify the last setup that produced a good result without guessing which fields changed. +Use **Share** in the Agent menu to publish a setup that another person can inspect and import as an independent Agent. -## Roll back safely +### Create a public link -1. Find the last known-good saved configuration. -2. Select **Roll back**. -3. Review the fields listed in the confirmation dialog. -4. Select **Promote to current**. -5. Start a **New thread** and repeat the request or [evaluation](/developers/evaluations) that exposed the problem. +Review the instructions and choose whether to include: -Rollback does not erase history. Fluso creates a new current configuration from the selected version, so the change is visible and can itself be reversed later. +- **Custom skills**, including files in each selected skill's folder. +- **Knowledge files**, including the contents of selected files. +- **Custom connections**, including their server URLs and connection settings. -Existing threads keep the configuration they started with. Only new threads use the restored configuration. This prevents a long-running conversation from changing behavior halfway through. +Select **Create public link**, then copy the link. Shared resources have a combined 20 MiB limit. - Rollback restores saved Agent fields. It does not restore an older Agent Studio workflow preview, recreate deleted project files, or copy back a project that no longer exists. + Anyone with the link can read the published setup and included resources. Inspect files and connection URLs for sensitive data before publishing. App credentials, chat history, and routines are not included. -If the selected version points to a deleted project, recreate the settings you need in the editor, choose a current project, and save them as a new version. If the Agent changed in another browser tab, refresh the history, review the newest version, and retry. - -### Example: restore severity rules +Built-in skills and resources you do not include remain references for the recipient to review. Project files are not automatically part of an Agent share; [export the project as ZIP](/features/projects#export-a-project) separately when needed. -Suppose a customer escalation Agent begins treating degraded service as P0 after its severity instructions were edited. Open **Version history**, compare the instruction changes, and promote the last version that kept degraded-but-usable service at P1. Then start a new thread with the same case and confirm the severity, next owner, and approval boundary. - -## Move an Agent between workspaces +### Update or stop sharing -Export, import, and share create portable copies of an Agent's setup. They do not transfer a live Agent, its chat history, or ownership of the original. Open the Agent and select its name in the top bar to find **Export YAML**, **Import Agent**, and **Share**. +Edits to your Agent do not automatically update the published snapshot. Open **Share** and choose **Update shared version** to publish the current setup. -### Export a file - -Select **Export YAML** to download an `.agent.yaml` definition. The file contains the portable Agent fields and saved workflow, but leaves out workspace identities, secrets, deliveries, project ownership, and knowledge-file contents. It lists omitted knowledge files so the recipient knows what to add again. - -If the Agent relies on a project, [export that project as a ZIP](/features/projects#export-a-project) separately to carry its files, `context.md`, and metadata. +Choose **Stop sharing** to revoke the public link. This stops future access through the link; it does not remove copies already imported or downloaded by someone else. ### Import a copy -Select **Import Agent** and choose a Fluso Agent YAML, YML, or JSON definition. Fluso opens a new draft in **Home**; it does not overwrite the Agent whose menu you used. - -Before creating the copy, review its instructions, select the destination project, add its knowledge files, and reconnect its Apps. Named skills remain references and must exist in the destination workspace. If the source Agent could use every skill, the imported copy starts with no skills selected; choose the skills it should use. - -Agent definition files are limited to 128 KB. Fluso rejects an incomplete definition or unsupported format version instead of creating a partial Agent. +Open the shared link and review its instructions, capabilities, and included files before importing. You can also start from **Agents → New Agent → Import from a shared link**. -### Share a review link +Choose the new Agent's name and destination project. Connect your own Apps and review permissions before using it. The imported Agent has its own conversation and routines; future changes to the source do not update your copy. -Select **Share**, then **Copy link**. Anyone with the link can review the read-only definition and import a separate copy. +The current interface uses share links for this flow. It does not offer the older Export YAML or Import Agent file controls. -The definition is stored in the link itself, so the link cannot be revoked. Anyone who keeps it can reopen that snapshot. Share it only with people who may read the Agent's instructions and setup. Later edits do not update the link or an imported copy; create a new link for a newer snapshot. +## Duplicate in your workspace -For a customer escalation Agent, send the support lead a review link or exported definition. They can inspect the P0/P1 rules, import a copy, connect their own Gmail and Slack access, add their runbook, and test it without changing your Agent or threads. +Choose **Duplicate** in the Agent menu for a separate Agent with copied configuration and knowledge. Its conversation and routines start separately. Check the project before testing: duplicates can still work with the same project files. -For project and conversation imports, see [Imports](/features/imports). Those imports bring context and files into projects; they are separate from importing an Agent definition. +## A practical handoff -For API-based version updates, see [Agents and versions](/developers/api-ref/agents-and-versions). +Share the Agent setup, provide any additional project files separately, and ask the recipient to connect their own Apps. Review [approval settings](/features/approvals), then [test the copy](/developers/evaluations) before using it for customer work. diff --git a/content/docs/developers/webhooks.mdx b/content/docs/developers/webhooks.mdx index f42ce0e..519de46 100644 --- a/content/docs/developers/webhooks.mdx +++ b/content/docs/developers/webhooks.mdx @@ -2,119 +2,23 @@ title: Webhooks sidebarTitle: Webhooks icon: webhook -description: Send authenticated JSON events into an Agent and inspect the resulting thread and delivery receipt. +description: Current availability of inbound Agent webhooks and the authenticated API alternative. --- -An Agent webhook receives JSON from another system and starts a follow-up Agent turn. It is an inbound trigger, not a callback that Fluso sends to another service. +The current Agents release does not expose an inbound webhook trigger interface or the earlier Agent webhook endpoints. Instructions referring to **Triggers**, webhook secrets, delivery receipts, or an Agent **Analytics** page do not apply to this release. -Choose whether events use a dedicated thread or an existing Agent thread. Each accepted event uses the Agent definition and project attached to that thread. +## Integrate an external event -## Create a webhook +A service you control can receive an event, authenticate it, and call the [Fluso chat API](/developers/api-ref/threads-and-messages#send-a-message) with your Fluso bearer token. This requires your own event handler; Fluso does not provide a webhook URL for it. - - - Open the Agent-name menu and choose **Triggers**. - - - Click **Add trigger**, give it a clear name, and choose an authentication - method. **Header secret** is the safer default. Use a query secret only - when the sending service cannot set a custom header. - - - Select **New thread on first event** to keep these events together in a - dedicated thread, or select an existing non-archived Agent thread. - - - Click **Create trigger**, then copy the webhook secret. Fluso shows the - clear secret only after creation or rotation. The webhook URL remains - available on the trigger row. - - +- Keep the bearer token on your server. +- Validate the event and send only the fields the Agent needs. +- Reuse the Agent's existing main conversation. +- Use a unique `requestId` for each intended turn and preserve it when retrying that turn. +- Follow the [run](/developers/api-ref/runs) to determine whether work completed. -## Send an event +Treat event text as untrusted input. Review [approval settings](/features/approvals) before allowing an event to cause an external write. An accepted chat request is not proof that the work finished. -The public delivery URL uses the webhook secret, not your Fluso bearer token. A header-authenticated request looks like this: +## Time-based work -```bash -export FLUSO_WEBHOOK_URL='' -export FLUSO_WEBHOOK_SECRET='' - -curl "$FLUSO_WEBHOOK_URL" \ - -X POST \ - -H 'Content-Type: application/json' \ - -H "X-Fluso-Webhook-Secret: $FLUSO_WEBHOOK_SECRET" \ - -H 'Idempotency-Key: release-ready-2026-09-01' \ - -d '{"event":"release.ready","release":"2026.09.01"}' -``` - -If you chose **Query secret**, send the same value through the `secret` query parameter. Query values can appear in browser, proxy, and server logs, so prefer the header when possible. - -The request must use `application/json`, contain valid JSON, and stay at or below 25,000 bytes. Fluso accepts any JSON shape; define the fields your Agent instructions expect. - -## Read the receipt - -A successful request returns `202 Accepted` with a delivery receipt: - -```json -{ - "id": "", - "receivedAt": "2026-09-01T12:00:00.000Z", - "payloadSummary": "JSON event · 54 bytes", - "status": "accepted", - "responseCode": 202, - "requestId": "webhook::", - "threadId": "", - "error": null -} -``` - -`202 Accepted` means the Agent turn was admitted or queued. It does not mean the Agent finished. Open the target thread or the Agent's **Analytics** page to inspect the run. - -If the target thread is already running, the event waits as a follow-up instead of interrupting the current turn. - -## Test and inspect deliveries - -Expand **Test & deliveries** on the trigger row. Edit the sample JSON and click **Send test event**. This is a real Agent turn. - -The trigger shows its latest 20 completed receipts. The list shows accepted or failed status, time, a payload-size summary, and a link to an accepted event's thread. The receipt stores a payload digest and size summary instead of the full JSON body. Idempotency records can remain for 24 hours even when they are no longer in that list. - -The full payload is added to the Agent message and becomes part of the target thread's context and history. Do not send a secret unless the Agent is intended to receive it. - -## Idempotency and retries - -Fluso makes one admission attempt for each delivery. It does not retry a failed request automatically. - -Send one `Idempotency-Key` header when your sender may retry. For 24 hours on that trigger: - -- The same key and payload returns the original receipt without another Agent turn. -- The same key with a different payload returns `409 Conflict`. -- Replaying a failed key returns the same failure; use a new key only when you intend to create a new turn. - -Without an idempotency key, repeated requests create separate Agent turns. - -## Pause, rotate, or delete - -- Turn the trigger switch off to pause it. Requests to a paused trigger return `409`. -- Choose **Rotate secret** if a secret may be exposed. The old secret stops working immediately, and the replacement is shown once. -- Choose **Delete trigger** to remove its URL and delivery history. Later requests to that URL return `404`. - -## Security boundary - -Treat every payload as untrusted input. It becomes thread context, so remove credentials and fields the Agent does not need. A webhook does not bypass the Agent's saved capabilities, tool rules, or approval boundaries. Keep external writes behind approval when an event should prepare work rather than publish it. - -## Common errors - -| Status | Check | -| --- | --- | -| `400` | The body is valid JSON. If present, `Idempotency-Key` appears once and contains 1 to 255 characters. | -| `401` | The header or query secret matches the current secret. | -| `404` | The trigger, Agent, or target thread still exists. | -| `409` | The trigger is enabled, the target is available, and the idempotency key is not conflicting or already in progress. | -| `413` | The raw JSON body is no larger than 25,000 bytes. | -| `415` | `Content-Type` is `application/json`. | -| `429` | The sender's IP rate limit or the Agent owner's usage limit has been reached. Honor `Retry-After` when it is present. | -| `502` or `503` | The Agent service and runtime are available. A repeated failed key returns the recorded failure and does not start another attempt; use a new key only when you intend one. | - -## Next - -Use [Runs](/developers/api-ref/runs) to inspect accepted turns, [Threads and contexts](/developers/threads-and-contexts) to understand the target thread, and [Schedules](/developers/schedules) for time-based triggers. +Use [Schedules](/developers/schedules) when a saved message should run at a future time or on a recurring routine. diff --git a/content/docs/features/approvals.mdx b/content/docs/features/approvals.mdx index ba9e562..8fdfa1b 100644 --- a/content/docs/features/approvals.mdx +++ b/content/docs/features/approvals.mdx @@ -2,108 +2,73 @@ title: Approvals and permissions sidebarTitle: Approvals icon: shield-check -description: Choose when Fluso asks before connector and MCP tool actions, review approval cards, and manage saved tool rules. +description: Set the account default, override it in a chat, and manage individual MCP tool rules. --- -Approvals let you decide how much Fluso can do without stopping for confirmation. You can keep every connector and MCP tool action behind a prompt, or let Fluso run them automatically. - -Your choice belongs to a chat. Existing chats keep their current mode. A choice made before a new chat starts is pending until you send the first message and the chat is created. - - - Organization rules and your saved **Deny** rules always apply. An automatic mode cannot override them. - +Fluso uses two approval modes for connected-app and MCP tools: **Ask me first** and **Allow everything**. Saved tool rules and network-access restrictions also apply. ## Choose an approval mode -| Mode | Connector and MCP tools | +| Mode | Behavior | |---|---| -| **Ask for everything** | Ask before a tool runs | -| **Don't ask permission** | Approve tools automatically | - -Use **Ask for everything** when you want to review each action before a tool can read or change data. **Don't ask permission** is best for work you trust Fluso to finish without waiting for you. - -### Set the mode from the composer - - - - Start a new chat and click the shield control beside the model mode in the composer. - - - Pick **Ask for everything** or **Don't ask permission**. The menu explains which requests will still pause. - - - Before a thread exists, the composer labels the choice as **Pending**. Sending your first message creates the chat and confirms its mode. - - - -You can change the mode between messages. The updated choice applies to later actions in that chat. It does not change other existing chats. +| **Ask me first** | Ask for tools that do not already have an effective Allow rule | +| **Allow everything** | Approve tools automatically, including Ask rules; Deny rules still block | -## Connector tool approval cards +Read-only tools follow each connection's settings. **Ask me first** does not force an approval for a tool that already has permission to run. -Connector and MCP tools can read or change data in another service. When a tool needs approval, the card shows the connector or server, tool name, a short argument summary, and an expandable view of the exact arguments. +Use the hand or open-lock control beside the reasoning mode in the composer. `⌘⇧\` switches between the two modes. -You can choose: +- In an existing chat, changing the control sets an override for that chat. +- On a new-chat screen, it changes your saved account default immediately. +- Chats without their own override follow the account default, including existing chats. +- Chats with an override keep it when you change the default. -- **Allow once** to run this tool only with the arguments shown on the card. -- **Always allow** to save an allow rule for this tool. -- **Deny** to reject this request without creating a permanent tool deny. +## Manage the account default -If the required app is not connected, the card asks you to **Connect** first. Complete sign-in and Fluso resumes the waiting action. If the request changes while you are deciding, it fails closed instead of applying your decision to different arguments. +Open your account menu, choose **Settings**, then **Approvals & permissions**. **Auto-approval** changes your account default for chats without an override. Changing one chat does not rewrite every other chat's override. -If the card expires or the run is canceled before you decide, ask Fluso to try the action again. An organization-managed deny is locked and cannot be approved from chat. +## Approval cards - - Use **Allow once** for a sensitive write or an unusual set of arguments. Use **Always allow** for a tool you expect this chat to call repeatedly. - +When a connected-app tool needs approval, the card shows the app or server, tool name, a short argument summary, and the exact arguments. -## Manage approvals in Settings +- **Allow once** permits the displayed request once. +- **Always allow** saves an allow rule for that tool. +- **Deny** rejects the request without creating a permanent tool deny. -Open your account menu, choose **Settings**, then open **Approvals & permissions**. This panel controls the mode for your next new chat. +If an app is missing, use **Connect** and complete sign-in. If the request changes, expires, or is canceled while you are deciding, the old card cannot approve a new action. Ask Fluso to retry it. -### Set the default for the next chat - -The **Auto-approval** section has the same modes as the composer. A Settings change is staged for your next new chat. It does not rewrite the mode of chats that already exist. - -## Which rule wins - -Fluso applies the most restrictive relevant rule. In practical terms: - -1. An organization **Deny** always blocks the tool. -2. Your **Deny** can block something the organization allows. -3. An organization **Allow** can make an action available, unless you denied it. -4. Your **Allow** can approve an action when the organization has not blocked it. -5. With no saved rule, the current chat mode decides whether Fluso asks or continues automatically. - -This is why switching to **Don't ask permission** does not open something that your organization or you explicitly blocked. + + Use **Ask me first** and set external write tools to **Ask** when you want to review each message, invitation, or change before it is sent. **Allow everything** bypasses Ask prompts, including explicit Ask rules. + -## Manage MCP tool rules +## Saved tool rules -Open **Plugins**, select an MCP server, and open its tool permissions. Each tool can be set to **Allow**, **Ask**, or **Deny**. +Open **Plugins → MCP**, expand a connection, and review **Tool permissions**. -You can also enable automatic approval for tools classified as read-only, such as list, search, fetch, and GET operations. An explicit **Ask** or **Deny** on a tool takes precedence over that read-only setting. +- **Allow** permits the tool without asking, unless a higher-priority policy blocks it. +- **Ask** requires approval in **Ask me first** mode. **Allow everything** automatically approves it. +- **Deny** blocks it. +- **Auto-approve read-only tools** permits tools classified as read-only. Explicit Ask and Deny rules take precedence over read-only auto-approval, but **Allow everything** still bypasses Ask. -See [MCP servers](/features/mcp) for connection setup and credential handling. +Network policy can block a connection independently of its tool permissions. Installing a skill or enabling **Allow everything** does not remove network restrictions or tool Deny rules. ## Troubleshooting - - Settings changes apply to the next new chat. Existing chats keep their current mode. Change the shield control in this chat, or start a new one. - - - The chat has not been created yet. Send the first message to commit that mode to the new chat. + + Check the control in this chat. A chat-specific override takes precedence over the account default. - - Ask Fluso to retry the action. Approval cards are bound to one pending request and cannot approve a later or changed request. + + Check the current chat mode. **Allow everything** approves Ask rules automatically. Switch to **Ask me first** to require the prompt. - - Tool rules apply to the specific tool, not every tool on the connector or MCP server. Review that server's tool permissions under **Plugins**. + + Check for an existing Allow rule or enabled read-only auto-approval. The chat mode is the fallback for tools without an applicable saved rule. - - Check that server's tool permissions under **Plugins** for a saved **Deny**. If the rule is locked or marked as managed by your organization, only an organization administrator can change it. + + Check for a Deny rule. For a separate network-policy block, contact the deployment operator. ## Next -See [Chat](/features/chat) for thread and composer behavior, and [Apps and MCP servers](/features/mcp) for app access and third-party tools. +See [Apps and MCP servers](/features/mcp) for connection setup and [Chat](/features/chat) for the composer and follow-up queue. diff --git a/content/docs/features/chat.mdx b/content/docs/features/chat.mdx index dc4acd7..635dab0 100644 --- a/content/docs/features/chat.mdx +++ b/content/docs/features/chat.mdx @@ -23,13 +23,11 @@ Quick answers straightforward questions and small edits. Deep takes longer on co The mode is chat-specific. You can change it between messages, and new chats start in Deep unless you switch them. -This only affects the chat you are using in the app. Telegram has its own conversation mode: using `/fast` in Telegram does not change an app chat, and changing the app control does not change Telegram. - ## Approval mode -Use the access control beside the mode button to choose when Fluso asks before connector and MCP tool actions. It shows a hand for **Ask me first**, a globe for **Allow web**, and an open lock for **Allow everything**; `⌘⇧\` steps through them. The choice belongs to the current chat. Before a new chat exists, it remains pending until you send the first message. +Use the access control beside the mode button to choose when Fluso asks before connector and MCP tool actions. It shows a hand for **Ask me first** and an open lock for **Allow everything**; `⌘⇧\` switches between them. A change in an existing chat sets an override for that chat. Before a new chat exists, the control changes your saved default. -See [Approvals and permissions](/features/approvals) for the modes, in-chat approval cards, saved tool rules, and organization policy behavior. +See [Approvals and permissions](/features/approvals) for the modes, in-chat approval cards, saved tool rules, and network-access boundaries. ## Asking for things well @@ -43,7 +41,7 @@ Two things matter more than anything else. A thread is one conversation. It remembers what you've said and what Fluso has said back, so a follow-up prompt picks up where you left off. After Fluso summarises your inbox, *"reply to the one from Legal"* makes sense because the summary is still in context. -Start a new thread when you switch topic. The plus button at the top works, or you can ask for one in chat. Old threads stay in the sidebar. Pick any of them back up and Fluso has the full history. +Start a new thread when you switch topic. The plus button at the top works, or you can ask for one in chat. Old threads stay in the sidebar. You can reopen the conversation; long histories may be summarized in the model context. ## Things you can do inside chat @@ -82,7 +80,7 @@ Stop the run with the square button and queued follow-ups pause instead of firin ## A few habits - One topic per thread. Switching subjects mid-thread blurs the context Fluso uses. The cost of starting a new thread is zero. -- Switch into a project when you're working on something specific. Project context tightens the answers. Without it, Fluso draws on everything. +- Switch into a project when you're working on something specific. Project context keeps the relevant files and memory together. **Home** is the project for general work. - Don't fight clarifying questions. If Fluso asks *"Which project?"* or *"What format?"*, answer it. The back-and-forth is faster than guessing on its behalf. ## Next diff --git a/content/docs/features/confidential.mdx b/content/docs/features/confidential.mdx index 9f361c8..656e749 100644 --- a/content/docs/features/confidential.mdx +++ b/content/docs/features/confidential.mdx @@ -19,7 +19,7 @@ For the full technical picture, see Prem's [confidential compute documentation]( ## Plans -Confidential mode is included with the **Confidential** plan. Accounts granted access by the Fluso team show **Sponsored Confidential** as their effective plan. +Confidential mode is included with the **Confidential** plan. **Pro does not include confidential mode.** Accounts with an active grant from the Fluso team show **Sponsored Confidential** as their effective plan. That access lasts until the grant expires; a Pro subscription alone does not keep it active afterward. Open **Settings** and find **Encrypted Inference**. Without plan access, the row reads "Available on the Confidential plan" and shows **Upgrade**. With plan access, it shows an **Off** or **On** switch. @@ -54,7 +54,7 @@ Open **Settings** and find **Encrypted Inference**. Without plan access, the row Image generation and automated task creation. Both rely on paths that would take your data outside the enclave, so they're turned off in this mode. - The Confidential plan. Team-granted access appears as Sponsored Confidential. + The Confidential plan or an active Sponsored Confidential grant. Pro alone does not include confidential mode. Inside the enclave, no. At the gateway, your request is encrypted for a hardware-sealed environment that infrastructure operators and the cloud provider cannot access. Before that, traffic passes through Fluso's AWS infrastructure. diff --git a/content/docs/features/imports.mdx b/content/docs/features/imports.mdx index d3dcfd3..8b7dd6d 100644 --- a/content/docs/features/imports.mdx +++ b/content/docs/features/imports.mdx @@ -99,7 +99,7 @@ When the import finishes, the dialog shows the projects created, files added to | Item | Limit | |---|---| | Upload file | `.zip` only | -| Zip size | 300 MB | +| Zip size | 300 MiB | | Sources | Agent app, ChatGPT export, Claude export | | Projects | Up to 8 planned; 10 hard limit | | Files per project | 500 | @@ -123,7 +123,7 @@ For agent-app exports, use the prompt in the dialog and check the manifest befor - Check that you uploaded a `.zip` file under 300 MB. For ChatGPT and Claude, upload the official export zip without unpacking it. + Check that you uploaded a `.zip` file under 300 MiB. For ChatGPT and Claude, upload the official export zip without unpacking it. Open the import thread from the dialog. The thread usually shows the step that failed and what Fluso tried before stopping. diff --git a/content/docs/features/mcp.mdx b/content/docs/features/mcp.mdx index de323ce..7137cb9 100644 --- a/content/docs/features/mcp.mdx +++ b/content/docs/features/mcp.mdx @@ -114,8 +114,8 @@ Expand any connection row to see its tools and set rules per tool. The Web Search row expanded: a Tool permissions section with an 'Auto-approve read-only tools' toggle, and three read-only tools (Exa Search, Exa Get Contents Action, Exa Answer), each with Allow, Ask, and Deny buttons. -- **Auto-approve read-only tools** allows operations classified as GET, list, search, and fetch to run without asking. Explicit Ask or Deny rules still win. -- Each tool has its own **Allow**, **Ask**, or **Deny**. Allow runs without asking, Ask pauses for your approval in chat, Deny blocks the tool outright. +- **Auto-approve read-only tools** allows operations classified as GET, list, search, and fetch to run without asking. Explicit Ask or Deny rules take precedence over this toggle. The chat mode **Allow everything** still automatically approves Ask rules. +- Each tool has its own **Allow**, **Ask**, or **Deny**. Allow runs without asking, Ask pauses for approval when the chat uses **Ask me first**, and Deny blocks the tool outright. **Allow everything** bypasses Ask rules but keeps Deny blocks. - Tools are grouped read-only versus everything else, so you can see at a glance what can only look and what can act. These rules work together with your chat-level approval mode. See [Approvals and permissions](/features/approvals) for how the modes and rules interact. @@ -155,7 +155,7 @@ Each row shows the connection's status. The three-dot menu holds the two actions The server advertises Dynamic Client Registration but rejected the registration. Switch to **OAuth (BYO)** and register an app in the server's developer console yourself. - Its rule is set to **Ask**, or your chat's approval mode is **Ask for everything**. Set the tool to **Allow** in the row's tool permissions, or change the mode — see [Approvals](/features/approvals). + Its rule is set to **Ask**, or your chat's approval mode is **Ask me first**. Set the tool to **Allow** in the row's tool permissions, or change the mode — see [Approvals](/features/approvals). ## Next diff --git a/content/docs/features/memory.mdx b/content/docs/features/memory.mdx index 23693fc..80f0411 100644 --- a/content/docs/features/memory.mdx +++ b/content/docs/features/memory.mdx @@ -13,7 +13,7 @@ Durable memory follows a stricter rule than you might expect: it saves stable th -**Global preferences.** User-level things that should apply everywhere. Your timezone, the response style you have asked for, workflow choices, standing instructions like *"always show me drafts in plain text"*. These live in `preferences.md` in your workspace, where you can read them. +**Global preferences.** User-level things that apply across ordinary project chats. Your timezone, the response style you have asked for, workflow choices, standing instructions like *"always show me drafts in plain text"*. These live in `preferences.md` in your workspace, where you can read them. **Project context.** Facts, decisions, conventions, and preferences that belong only to the project you are in. The Q3 roadmap decision. The naming convention you agreed with the team. The pricing approach for this client. Each project keeps its own `context.md`. @@ -23,7 +23,7 @@ The split matters because Fluso is careful about scope. Project material stays i ## How it loads -With every message, Fluso pulls in three things as background context: +For ordinary chats, Fluso loads these layers as background context: - Your global preferences - The current project's context @@ -44,7 +44,7 @@ Two paths. Both are conservative on purpose. **You ask explicitly.** Say *"remember this"*, *"forget this"*, *"add this to project context"*, or *"update my preference"* and Fluso edits `preferences.md` or the project's `context.md` directly. Clear intent only. A passing line like *"I like detailed answers"* is not treated as a memory write; that kind of inference goes through the other path. -**Background learning.** After each reply, a background pass updates the project's working memory. When something durable shows up — a stated preference, a clear correction, a convention you keep repeating, a decision — it also adds that to your preferences or the project's context, marked as auto-saved and deduplicated against what is already there. Anything that looks like a secret or credential is dropped rather than saved. If nothing durable came up, it writes nothing durable. +**Background learning.** After each reply, a background pass updates the project's working memory. When something durable shows up — a stated preference, a clear correction, a convention you keep repeating, a decision — it also adds that to your preferences or the project's context, marked as auto-saved and deduplicated against what is already there. This pass is instructed to exclude secrets and credentials; avoid putting them in chat or memory files. If nothing durable came up, it writes nothing durable. The guardrail on explicit updates exists for a reason. Vague or accidental wording should not mutate the layer that follows you across every chat. @@ -55,7 +55,7 @@ The guardrail on explicit updates exists for a reason. Vague or accidental wordi - Decisions, conventions, and patterns inside a project. - The recent state of each project's work, in working memory. -## What does not get saved +## What memory is designed to omit - Greetings and small talk. - Temporary instructions for a single chat. diff --git a/content/docs/features/open-architecture.mdx b/content/docs/features/open-architecture.mdx index 6f1d645..ed88de3 100644 --- a/content/docs/features/open-architecture.mdx +++ b/content/docs/features/open-architecture.mdx @@ -5,9 +5,9 @@ icon: blocks description: Keep a usable copy of your work and move it through documented files, links, and APIs. --- -Fluso keeps core work in ordinary formats instead of locking every object behind one interface. You can download project files, move Agent definitions, export operational records, and read conversation history through the API. +Fluso keeps core work in ordinary formats instead of locking every object behind one interface. You can download project files, share Agent setups, and read conversation history through the API. -Different exports serve different purposes. A project ZIP is a file backup; an Agent YAML is a reusable setup; a shared chat is a reviewable snapshot. +Different exports serve different purposes. A project ZIP is a file backup; an Agent share is a reusable setup; a shared chat is a reviewable snapshot. ## What you can take out @@ -16,12 +16,9 @@ Different exports serve different purposes. A project ZIP is a file backup; an A | **Projects and files** | Open **Projects**, use the project's **••• → Export as zip**, or open a project and select **Export** | A ZIP of the project's regular files, their folder paths, `context.md`, and project metadata; empty folders are omitted | | **Individual files** | Open a project file and select **Download** | The original file in its stored format | | **Shared project files** | Open a project file, select **Share**, then create a link | A revocable public link to the selected file | -| **Generated documents and presentations** | Use the artifact's export menu | Documents as PDF, Word, HTML, or Markdown; presentations as PDF, PowerPoint, or a Google Slides copy | -| **Agents** | Open an Agent, select its name, then **Export YAML** | A portable `.agent.yaml` definition with the Agent's saved setup and workflow | -| **Agent review copies** | Open an Agent, select its name, then **Share** | A read-only link that another person can inspect and import as a separate Agent | +| **Generated documents and presentations** | Download the generated file from its artifact or project | The format Fluso created; ask for another format if needed and inspect the result | +| **Agent review copies** | Open the Agent menu, then **Share** | A revocable public snapshot of the setup and selected resources, which someone else can import as a separate Agent | | **Conversation history** | Open a chat and select **Share chat**, or read messages with the Threads API | A revocable public snapshot, or structured persisted messages through the API | -| **Audit logs** | In Fluso Admin, filter **Audit log**, then select **Export _N_ rows** | CSV containing the currently filtered rows from the latest 100 recorded identity and access events | -| **Usage records** | In Fluso Admin, open **Observability → Export CSV** | CSV of the recorded daily gateway cost and token totals shown in the 14-day view | Project ZIPs skip dotted runtime entries and symbolic links. They do not serve as a complete conversation archive. Use the [Threads and messages API](/developers/api-ref/threads-and-messages#read-message-history) when you need persisted chat records in a system you control. @@ -31,31 +28,24 @@ Open **Plugins → Skills** and select a skill to read its `SKILL.md`. This is t The skill document is view-only, and there is no one-click skill bundle export today. For a custom skill you own, copy its `SKILL.md` and keep its source files in your own version control before removing it from Fluso. Built-in and marketplace skills can be inspected in Fluso but are not exported as workspace-owned packages. -## What an Agent export leaves behind +## What an Agent share includes -Agent export and sharing deliberately omit: +An Agent share publishes its setup. You can also include selected custom skill folders, knowledge files, and custom connection settings. These selected resources become readable to anyone with the link. Credentials, conversation history, routines, and project ownership are not included. -- Workspace identities and credentials. -- App connection secrets. -- Chat history and deliveries. -- Project ownership and project files. -- Knowledge-file contents. -- Schedules, webhook triggers, evaluations, and version history. - -The export names omitted knowledge files so the recipient can add them again. Named skills remain references to review in the destination workspace; an Agent configured to use every skill imports with none selected. Apps must be reconnected. See [Agent versions](/developers/versions#move-an-agent-between-workspaces) for the full handoff flow. +Recipients connect their own Apps and review the available skills and files. See [Configuration and sharing](/developers/versions#move-an-agent-between-workspaces) for creating, updating, revoking, and importing a link. ## A practical handoff To hand a customer-support workflow to another team: -1. Export the support project as ZIP so they receive the runbooks and working files. -2. Export the Agent as YAML, or send its review link. -3. Share any example conversation as a snapshot, removing sensitive messages first. -4. Export the relevant filtered audit rows separately if the reviewer needs access evidence. -5. In the destination workspace, import the Agent, upload the project files, reconnect Apps, and run its evaluations before live use. +1. Export the support project as ZIP if they need its runbooks and working files. +2. Share the Agent setup, selecting only resources they may read. +3. Review any example conversation for sensitive information before sharing a snapshot. +4. In the destination workspace, import the Agent, upload the project files, and connect Apps. +5. Review approval settings and test the copy before live use. -These exports are independent snapshots. Later Fluso changes do not silently rewrite the copies you already saved. +These are independent snapshots. Later changes do not update downloaded or imported copies. Updating an Agent's published share changes what future visitors to that link receive. ## APIs for continuous access -Use the [API reference](/developers/api-ref/authentication) when a one-time download is not enough. The API exposes Agents and versions, projects and files, threads and messages, schedules, runs, and usage. Authenticate each request with a scoped bearer token and store only the data your integration needs. +Use the [API reference](/developers/api-ref/authentication) when a one-time download is not enough. The API exposes current Agent configurations, projects and files, threads and messages, schedules, runs, and usage. Authenticate each request with a bearer token and store only the data your integration needs. diff --git a/content/docs/features/skills.mdx b/content/docs/features/skills.mdx index 13a0bf7..863f8f7 100644 --- a/content/docs/features/skills.mdx +++ b/content/docs/features/skills.mdx @@ -64,7 +64,7 @@ Private enterprise skills use two pieces: 1. `SKILL.md` contains the routing description and operating instructions. 2. An authenticated private MCP server keeps sensitive code and credentials, then exposes the operations the skill needs. -The server must expose a publicly reachable HTTPS Streamable HTTP endpoint. "Private" here means access-controlled, not a `localhost` or private-network address. The workspace or organization network-egress policy, plus any provider policy applied to that origin, must allow it. +The server must expose a publicly reachable HTTPS Streamable HTTP endpoint. "Private" here means access-controlled, not a `localhost` or private-network address. The deployment's network-egress rules, user grants, and provider policies must permit access to that origin. Access follows the server's authentication and the workspace's MCP tool policy. Each tool's **Allow**, **Ask**, or **Deny** rule controls how calls proceed. Installing the skill does not override server access. See [Apps & MCP](/features/mcp#tool-permissions) to connect the server and set its tool rules. diff --git a/content/docs/features/tasks.mdx b/content/docs/features/tasks.mdx index 3d44b79..8aa4e63 100644 --- a/content/docs/features/tasks.mdx +++ b/content/docs/features/tasks.mdx @@ -7,7 +7,7 @@ description: Fluso's task list, mostly populated automatically from email, meeti A task in Fluso is a small piece of follow-up that came out of your day. A reply someone is waiting for. A meeting to confirm. A decision someone asked you for. Fluso watches the apps you have connected and turns the action items into tasks for you. -You spend your time on the work. The list mostly keeps itself. +Background extraction depends on the connected apps, deployment settings, and runtime availability. It is disabled while [confidential mode](/features/confidential) is on. You can still work with tasks explicitly in chat. ## Where tasks come from @@ -15,7 +15,7 @@ Most tasks arrive without you asking. Fluso pulls them out of your connected app **Email.** A message that asks you to do something becomes a task on you. The thread is linked, so the original is one click away. -**Meetings.** Process a meeting transcript and every action item becomes a task. Items on you sit in your list. Items on someone else are tagged with the person. +**Meetings.** Ask Fluso to process a meeting transcript and create tasks from its action items. Items on you sit in your list. Items on someone else are tagged with the person. **Slack.** A message in a channel you have pointed Fluso at, asking for a decision or a follow-up, ends up as a task. The thread is linked back. diff --git a/content/docs/going-deeper.mdx b/content/docs/going-deeper.mdx index 183edb1..f6ebdd4 100644 --- a/content/docs/going-deeper.mdx +++ b/content/docs/going-deeper.mdx @@ -21,7 +21,7 @@ A few patterns worth practising. **Queue while Fluso works.** Press Enter during a run and the message waits in the editable follow-up queue. For a correction that cannot wait, use **Send now** on its queue row to steer the live run. The full set of controls is in [While Fluso is working](/features/chat#while-fluso-is-working). -**Reference earlier work.** Threads remember everything. *"Reply to the one from Legal"* makes sense after Fluso has summarised your inbox. *"Use the same tone as my last email to the team"* works because Fluso has the previous draft in context. +**Reference earlier work.** Threads keep their conversation history, while long model contexts may be summarized. *"Reply to the one from Legal"* makes sense after Fluso has summarised your inbox. *"Use the same tone as my last email to the team"* works because Fluso has the previous draft in context. **Set the audience and the tone.** "For technical buyers" produces different writing from "for board members" produces different writing from "for a customer success follow-up". The default audience is generic. If you tell it the audience, it writes for them. @@ -29,7 +29,7 @@ A few patterns worth practising. [Projects](/features/projects) are folders for context. Most people create one and forget. The better habit: -A project per major area of work. Acme Corp, Q3 Launch, Board Reporting, Personal. When you're inside a project, Fluso scopes its memory and search to that project's content. Asking "what's the status?" inside the Acme project gets the Acme answer; same prompt outside any project gets a generic everything-bag. +A project per major area of work. Acme Corp, Q3 Launch, Board Reporting, Personal. When you're inside a project, Fluso scopes its memory and search to that project's content. Asking "what's the status?" inside the Acme project gets the Acme answer; use **Home** for general work. A Home chat does not automatically receive every project's memory. Add stable project context when the background is non-obvious. The simplest version: @@ -108,7 +108,7 @@ The pattern: name the inputs, name the output, let Fluso connect them. ## Approval discipline -Approval follows the effective tool and chat policy. With **Ask**, a read or write pauses on an approval card. A tool set to **Allow**, or a chat using **Don't ask permission**, can continue without a per-action prompt; **Deny** always blocks it. Keep external-facing write tools on **Ask** when you want to review each draft. +Approval follows the effective tool and chat policy. With **Ask me first** and an **Ask** tool rule, a read or write pauses on an approval card. A tool set to **Allow**, or a chat using **Allow everything**, can continue without a per-action prompt; **Deny** always blocks it. Use **Ask me first** and keep external-facing write tools on **Ask** when you want to review each draft. The instinct on day one is to read every draft carefully. By day twenty, you will be tempted to wave things through. Don't. @@ -122,21 +122,19 @@ The instinct on day one is to read every draft carefully. By day twenty, you wil ## For teams -Team plans add shared context. The patterns that matter: +Projects and memory belong to the signed-in account. A standard plan does not create a shared project or shared knowledge graph for colleagues. -**Shared projects** for cross-team work. Both you and your colleague see the same memory, the same files, the same task list, scoped to that project. The Acme project becomes a real shared brain instead of two separate ones. +Share a reviewed conversation or file link, export project files, or share an Agent setup for someone else to import. These are separate copies or published snapshots, not collaborative access to your live workspace. See [Open architecture](/features/open-architecture). -**Shared knowledge graph** for the team. Decisions made in any team member's meetings are visible to everyone (within the shared project). Useful for executive teams; less useful for projects with strict need-to-know. - -**Admin visibility, not content access.** The current [Admin panel](/admin-panel) covers identity and access records, recorded usage, runtime status, and network policy. Connected-app inventory, seat controls, and a complete organization-wide audit require their owning Enterprise integrations. The admin UI does not expose messages, files, or knowledge graphs. +For organization access, deployment boundaries, or shared-work requirements, [contact the Fluso team](mailto:sales@premai.io) to scope the setup. [Fluso Admin](/admin-panel) gives authorized operators usage and runtime controls without exposing workspace content. ## Things people miss A short list of features that are easy to overlook. -The slash commands inside chat: `/status` shows what Fluso is doing right now (useful when something's slow), `/schedules` lists pending scheduled actions, `/abort` stops the current run. +In desktop chat, use **Stop** to stop a run. -Saying *"new thread"* starts a fresh context. Useful when the conversation has drifted but you don't want to reach for the mouse. +Use **New chat** when the conversation has drifted and you want a fresh thread. You can attach files to messages. PDFs, images, CSVs, audio. *"Summarise this"*, *"what does this chart show?"*, *"make a deck from this data"*. The file becomes part of the prompt. diff --git a/content/docs/index.mdx b/content/docs/index.mdx index 052b6ce..69ff439 100644 --- a/content/docs/index.mdx +++ b/content/docs/index.mdx @@ -35,7 +35,7 @@ Pick a workflow that matches a problem you have right now. Each one is a story, A CEO ask on Monday, deck ready by 10am. - Bug report to merged PR in fifteen minutes. + Bug report to a pull request you can review. diff --git a/content/docs/integrations/github.mdx b/content/docs/integrations/github.mdx index c58d66b..11a289e 100644 --- a/content/docs/integrations/github.mdx +++ b/content/docs/integrations/github.mdx @@ -13,7 +13,7 @@ If you don't write code, the rest of this page is safely ignorable. If you do, t Open **Plugins** in the sidebar, click **Add MCP**, and click **Connect** on **GitHub**. GitHub's OAuth flow opens. -Choose repository scope on GitHub's screen: specific repositories or all repositories you have access to. Either is fine, and you can change the set later from your GitHub settings without reconnecting. +Review the permissions GitHub requests. Repository visibility depends on that authorization, your own repository access, and organization restrictions. The available controls depend on the authorization flow; do not assume it offers a per-repository selector. Read access is what lets Fluso browse code, answer architecture questions, and review PRs. Write access to issues and PRs is what lets it file issues, open PRs, and leave comments, subject to the effective tool and chat policy. @@ -58,7 +58,7 @@ Issues: > *"What issues are assigned to me this sprint?"* - Keep GitHub write tools on **Ask** when you want every diff or comment shown before the action runs. **Allow** or **Don't ask permission** can continue without a per-action prompt; **Deny** blocks the write. + Use **Ask me first** and keep GitHub write tools on **Ask** when you want every diff or comment shown before the action runs. **Allow** or **Allow everything** can continue without a per-action prompt; **Deny** blocks the write. ## A small thing that makes generated code much better @@ -86,7 +86,7 @@ You can also revoke from [GitHub → Settings → Applications](https://github.c ## Troubleshooting - Rerun authorisation and add the repo to the allowlist, or grant access to all repositories. + Check that your GitHub account can access it, that the authorization covers private repositories, and that the organization permits the app. Reconnect if the required permissions changed. Your organisation may require an admin to approve the OAuth app. Check **Org → Settings → Third-party access**. @@ -102,6 +102,6 @@ You can also revoke from [GitHub → Settings → Applications](https://github.c The code skills (Q&A, PR review, scaffolding, bug fixes) and others. - Bug report to merged PR in fifteen minutes. + Bug report to a pull request you can review. diff --git a/content/docs/integrations/gmail.mdx b/content/docs/integrations/gmail.mdx index 359df7b..eca70f8 100644 --- a/content/docs/integrations/gmail.mdx +++ b/content/docs/integrations/gmail.mdx @@ -60,9 +60,9 @@ Follow-ups: ## How permissions actually behave -Reading happens when you ask for it (*"summarise my inbox"*) and continuously in the background for auto-task extraction. Messages are processed for the response and not stored beyond what's referenced in your knowledge graph and tasks. +Reading happens when you ask for it (*"summarise my inbox"*) and during enabled background task extraction. Retrieved messages can be retained in conversation history, tasks, and indexed context. Disconnecting an app removes its access; it does not erase content already saved in Fluso. -Keep Gmail send tools on **Ask** when you want every draft shown before it sends. **Allow** or **Don't ask permission** can continue without a per-action prompt; **Deny** blocks the send. There is no separate batch-send mode that overrides the effective policy. +Use **Ask me first** and keep Gmail send tools on **Ask** when you want every draft shown before it sends. **Allow** or **Allow everything** can continue without a per-action prompt; **Deny** blocks the send. There is no separate batch-send mode that overrides the effective policy. Header metadata is used for categorisation and handled under the same subprocessor controls as other requested email content. @@ -81,7 +81,7 @@ You can also revoke directly from [Google Account → Security → Third-party a OAuth tokens occasionally expire. In **Plugins**, open the row's three-dot menu and click **Reconnect**. - Auto-task extraction runs periodically and learns the shape of your inbox over a couple of days. You can also force a sweep with *"Scan my inbox for tasks."* + Background extraction depends on the connection, runtime availability, and deployment settings. It is disabled in confidential mode. Check the Tasks sync activity for errors. You can also ask *"Scan my inbox for tasks"* to request work in the current chat. ## See also diff --git a/content/docs/integrations/google-calendar.mdx b/content/docs/integrations/google-calendar.mdx index 4594794..49bc404 100644 --- a/content/docs/integrations/google-calendar.mdx +++ b/content/docs/integrations/google-calendar.mdx @@ -9,13 +9,13 @@ Calendar pairs naturally with Gmail. Together they enable the morning brief, mee ## What changes once it's on -Calendar enables several skills that activate automatically — see [Skills](/features/skills) for the full catalog. The short version: see your schedule with context, find time without playing Tetris, schedule meetings from chat, and have Fluso prep you before a call. Tasks with deadlines fold into the calendar view. +Calendar enables several skills that activate automatically — see [Skills](/features/skills) for the full catalog. The short version: see your schedule with context, find time without playing Tetris, schedule meetings from chat, and have Fluso prep you before a call. Ask Fluso to compare task deadlines with your calendar; creating or changing a calendar event is a separate action. ## Setup Calendar comes in through the **Google Workspace** app — the same connection that covers Gmail, Drive, Docs, and the rest of the suite. If you already connected it for Gmail, Calendar is on and there is nothing to do here. -Otherwise: open **Plugins** in the sidebar, click **Add MCP**, and click **Connect** on **Google Workspace**. Sign in with the Google account whose calendar you want Fluso to run, and approve the permissions on Google's screen. Reading is what shows your schedule and availability; write access is what lets Fluso create and modify events when you ask. +Otherwise: open **Plugins** in the sidebar, click **Add MCP**, and click **Connect** on **Google Workspace**. Sign in with the Google account whose calendar you want Fluso to run, and approve the permissions on Google's screen. Reading is what shows your schedule and availability; write access is what lets Fluso create and modify events when you ask. Use **Ask me first** and keep calendar write tools on **Ask** to review invitations or changes before they are sent. ## Prompts that work well diff --git a/content/docs/integrations/slack.mdx b/content/docs/integrations/slack.mdx index e13ed94..f5602f7 100644 --- a/content/docs/integrations/slack.mdx +++ b/content/docs/integrations/slack.mdx @@ -48,7 +48,7 @@ Posting: > *"Post a status update in #partnerships about Acme."* - Keep Slack write tools on **Ask** when you want every draft shown before it posts. **Allow** or **Don't ask permission** can continue without a per-action prompt; **Deny** blocks the post. + Use **Ask me first** and keep Slack write tools on **Ask** when you want every draft shown before it posts. **Allow** or **Allow everything** can continue without a per-action prompt; **Deny** blocks the post. ## Cross-app workflows @@ -72,7 +72,7 @@ You can also revoke from your Slack workspace at **Settings → Integrations → ## Troubleshooting - Add the Fluso bot to the private channel, or rerun the authorisation and select the channel. + With **Slack**, check that the connected user belongs to the private channel and the authorization permits reading it. With **Slackbot**, invite the bot to the channel. Workspace policy can restrict either connection. Connect each separately. Fluso treats them as independent. Disambiguate in the prompt: *"What did I miss in [workspace] #channel?"* diff --git a/content/docs/interface/composer.mdx b/content/docs/interface/composer.mdx index 66a18f0..d27e70f 100644 --- a/content/docs/interface/composer.mdx +++ b/content/docs/interface/composer.mdx @@ -177,19 +177,18 @@ The mode button on the composer toolbar sets reasoning effort for the current ch | **Deep** | complex tasks, reviews, planning | | **Max** | the hardest problems, when you would rather wait | -The choice belongs to the chat, not the app, so a quick lookup and a long refactor can sit side by side in your sidebar at different settings. In [confidential mode](/features/confidential) the reasoning level is fixed, so Max is not offered there. +The choice belongs to the chat, not the app, so a quick lookup and a long refactor can sit side by side in your sidebar at different settings. In [confidential mode](/features/confidential) the reasoning level is fixed, so Max is not offered there. Quick still turns reasoning off. ## What Fluso may do on its own -Beside the mode button, one control sets how much Fluso does before checking with you. `⌘⇧\` steps through the three levels. +Beside the mode button, one control sets how much Fluso does before checking with you. `⌘⇧\` switches between the two modes. | Level | Behaviour | | --- | --- | -| **Ask me first** | asks before reaching the web and before any connected app | -| **Allow web** | searches the web on its own, still asks before connected apps | -| **Allow everything** | acts without asking | +| **Ask me first** | asks for connected-app tools that do not already have an effective Allow rule | +| **Allow everything** | permits connected-app tools automatically, including Ask rules; Deny rules still block | -Your choice sticks as the default for new chats. [Approvals and permissions](/features/approvals) covers the approval cards, saved tool rules, and what an organization policy can override. +In an existing chat, your choice sets that chat's override. On a new-chat screen it changes the account default, which also applies to chats without an override. Read-only tools follow each connection's settings. [Approvals and permissions](/features/approvals) covers the approval cards, saved tool rules, and network-access boundaries. ## Dictating diff --git a/content/docs/interface/sidebar.mdx b/content/docs/interface/sidebar.mdx index 8a38497..d5bbb8f 100644 --- a/content/docs/interface/sidebar.mdx +++ b/content/docs/interface/sidebar.mdx @@ -155,7 +155,7 @@ Rest the pointer on a row for a moment and a card appears with the project it be ## Working on several chats at once -Press and hold a row, or `⌘`-click and `⇧`-click, to start a selection. Every row grows a checkbox and a bar appears at the foot of the sidebar, counting what you have picked and offering the actions that apply to all of it: move, pin, archive, label, delete. +Press and hold a row, or `⌘`-click and `⇧`-click, to start a selection. Every row grows a checkbox and a bar appears at the foot of the sidebar, counting what you have picked and offering the actions that apply to all of it: pin, archive or restore, label, and delete. A selection is not confined to one folder. Tick chats in three different projects and the bar treats them as one set, which is the fastest way to clear out a week's worth of scattered one-off chats. diff --git a/content/docs/meta.json b/content/docs/meta.json index 7435c5a..57cb8db 100644 --- a/content/docs/meta.json +++ b/content/docs/meta.json @@ -22,8 +22,6 @@ "...resources", "---Release notes---", "release-notes", - "---Remote access---", - "...remote", "---Workflows---", "...workflows" ] diff --git a/content/docs/quickstart.mdx b/content/docs/quickstart.mdx index 1693b97..85d423f 100644 --- a/content/docs/quickstart.mdx +++ b/content/docs/quickstart.mdx @@ -21,9 +21,7 @@ In this quickstart, you will: ## Before you start -Fluso runs on macOS. Download it from [fluso.ai](https://fluso.ai/) and install the app. - -Windows and iOS are coming. For now, you need a Mac. +This guide follows the desktop app, available for macOS and Windows. Download it from [fluso.ai](https://fluso.ai/) and install it. Fluso is also available on the [iOS App Store](https://apps.apple.com/in/app/fluso/id6780937477); mobile controls differ from the desktop steps below. Pick one project before you open the app. Good first projects include: diff --git a/content/docs/remote/telegram.mdx b/content/docs/remote/telegram.mdx deleted file mode 100644 index c3f1d85..0000000 --- a/content/docs/remote/telegram.mdx +++ /dev/null @@ -1,136 +0,0 @@ ---- -title: Telegram -sidebarTitle: Telegram -icon: send -description: Fluso's Telegram bot. Sign in once, then chat with Fluso from a private Telegram conversation. ---- - -Fluso has a Telegram bot for the times you are away from your Mac. Sign in once with your Fluso account, and the bot is the same Fluso you use on the Mac app, just over Telegram. - -The bot only works in private chats. One Telegram account, one Fluso. It will not work in group chats. - -## Find the bot in the Mac app - -The easiest way to get to the bot is from inside Fluso: - -1. In the Fluso Mac app, click your name at the bottom left. -2. Pick **Settings** from the menu. -3. Scroll to the bottom of Settings. You will see a **Telegram** panel with a QR code and an **Open Telegram** button. -4. Scan the QR code with your phone, or click **Open Telegram** if Telegram is already on your computer. - -Either way, you land in a private chat with `@fluso_bot`. That is the bot. - -## Sign in - -Once you are in the chat with `@fluso_bot`: - -1. Send `/login`. -2. Tap the **Sign in** button the bot sends back. -3. Finish signing in to Fluso in your browser. -4. Telegram opens again and the bot confirms you are signed in. - -You will get signed out after a while. If the bot ever asks you to sign in again, send `/login` once more. - -## Connect your apps - -Before Fluso can read your Gmail, post in your Slack, or open issues for you, it needs to be connected to those apps. You only have to do this once per app. Connections you make here on Telegram are shared with the Mac app, so you do not have to set them up twice. - -- `/connect` shows the list of apps you can connect. -- `/connect ` connects an app by name. Try `/connect google`, `/connect github`, `/connect slack`, or `/connect linear`. - -When you connect **Google**, you get all of Google in one go: Gmail, Drive, Docs, Sheets, Slides, Calendar, Meet, and Tasks. You do not need to connect Gmail or Calendar separately. - -`/status` tells you what is connected right now. `/disconnect` removes a connection. `/apps` shows the full list of apps you can connect. - -## What to ask - -Once you are signed in and have at least one app connected, ask in plain English. - -> *"Summarise my unread Gmail from today."* - -> *"Find the latest issue assigned to me in Linear."* - -> *"Search Slack for the deployment thread from yesterday."* - -> *"Read this document and pull out the key numbers."* - -> *"Use this voice note as my instruction."* - -If you ask for something that needs an app you have not connected yet, the bot will say so. Send `/connect ` and ask again. - -Connector writes in Telegram follow the same effective **Allow**, **Ask**, or **Deny** policy as the app. With **Ask**, the bot shows an approval card and waits for your decision. **Allow** or **Don't ask permission** can continue without a per-action prompt; **Deny** blocks the action. - -## Fast mode - -Send `/fast` to switch the current Telegram conversation to Fast mode. Fast mode turns reasoning off for quick, lighter work and can use fewer tokens. - -Send `/fast` again in the same Telegram conversation to switch back to High mode. The bot sends a short confirmation each time, so you can see whether Fast mode is on or off. - -This is conversation-specific, not an account setting. `/newchat` starts a fresh Telegram conversation back in High mode. - -Telegram mode and app mode are separate. Using `/fast` in Telegram does not change any chat in the app, and changing the app's High/Fast dropdown does not change Telegram. - -## Files, images, voice - -You can send more than just text: - -- **Files and documents** — Fluso saves them and reads them for you. -- **Images** — same thing. Fluso can look at the picture and answer questions about it. -- **Voice or audio** — Fluso treats it as your instruction. The reply may come back as voice or as text. -- **Video and video notes** — these work too. -- **Animated and video stickers** — these are not supported. - -Very large files may not go through. If a file is rejected, send a smaller version or split it into parts. - -## Conversation controls - -| Command | What it does | -|---|---| -| `/newchat` | Start a fresh conversation. Your files are kept. | -| `/fast` | Toggle the current conversation between Fast and High. `/newchat` resets it to High. | -| `/reset` | Wipes everything: files, chat history, and what Fluso has learned. Cannot be undone. | -| `/abort` | Stop what Fluso is doing right now. | -| `/schedules` | Show anything Fluso has scheduled, if any. | -| `/logout` | Sign out of the Telegram bot. | -| `/help` | Show the bot's commands. | - - - `/reset` cannot be undone. It clears your files, chat history, and everything Fluso has remembered on Telegram. If you only want a fresh conversation, use `/newchat` instead. - - -## While Fluso is working - -A long answer may arrive as a few Telegram messages in a row instead of one big message. Any files Fluso creates for you will arrive as attachments. - -If Fluso is still starting up, the bot will say so and ask you to try again in about a minute. - -## Troubleshooting - - - - You have been signed out. Send `/login` and finish the browser sign-in to start again. - - - Send `/connect `, then ask your original question again. - - - The file is too big. Send a smaller version, or split it into parts. - - - Send `/abort` to stop it. If the bot says it is still loading, wait a moment and try again. - - - Send `/newchat` to start fresh. Your files are kept. Only use `/reset` if you want to wipe everything. - - - -## See also - - - - What app connections are and how to manage them. - - - How chat works in Fluso. Telegram works the same way. - - diff --git a/content/docs/resources/faq.mdx b/content/docs/resources/faq.mdx index fe6e722..3490282 100644 --- a/content/docs/resources/faq.mdx +++ b/content/docs/resources/faq.mdx @@ -9,13 +9,13 @@ description: The questions that come up most often. What Fluso is, how it works, - An AI assistant that connects to your apps — Gmail, Calendar, Slack, GitHub, and a hundred more — and helps you manage work through conversation. It reads your inbox, drafts replies, runs your calendar, creates documents, researches topics, writes code, and remembers everything along the way. + An AI assistant that connects to your apps — Gmail, Calendar, Slack, GitHub, and a hundred more — and helps you manage work through conversation. It reads your inbox, drafts replies, runs your calendar, creates documents, researches topics, writes code, and can recall saved preferences and project context. - No. A chatbot answers questions. Fluso performs actions: sending mail, scheduling, opening PRs, generating files. It works across the apps where your work already happens, not just inside a chat window. + No. A chatbot answers questions. Fluso performs actions: sending mail, scheduling, opening PRs, generating files. External writes follow your [approval settings](/features/approvals); use **Ask me first** and Ask rules to review them before they run. - Those are general-purpose assistants in a chat window. Fluso connects directly to your tools, builds a private knowledge graph from your work, takes action across apps, and remembers what's happened. It's an executive assistant, not a conversational AI. + Fluso focuses on connected-app work, project files, tasks, and persistent workspace context. Compare the workflows and permissions you need; other assistants can also offer tools and memory. Anyone who loses too much time to email, meetings, research, content creation, or context-switching. Founders, executives, developers, PMs, researchers, and teams all use it. @@ -55,7 +55,7 @@ description: The questions that come up most often. What Fluso is, how it works, It asks clarifying questions: *"Which project?"* or *"What format?"* Answer for a better result. - Fluso runs on macOS today. Download it from [fluso.ai](https://fluso.ai/). Windows and iOS are coming later. + Fluso is available for macOS and Windows from [fluso.ai](https://fluso.ai/), and on the [iOS App Store](https://apps.apple.com/in/app/fluso/id6780937477). Some setup controls are desktop-only. Primarily English, but it understands and responds in many. Quality varies by language and task. @@ -76,16 +76,16 @@ description: The questions that come up most often. What Fluso is, how it works, Deleting your account deletes your dedicated sandbox and all associated data, including your files, conversations, connected-account credentials, and other records held by Fluso. We do not retain your data after account deletion. - It reads emails when you ask it to (e.g., *"summarise my inbox"*) and as part of auto-task extraction. It does not keep a separate mailbox copy. See [Legal](/resources/legal) for Fluso's privacy policy. + It reads email within the permissions you grant, on request and during enabled background task extraction. Retrieved content can become part of conversation history, tasks, or indexed context. See [Legal](/resources/legal) for Fluso's privacy policy. - Gmail send tools follow your effective **Allow**, **Ask**, or **Deny** policy. Use **Ask** to review each draft before it sends; **Allow** or **Don't ask permission** can continue without a per-action prompt. + Gmail send tools follow your effective **Allow**, **Ask**, or **Deny** policy. Use **Ask me first** with an **Ask** rule to review each draft before it sends; **Allow** or **Allow everything** can continue without a per-action prompt. In your isolated workspace on encrypted infrastructure. Files, conversations, tasks, and the knowledge graph are private to you. - Yes. Individual entries, connected apps' data (tokens destroyed), or the entire account. Deletion is permanent. + You can remove individual workspace files and disconnect apps, or request account deletion through support. Deletion is permanent. No. Your private data is never used to train AI models. @@ -101,16 +101,16 @@ See [Legal](/resources/legal) for Fluso's privacy policy. - Yes. Free includes full chat, 3 connected apps, 1 project, 100 messages a month, and the basic skills. Enough to decide whether it works for you. + Yes. The free plan is called **Basic** in the app. It includes chat and workspace tools with a smaller usage allowance. Limits use six-hour and weekly windows, rather than a fixed monthly message count. See [Pricing](/resources/pricing). - - Yes. Fourteen days, no card. + + New accounts receive 30 days of Sponsored Confidential access without a paid subscription. That grant is separate from any trial offered at checkout. Check **Settings → Plans** for your effective plan and expiry; confidential inference still needs to be enabled in Settings. - You're notified when you're getting close. Upgrade to continue. Your data is preserved. + If either usage window is exhausted, Fluso stops new runs and shows the reset time. Wait for that window to reset or choose a higher plan. Reaching a usage limit does not delete your work. - Yes. Pro access stays until the end of the billing period, then reverts to Free. + You can cancel from your account billing controls. Paid access continues until the end of the paid period. A separate sponsorship keeps its own expiry; otherwise the account returns to Basic. @@ -123,13 +123,13 @@ Plan details on [Pricing](/resources/pricing). Specialised capabilities: creating PDFs, generating images, processing meetings, deep research. They activate when you ask for something they can do. - No. Fluso picks the right skill based on the request. + Built-in skills are available automatically. You can install marketplace skills or create your own from **Plugins → Skills**. Fluso selects from the skills available to your account when a request matches. Yes. Open **Plugins → Skills**, click **Add skill** at the top right, and pick **Build with Fluso**. The skill-creator skill takes it from there in chat: it asks what workflow the skill should handle, what inputs it takes, what shape the output should have, and which tools or apps are involved, then writes the skill and adds it to **My Skills**. See [Skills](/features/skills#building-your-own) for the full flow. - - Free includes the document-shaped ones: PDFs, Word, decks, spreadsheets. Pro adds image generation, deep research with citations, meeting intelligence, video summaries. + + The current skill catalog is shared across plans; usage limits still apply. Skills can require connected apps or other tools. Image generation is unavailable while confidential mode is enabled. See [Skills](/features/skills). @@ -140,12 +140,12 @@ Plan details on [Pricing](/resources/pricing). Check Google Workspace is connected (**Plugins**). Try reconnecting from the row's menu. If the issue persists, you may have hit a Gmail API rate limit. Wait a few minutes. - Start a new thread (the **+** button) if the conversation has drifted. *"Forget the context so far and start fresh on this topic"* also works. Being more specific in the request usually helps. + For an ordinary chat, start a new conversation with **New chat** when the topic has changed. Asking it to ignore earlier messages does not delete that history. Saved Agents keep one main conversation; see [Threads and contexts](/developers/threads-and-contexts) for separate testing or delegated work. Refresh the page or reconnect. OAuth tokens occasionally expire. **Plugins** → row menu → **Reconnect**. - [support@premai.io](mailto:support@premai.io). Pro gets priority email. Team gets priority chat. Enterprise gets dedicated support. + [support@premai.io](mailto:support@premai.io). For support commitments in a custom deployment, check your Enterprise agreement. diff --git a/content/docs/resources/pricing.mdx b/content/docs/resources/pricing.mdx index 2f4ac92..d4c9994 100644 --- a/content/docs/resources/pricing.mdx +++ b/content/docs/resources/pricing.mdx @@ -2,141 +2,81 @@ title: Pricing sidebarTitle: Pricing icon: credit-card -description: Compare plan limits, storage, automation, and workspace controls. +description: Current plans, usage windows, billing, and confidential access. --- -Four plans. Free is enough to try Fluso on real work. Plus is for daily use. Pro adds heavier automation and confidential computing. Enterprise is the path for custom deployments, data residency, and server-integrated identity or audit work. +Fluso's current personal plans are Basic, Plus, Pro, and Confidential. Basic is the free plan. Open **Settings → Plans** to see your effective access, current usage, and the offers available to your account. -Fluso uses only open-source models across all features, including Agent Studio. Your data never trains shared models. You get roughly 3× the tokens of equivalent closed-source assistants on the same task. +Fluso uses only open-source models across all features. Your data is not used to train shared models. ## Plans - - - **Free forever** - - Enough to try Fluso on real work. - - Full workspace access - - Core model - - Limited apps - - Dedicated sandbox - - 1 GB storage - - Automated obligation detection runs once - - Automated task creation runs once - - European hosting - - - **$19/user/month** - - For Fluso as your daily assistant. Most people start here. - - Everything in Free - - Always-on workspace. Never sleeps. - - Significantly more tokens - - All apps - - Artifact generation - - Skills Marketplace - - Obligation detection every 12 hours - - Task creation every 12 hours - - 10 GB storage - - - **$99/user/month** - - For heavy automation and sensitive work. - - Everything in Plus - - 20× the tokens - - Constant obligation detection - - Constant task creation - - Confidential computing - - Unlimited meeting notes - - Priority support - - 10 GB storage - - - **Custom pricing** - - For organisations with custom needs. - - Everything in Pro - - Server-integrated identity (implementation scoped) - - Dedicated account executive - - Dedicated support - - Custom obligation detection - - Custom data retention - - Server-backed audit logging (implementation scoped) - - Custom skills - - +| Plan | Monthly price | Usage allowance | Confidential mode access | +|---|---|---|---| +| Basic | Free | For light, occasional use | No | +| Plus | $19 | Higher than Basic | No | +| Pro | $99 | Higher than Plus | No | +| Confidential | $119 | Higher than Pro | Yes, enable it in Settings | +| Enterprise | Custom | Agreed for the deployment | Agreed for the deployment | + +Prices above are the current monthly personal-plan prices. Checkout shows the applicable trial, tax, billing date, and total before you subscribe. + +Basic runtimes can sleep when idle and resume when you return. Paid plans keep the runtime available for ongoing work, subject to maintenance and service availability. + +The current app does not divide its skill catalog into separate Free and Pro catalogs. Skills, files, connected apps, and background work still depend on their own permissions, configuration, and available usage. Image generation and background task extraction are disabled while confidential mode is enabled. + +## Usage limits + +Usage is measured in **six-hour** and **weekly** windows. If either window is exhausted, Fluso blocks new runs and shows when that window resets. You can wait for the reset or choose a plan with a higher allowance. + +These are usage allowances, not a fixed number of monthly messages or a guaranteed number of tokens per task. Long conversations, model output, and multi-step work use different amounts. The app shows the remaining percentage and reset time for each window. + +Reaching a usage limit does not delete your files or conversations. Storage has a separate limit; an upload or write can fail even when inference usage remains. + +## Sponsored Confidential + +An active **Sponsored Confidential** grant provides Confidential access until its displayed expiry. New accounts receive an initial 30-day grant. A sponsorship is an entitlement from the Fluso team, separate from a paid subscription or a checkout trial. - **Enterprise.** Prem has attained SOC 2 Type II. [Review the current security posture.](https://www.premai.io/security-at-prem) + **Pro does not include confidential mode.** A Pro subscriber can have a separate Sponsored Confidential grant. When that grant expires, Pro alone does not keep confidential access. Sponsorship does not cancel or pause an existing paid subscription. -## What's in every plan - -A few things hold regardless of plan. - -- **Open-source models only.** All Fluso features, including Agent Studio, use open-source models. -- **European hosting.** GDPR-aligned by default. -- **3× more tokens** than equivalent closed-source assistants on a like-for-like task. -- **Your data is yours.** Nothing trains shared models. - -## What changes between plans - -| | Free | Plus | Pro | Enterprise | -|---|---|---|---|---| -| Price | $0 | $19/user/mo | $99/user/mo | Custom | -| Tokens | Core | Significantly more | 20× | Custom | -| Apps | Limited | All | All | All | -| Obligation detection | Once | Every 12 hours | Constant | Custom | -| Task creation | Once | Every 12 hours | Constant | Custom | -| Storage | 1 GB | 10 GB | 10 GB | Custom | -| Workspace | Sleeps | Always-on | Always-on | Always-on | -| Skills Marketplace | — | ✅ | ✅ | ✅ | -| Artifact generation | — | ✅ | ✅ | ✅ | -| Confidential computing | — | — | ✅ | ✅ | -| Unlimited meeting notes | — | — | ✅ | ✅ | -| Priority support | — | — | ✅ | Dedicated | -| SSO | — | — | — | Scoped integration | -| Audit logs | — | — | — | Scoped integration | -| Custom skills | — | — | — | ✅ | -| Custom data retention | — | — | — | ✅ | - -Obligation detection scans your connected apps for things you have committed to: replies expected, deadlines, action items. Task creation is the same pipeline writing them into your list. See [Tasks](/features/tasks) for what happens after. +Clerk's billing view describes your paid subscription. Fluso's **Settings → Plans** also accounts for sponsored access, so the two labels can differ. Check the sponsorship expiry as well as the billing renewal date. + +## Confidential mode + +Having access does not turn encrypted inference on automatically. With the **Confidential** plan or active **Sponsored Confidential** access, enable **Settings → Encrypted Inference**. + +Confidential mode processes model inference inside a hardware-isolated enclave. The Fluso runtime is separate from encrypted inference. See [Confidential mode](/features/confidential) for activation, limitations, and the trust boundary. + +## Enterprise + +Enterprise deployments are scoped with the Fluso team. Agree on deployment ownership, residency, retention, identity integrations, support, and any additional access requirements before treating them as available. + +Prem has attained SOC 2 Type II. See the [current security posture](https://www.premai.io/security-at-prem) and [deployment models](/deployment-models). + +You can create your own workspace skills from **Plugins → Skills**. Enterprise implementation work is a separate engagement with the team; see [Skills](/features/skills). ## Common questions - - Compared against equivalent closed-source assistants on a like-for-like task. The full methodology lives on the [pricing page](https://fluso.ai/pricing.html). - - - Fluso uses only open-source models across all features, including Agent Studio. - - Fluso Cloud stores workspace data in the EU by default. Model inference and connected-App processing have their own provider boundaries. Enterprise customers can scope alternative data residency. Your data is never used to train shared models. See [Legal](/resources/legal) for Fluso's privacy policy. - - - Plus is the daily-driver tier: all apps, the Skills Marketplace, artifact generation, obligation and task automation every 12 hours. Pro raises tokens 20×, runs that automation constantly, lifts the meeting-notes cap, and adds confidential computing. Move to Pro when the 12-hour cadence or the Plus token allowance starts being the bottleneck. + Fluso Cloud stores workspace data in the EU by default. Model inference and connected apps have their own processing boundaries. Enterprise deployments can scope alternative residency. See [Legal](/resources/legal). - - Yes. Upgrade or downgrade from your account settings. Upgrading is immediate. Downgrading keeps your data but premium features come off at the next billing cycle. + + Pro gives intensive work more usage headroom than Plus. It does not add confidential mode. Choose Confidential if you need that access after a sponsorship ends. - - On Pro and Enterprise, Fluso runs your workload in a hardware-isolated environment so the model provider cannot read it. Useful when the work itself is sensitive. The technical details are on the [pricing page](https://fluso.ai/pricing.html). + + Use your account's billing controls. Review the effective date and charge shown before confirming. Paid access continues through the paid period after cancellation; a separate sponsorship keeps its own expiry. - - Custom data retention is part of the Enterprise scope. Governance records persist the configured identity and access history, but Microsoft Entra metadata does not verify a directory or provide SSO by itself. Prem has attained SOC 2 Type II. [Review the current security posture.](https://www.premai.io/security-at-prem) + + No. Background extraction depends on connected apps, deployment settings, runtime availability, and service health. It is disabled in confidential mode. Check [Tasks](/features/tasks) for sync activity and explicit task requests. - - Custom skills are part of the Enterprise tier and are built with the Fluso team. For workspace-level skill creation on Plus and Pro, see [Skills](/features/skills). - - - Yes. [Email us](mailto:sales@premai.io) and tell us about your organisation. + + [Email the team](mailto:sales@premai.io) with your requirements and organization details. ## Get started -Free forever, no card. [Download Fluso for Mac.](https://fluso.ai/) - -For a custom setup, [get in touch.](mailto:sales@premai.io) +[Download Fluso](https://fluso.ai/). For account or billing questions, contact [support@premai.io](mailto:support@premai.io). diff --git a/content/docs/workflows/content-launch.mdx b/content/docs/workflows/content-launch.mdx index 8b6d377..9f0cd6f 100644 --- a/content/docs/workflows/content-launch.mdx +++ b/content/docs/workflows/content-launch.mdx @@ -23,6 +23,8 @@ Post comes back. You read it, drop in the actual customer quote you have on hand ## Social graphics +Image generation requires standard inference. It is unavailable while [confidential mode](/features/confidential) is on. + > *"Generate five social media graphics for the DataLens launch. 1080×1080, brand colours, featuring key stats: 'Real-time analytics', '10x faster insights', 'No SQL required'."* Five variants generated. You pick three. Done. diff --git a/content/docs/workflows/dev-bug-fix.mdx b/content/docs/workflows/dev-bug-fix.mdx index 6da3f02..80ce5a7 100644 --- a/content/docs/workflows/dev-bug-fix.mdx +++ b/content/docs/workflows/dev-bug-fix.mdx @@ -2,7 +2,7 @@ title: A bug to a PR sidebarTitle: Bug → PR icon: bug -description: Bug report to merged PR in fifteen minutes. Fluso traces the code, finds the cause, writes the fix, opens the pull request for your review. +description: Trace a reported bug, prepare a fix, and open a pull request for review. --- Users report password reset emails aren't arriving. It's affecting customers. You need to find the bug and fix it. @@ -68,7 +68,7 @@ Always read the diff. Fluso writes good code, but you're still the engineer of r Drop a `context.md` in the repo describing your stack, conventions, and do-not-touch zones. Fluso reads and follows. The first PR after you add it will make the value obvious. - Keep GitHub write tools on **Ask** to stop on each PR or push and review the diff. **Allow** or **Don't ask permission** can continue without a per-action prompt. + Use **Ask me first** and keep GitHub write tools on **Ask** to stop on each PR or push and review the diff. **Allow** or **Allow everything** can continue without a per-action prompt. ## Related diff --git a/content/docs/workflows/knowledge-recall.mdx b/content/docs/workflows/knowledge-recall.mdx index 2653cf5..22147e4 100644 --- a/content/docs/workflows/knowledge-recall.mdx +++ b/content/docs/workflows/knowledge-recall.mdx @@ -42,17 +42,11 @@ You sound informed and prepared, because you are. The thing you would have forgo | Last contact | *"When did I last talk to the Stripe team?"* | | Relationship health | *"How's the Acme relationship going? Any red flags?"* | -## How recall scales over time +## What recall depends on -The graph builds. The longer you've been using Fluso, the deeper the recall. +Recall depends on the material available to the current project, saved preferences and context, working-memory summaries, and sources Fluso can retrieve through your connected apps. It does not become a complete archive automatically after a fixed number of weeks. -In week one, it can recall your frequent contacts and current projects. - -By the end of month one, key relationships have history, project status is real-time, your communication patterns are visible. - -At three months, Fluso starts surfacing patterns you wouldn't think to ask about: relationships you've gone quiet on, projects that are stalled, topics that keep coming up without resolution. - -After six months, it's institutional memory. *"What was the outcome of that vendor negotiation in January?"* gets a real answer, with citations. +Ask for source links when dates, decisions, or quotations matter. If something was never saved or the source is no longer accessible, provide it again. See [Memory](/features/memory) for the scope and limits. ## When recall is most valuable @@ -70,13 +64,13 @@ Gmail connected (see [Gmail](/integrations/gmail)). Calendar connected so meetin ## Privacy -The graph is yours alone. Lives in your isolated workspace. Never shared with other users. Never used to train models. Delete individual entries or wipe the whole thing whenever you want. See [Legal](/resources/legal) for Fluso's privacy policy. +Your workspace memory belongs to your account. Projects scope the context used in ordinary chats. Ask Fluso to read or correct saved preferences and project context; use source links to verify recalled facts. See [Legal](/resources/legal) for Fluso's privacy policy. ## Related - The full deep dive on the knowledge graph. + Preferences, project context, and working memory. Meeting prep is recall in action — see it in context. diff --git a/content/docs/workflows/meetings.mdx b/content/docs/workflows/meetings.mdx index 6fca7bf..8a7cdf2 100644 --- a/content/docs/workflows/meetings.mdx +++ b/content/docs/workflows/meetings.mdx @@ -7,13 +7,13 @@ description: The full lifecycle on a real Tuesday. Prep at 9:55, meeting at 10, The savings on meetings come from two places: the half hour before that you usually spend scrambling, and the forty-five minutes after that you usually spend on notes, tasks, and follow-up emails. Fluso compresses both. The meeting itself is exactly the same length. -## A real Tuesday +## An example Tuesday It's 9:00 AM. You have a project review with the Acme team at 10. You haven't prepped. The old version: scramble through emails, find the last meeting notes, check Slack for Acme threads, try to remember what was pending. You arrive at 10 feeling slightly behind. After the meeting: 20 minutes typing notes, 15 minutes creating tasks, 15 minutes writing the follow-up email, 10 minutes drafting the Slack update. Done by 11:45, ninety minutes after the meeting ended. -The Fluso version is below. +The Fluso version is below. Times and outputs illustrate the workflow; they are not a processing-time guarantee. ### 9:55 — Prep @@ -75,7 +75,7 @@ For async-style recordings: > *"Process this Loom and create tasks from the action items."* -Works for any video or audio source, not just live calls. +Provide an accessible recording or transcript. Supported formats, file limits, and permissions still apply. ## When you have multiple meetings in a row diff --git a/content/docs/workflows/morning-brief.mdx b/content/docs/workflows/morning-brief.mdx index da51d2e..a2d7786 100644 --- a/content/docs/workflows/morning-brief.mdx +++ b/content/docs/workflows/morning-brief.mdx @@ -45,7 +45,7 @@ The prompt language is loose. Anything that gestures at the same intent works. ## Setup checklist -Gmail connected (see [Gmail](/integrations/gmail)). Calendar connected (see [Google Calendar](/integrations/google-calendar)). Auto-task extraction is on by default. Slack is optional but adds team context to the brief if you've connected it. +Gmail connected (see [Gmail](/integrations/gmail)). Calendar connected (see [Google Calendar](/integrations/google-calendar)). Background task extraction depends on runtime and deployment settings and is disabled in confidential mode. You can request this brief directly in chat. Slack is optional but adds team context to the brief if you've connected it. ## What changes through the week diff --git a/public/_redirects b/public/_redirects index a38137d..ce6aa74 100644 --- a/public/_redirects +++ b/public/_redirects @@ -4,3 +4,6 @@ /resources/security/ /resources/legal 301 /llms.mdx/docs/resources/privacy/content.md /llms.mdx/docs/resources/legal/content.md 301 /llms.mdx/docs/resources/security/content.md /llms.mdx/docs/resources/legal/content.md 301 +/remote/telegram /features/chat 301 +/remote/telegram/ /features/chat 301 +/llms.mdx/docs/remote/telegram/content.md /llms.mdx/docs/features/chat/content.md 301