From 837cf940bcde61be0a2d7318699b16d166ab2417 Mon Sep 17 00:00:00 2001 From: biswaroop1547 Date: Tue, 1 Sep 2026 19:32:10 +0530 Subject: [PATCH 1/3] docs: simplify Agent guide navigation --- .../context-isolation-in-threads.mdx | 30 +------------ .../export-import-and-share-agents.mdx | 40 +----------------- content/docs/developers/meta.json | 12 +++--- .../developers/parent-and-child-threads.mdx | 37 +--------------- .../docs/developers/threads-and-contexts.mdx | 42 ++++++++++++++++++- content/docs/developers/versions.mdx | 38 ++++++++++++++--- content/docs/features/meta.json | 2 +- content/docs/features/open-architecture.mdx | 2 +- content/docs/features/projects.mdx | 6 +++ 9 files changed, 93 insertions(+), 116 deletions(-) diff --git a/content/docs/developers/context-isolation-in-threads.mdx b/content/docs/developers/context-isolation-in-threads.mdx index 0045423..3f0fb84 100644 --- a/content/docs/developers/context-isolation-in-threads.mdx +++ b/content/docs/developers/context-isolation-in-threads.mdx @@ -2,33 +2,7 @@ title: Context isolation in threads sidebarTitle: Context isolation icon: lock-keyhole -description: Understand what an Agent thread keeps to itself and what it shares with other threads. +description: Find the combined guide to thread context, isolation, and delegation. --- -Each Agent thread has its own conversation history and session state. Starting a new thread gives you a clean conversation. Sending work to a child thread passes the message you send, not the parent's full transcript. - -A new thread does not receive another thread's conversation history, but it can still access shared project files and other resources. - -## What stays in one thread - -- The message history for that conversation. -- In-progress turn state and temporary session data. -- The Agent definition captured when the thread was created. -- References to attached files in that thread's history. - -## What threads can share - -Each thread uses the resources in the saved Agent definition it started with. Threads started from the same definition can use the same knowledge files and capabilities. Threads in the same configured project can also use: - -- The project's files. -- Short project working-memory summaries from other threads. - -If two threads edit the same resource at once, their changes can conflict. - -## When to start a new thread - -Use a new thread when the topic has changed, when a task needs its own history, or when two independent tasks can progress separately. Keep the current thread when the next step depends on the full conversation. - -## Next - -See [Parent and child threads](/developers/parent-and-child-threads) for delegation rules and [Threads and contexts](/developers/threads-and-contexts) for the complete context map. +Context isolation now lives in [Threads and contexts](/developers/threads-and-contexts#keep-contexts-isolated). diff --git a/content/docs/developers/export-import-and-share-agents.mdx b/content/docs/developers/export-import-and-share-agents.mdx index ed71a05..c32027b 100644 --- a/content/docs/developers/export-import-and-share-agents.mdx +++ b/content/docs/developers/export-import-and-share-agents.mdx @@ -2,43 +2,7 @@ title: Export, import, and share Agents sidebarTitle: Export, import & share icon: share-2 -description: Move an Agent definition between workspaces or give someone a safe copy to review. +description: Find the combined guide to Agent versions, export, import, and 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**. - -## Export a file - -Select **Export YAML** to download an `.agent.yaml` definition. Keep the file in source control when you want a reviewable handoff or a backup outside Fluso. - -The file includes the portable Agent fields and its saved workflow. It leaves out workspace identities, secrets, deliveries, project ownership, and knowledge-file contents. The names of omitted knowledge files are included so the recipient knows what must be added again. - -## Import a copy - -Select **Import Agent** and choose a Fluso Agent YAML, YML, or JSON definition. Fluso opens a new Agent draft; it does not overwrite the Agent whose menu you used. - -Before creating the copy: - -1. Review the name, instructions, and conversation starters. -2. Choose the destination project. Imports start in **Home**. -3. Add the required knowledge files again. -4. Review every skill and App. These are references, not transferred credentials, and must be available in the destination workspace. -5. Create the Agent and test it in a new thread. - -Agent definition files are limited to 128 KB. Import rejects an incomplete definition or an unsupported format version rather than creating a partial Agent. - -## Share a review link - -Select **Share**, then **Copy link**. Anyone with the link can review the read-only setup and choose **Import this Agent** to make a separate copy in their own workspace. - -A shared link contains the portable definition. Treat it like the exported file: send it only to people who may read the Agent's instructions and configuration. It does not include workspace secrets, identities, chat history, project files, or knowledge-file contents. - -The link is a snapshot, not ongoing collaboration. Later edits to the source Agent do not update an imported copy, and changes to the copy do not affect the source. Share a new link when you want someone to review a newer setup. - -## Example handoff - -For a customer escalation Agent, export the definition or share its link with the support lead. They can review the P0/P1 rules and approval boundary, import a copy, connect their own Gmail and Slack access, add their escalation runbook, and test it without touching your Agent or threads. - -For ordinary project and conversation imports, see [Imports](/features/imports). Those imports bring context and files into projects; they are separate from importing an Agent definition. +Export, import, and sharing now live in [Agent versions and portability](/developers/versions#move-an-agent-between-workspaces). diff --git a/content/docs/developers/meta.json b/content/docs/developers/meta.json index fa0c30e..e2a141f 100644 --- a/content/docs/developers/meta.json +++ b/content/docs/developers/meta.json @@ -2,17 +2,17 @@ "pages": [ "agent-builder", "agent-description", + "evaluations", + "versions", "api-ref", "architecture", - "context-isolation-in-threads", - "evaluations", - "export-import-and-share-agents", - "parent-and-child-threads", "project-context", "schedules", "threads-and-contexts", "user-preferences", - "versions", - "webhooks" + "webhooks", + "!context-isolation-in-threads", + "!export-import-and-share-agents", + "!parent-and-child-threads" ] } diff --git a/content/docs/developers/parent-and-child-threads.mdx b/content/docs/developers/parent-and-child-threads.mdx index 9802750..5f80220 100644 --- a/content/docs/developers/parent-and-child-threads.mdx +++ b/content/docs/developers/parent-and-child-threads.mdx @@ -2,40 +2,7 @@ title: Parent and child threads sidebarTitle: Parent & child threads icon: git-fork -description: Let a top-level Agent thread coordinate independent work without mixing every conversation together. +description: Find the combined guide to thread context, isolation, and delegation. --- -A top-level Agent thread can create direct child threads for separate tasks. The parent coordinates the request. 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 - -Agent setup offers three choices: - -| Setting | Behavior | -| --- | --- | -| Off | The Agent cannot manage other threads. | -| Explicit | The Agent creates a child only when you ask or its standing instructions require one. This is the default. | -| Proactive | The Agent may create direct children for distinct tasks that can progress independently. | - -Proactive mode does not mean every step becomes a child. Use child threads only for distinct tasks. Reuse a child that already owns the task, and keep related changes that must move together in the parent. - -## Give a child enough context - -A child sees the task message, not the parent conversation. A good task message includes: - -- The task and what the child owns. -- The source material to use. -- Any constraints and actions that need approval. -- What counts as done and what the child should return. - -The parent can request the child's final result and receive it automatically. It can also send more work to an existing child. Only the parent that created a child can cancel its delegated request or delete that child. - -## Safe parallel work - -Use separate children for read-only research or changes to different outputs. Keep changes to the same files or shared APIs in one thread, and combine the results there. - -## Next - -Read [Context isolation in threads](/developers/context-isolation-in-threads) before splitting work, then see [Threads and messages](/developers/api-ref/threads-and-messages) for the public thread API. +Parent and child threads now live in [Threads and contexts](/developers/threads-and-contexts#use-parent-and-child-threads). diff --git a/content/docs/developers/threads-and-contexts.mdx b/content/docs/developers/threads-and-contexts.mdx index afa3ac3..5e6101d 100644 --- a/content/docs/developers/threads-and-contexts.mdx +++ b/content/docs/developers/threads-and-contexts.mdx @@ -36,6 +36,44 @@ The Agent definition includes its name, description, goal, instructions, allowed 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. +## Keep contexts isolated + +### What stays in one thread + +- Its messages and attached-file references. +- In-progress turn state and temporary session data. +- The Agent definition captured when the thread started. + +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. + +## 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. | + +### Give a child enough context + +A child sees the task message, not the parent's transcript. Include the task, source material, constraints, approval boundaries, and expected result. The parent can receive the result, send follow-up work to that child, or cancel its delegated request. + +### Work in parallel safely + +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. + ## Pick the right scope - Put stable Agent behavior in **Instructions**. @@ -44,6 +82,6 @@ Ordinary project chats can use global user preferences, project instructions, an - Start a new thread for a clean conversation. - Use a child thread only when the task can progress with the context you send it. -## Next +## Related guides -Read [Context isolation in threads](/developers/context-isolation-in-threads), [Project context](/developers/project-context), and [User preferences](/developers/user-preferences) for each boundary. +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. diff --git a/content/docs/developers/versions.mdx b/content/docs/developers/versions.mdx index b75a33e..38ac4bc 100644 --- a/content/docs/developers/versions.mdx +++ b/content/docs/developers/versions.mdx @@ -1,8 +1,8 @@ --- title: Agent versions -sidebarTitle: Versions -icon: history -description: Review saved Agent changes, restore a known-good setup, and verify it in a new thread. +sidebarTitle: Agent versions +icon: git-compare-arrows +description: Review, restore, export, import, and share an Agent's saved setup. --- 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. @@ -31,10 +31,38 @@ Existing threads keep the configuration they started with. Only new threads use 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. -If the selected version points to a deleted project, choose a current project in the editor first. If the Agent changed in another browser tab, refresh the history, review the newest version, and retry. +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 +### Example: restore severity rules 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 + +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**. + +### 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. + +### 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. + +### Share a review link + +Select **Share**, then **Copy link**. Anyone with the link can review the read-only definition and import a separate copy. + +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. + +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. + +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. + For API-based version updates, see [Agents and versions](/developers/api-ref/agents-and-versions). diff --git a/content/docs/features/meta.json b/content/docs/features/meta.json index 84439fa..6e17f97 100644 --- a/content/docs/features/meta.json +++ b/content/docs/features/meta.json @@ -1,10 +1,10 @@ { "pages": [ "approvals", + "mcp", "chat", "confidential", "imports", - "mcp", "memory", "open-architecture", "projects", diff --git a/content/docs/features/open-architecture.mdx b/content/docs/features/open-architecture.mdx index 0686dd1..ffe12f1 100644 --- a/content/docs/features/open-architecture.mdx +++ b/content/docs/features/open-architecture.mdx @@ -40,7 +40,7 @@ Agent export and sharing deliberately omit: - Knowledge-file contents. - Schedules, webhook triggers, evaluations, and version history. -The export names omitted knowledge files so the recipient can add them again. Skills and Apps remain references to review and reconnect in the destination workspace. See [Export, import, and share Agents](/developers/export-import-and-share-agents) for the full handoff flow. +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 and portability](/developers/versions#move-an-agent-between-workspaces) for the full handoff flow. ## A practical handoff diff --git a/content/docs/features/projects.mdx b/content/docs/features/projects.mdx index c68d051..ad863cb 100644 --- a/content/docs/features/projects.mdx +++ b/content/docs/features/projects.mdx @@ -37,6 +37,12 @@ Files created in project chats stay in the same workspace. That makes the projec [Tasks](/features/tasks#tasks-and-projects) can also belong to a project, keeping their follow-up chat in the same scope. +## Export a project + +On **Projects**, open the project's **•••** menu and select **Export as zip**. You can also open the project and select **Export**. + +The ZIP contains the project's regular files and folders, `context.md`, and project metadata. It skips dotted runtime entries and symbolic links. Conversation history is separate; use **Share chat** for a reviewable snapshot or the [Threads API](/developers/api-ref/threads-and-messages#read-message-history) for persisted messages. + ## Keep context in the right place Project instructions guide ordinary project chats. Durable notes and decisions live in `context.md`, while working memory keeps short summaries of recent work. The file is hidden from the project explorer; say *"add this to project context"* in a project chat when you want Fluso to update it. From 1b737c516035481e359e6a8d556a9492df88ca95 Mon Sep 17 00:00:00 2001 From: biswaroop1547 Date: Tue, 1 Sep 2026 19:41:54 +0530 Subject: [PATCH 2/3] docs: document deployment models --- AGENTS.md | 1 + content/docs/deployment-models.mdx | 64 ++++++++++++++++++++++++++++++ content/docs/introduction.mdx | 2 +- content/docs/meta.json | 2 + 4 files changed, 68 insertions(+), 1 deletion(-) create mode 100644 content/docs/deployment-models.mdx diff --git a/AGENTS.md b/AGENTS.md index 6cd6f48..a6d7f8b 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -15,6 +15,7 @@ The navigation keeps Home first, then sorts the top-level sections and the pages - **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/*`. - **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, pricing, privacy, security}`. Security covers infrastructure; Privacy covers data handling; they're distinct pages. diff --git a/content/docs/deployment-models.mdx b/content/docs/deployment-models.mdx new file mode 100644 index 0000000..4ea8954 --- /dev/null +++ b/content/docs/deployment-models.mdx @@ -0,0 +1,64 @@ +--- +title: Deployment models +sidebarTitle: Overview +icon: server-cog +description: Compare Fluso Cloud, dedicated AWS VPC, planned Azure VNet, and scoped on-premises deployments. +--- + +Your deployment model decides who operates Fluso and where its runtime, durable data, and diagnostics can live. It does not by itself control where connected Apps or external model providers process data. + +| Model | Availability | Operations | +| --- | --- | --- | +| Fluso Cloud | Available | Managed by Fluso | +| Dedicated AWS VPC | Supported for scoped Enterprise deployments | Responsibilities agreed during deployment design | +| Azure VNet | Coming soon | Not available today | +| On-premises | Scoped Enterprise engagement | Responsibilities agreed before implementation | + +## Fluso Cloud + +Fluso Cloud is the standard managed service. It runs on AWS with European hosting by default. Fluso operates the application services, Agent runtimes, storage, and platform updates; you manage your workspace, users, connected Apps, and approval policies. + +Choose it when you want to start without operating infrastructure. See [Privacy](/resources/privacy) for data handling and [Security](/resources/security) for encryption and isolation. + +## Dedicated AWS VPC + +A dedicated AWS VPC deployment is available for Enterprise customers whose network or residency requirements do not fit the managed service. It is a scoped deployment, not a self-service switch. + +Before launch, your team and Fluso agree on the AWS region, network connectivity, ingress and egress, DNS, secrets, data stores, backups, upgrades, and support access. Outbound access can use Fluso's Allow, Ask, and Deny policy boundary; review the current scope under [Network egress](/admin-panel#network-egress). + +## Azure VNet (coming soon) + +Azure VNet support is planned but is not available today. There is no published availability date. Do not make an Azure deployment dependency until Fluso confirms the required region and services are supported. + +## On-premises + +On-premises deployments are scoped with Enterprise customers against the target infrastructure. Fluso does not currently offer a one-click installer or a generic support promise for every Kubernetes, virtual-machine, or bare-metal environment. + +Agree on these boundaries before treating the design as approved: + +| Boundary | What to decide | +| --- | --- | +| Data residency | Where the database, project files, knowledge data, and backups are stored | +| Runtime and inference residency | Where Agent runtimes execute and which model endpoints may receive requests | +| Diagnostic-data residency | Where logs, metrics, and traces are stored, how long they are retained, and who can access them | +| Network access | Which inbound paths and outbound destinations are permitted | +| Connected Apps | Which external systems may be read or changed, and what returned data Fluso may persist | + + + Running Fluso on-premises does not automatically keep model inference or connected-App data on-premises. External providers keep their own processing boundaries. Confirm every provider and route as part of the deployment design. + + +## Telemetry + +AWS deployments use CloudWatch for service logs, dashboards, and alarms. Fluso's knowledge service can emit structured logs, OpenTelemetry data over OTLP, and optional Prometheus metrics. For an on-premises deployment, agree which signals and customer-owned collectors are supported before implementation. + +[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. + +## Choose a model + +- Start with Fluso Cloud when managed operations and European hosting meet the requirement. +- Scope an AWS VPC deployment when you need a dedicated AWS network boundary. +- Treat Azure VNet as future availability, not a current option. +- Scope on-premises only after Fluso validates the infrastructure, residency, provider, telemetry, and support requirements. + +For a custom deployment, [contact Fluso](mailto:sales@premai.io). For the component boundaries behind these models, read [Architecture](/developers/architecture). diff --git a/content/docs/introduction.mdx b/content/docs/introduction.mdx index 9e62b5b..50af60f 100644 --- a/content/docs/introduction.mdx +++ b/content/docs/introduction.mdx @@ -62,7 +62,7 @@ You will see how Fluso reads context, where it finds evidence, and how much revi Your workspace runs inside a dedicated environment. Data is not used to train shared models, is hosted in Europe, and is grounded in Switzerland through Prem AI's infrastructure. -Enterprise customers can choose private VPC, on-prem, or air-gapped deployments. See [Privacy](/resources/privacy) and [Security](/resources/security) for the full picture. +Enterprise deployments can be scoped for a dedicated AWS VPC or an on-premises environment. Azure VNet support is coming soon. Compare the current [deployment models](/deployment-models), then see [Privacy](/resources/privacy) and [Security](/resources/security) for the data and infrastructure boundaries. ## Next diff --git a/content/docs/meta.json b/content/docs/meta.json index 1fa3a35..d91de01 100644 --- a/content/docs/meta.json +++ b/content/docs/meta.json @@ -7,6 +7,8 @@ "...developers", "---App setup---", "...integrations", + "---Deployment models---", + "deployment-models", "---Features---", "...features", "---Get started---", From ea2c1296c8c4fd67bbddf0ed01badd4625eb2595 Mon Sep 17 00:00:00 2001 From: biswaroop1547 Date: Tue, 1 Sep 2026 19:55:15 +0530 Subject: [PATCH 3/3] docs: close deployment and portability gaps --- content/docs/deployment-models.mdx | 12 +++++++----- .../developers/export-import-and-share-agents.mdx | 2 +- content/docs/developers/threads-and-contexts.mdx | 2 +- content/docs/features/open-architecture.mdx | 6 ++++-- content/docs/features/projects.mdx | 2 +- content/docs/meta.json | 3 ++- content/docs/resources/faq.mdx | 2 +- content/docs/resources/pricing.mdx | 2 +- content/docs/workflows/dev-bug-fix.mdx | 2 +- 9 files changed, 19 insertions(+), 14 deletions(-) diff --git a/content/docs/deployment-models.mdx b/content/docs/deployment-models.mdx index 4ea8954..f7189f1 100644 --- a/content/docs/deployment-models.mdx +++ b/content/docs/deployment-models.mdx @@ -24,7 +24,7 @@ Choose it when you want to start without operating infrastructure. See [Privacy] A dedicated AWS VPC deployment is available for Enterprise customers whose network or residency requirements do not fit the managed service. It is a scoped deployment, not a self-service switch. -Before launch, your team and Fluso agree on the AWS region, network connectivity, ingress and egress, DNS, secrets, data stores, backups, upgrades, and support access. Outbound access can use Fluso's Allow, Ask, and Deny policy boundary; review the current scope under [Network egress](/admin-panel#network-egress). +Before launch, your team and Fluso agree on AWS account ownership, region, network connectivity, ingress and egress, DNS, secrets, data stores, backups, upgrades, and support access. Where egress governance is enabled, outbound access can use Fluso's Allow, Ask, and Deny policy boundary; review the current scope under [Network egress](/admin-panel#network-egress). ## Azure VNet (coming soon) @@ -40,17 +40,19 @@ Agree on these boundaries before treating the design as approved: | --- | --- | | Data residency | Where the database, project files, knowledge data, and backups are stored | | Runtime and inference residency | Where Agent runtimes execute and which model endpoints may receive requests | -| Diagnostic-data residency | Where logs, metrics, and traces are stored, how long they are retained, and who can access them | +| Diagnostic-data residency | What diagnostic data is captured, where it is stored, how long it is retained, and who can access it | | Network access | Which inbound paths and outbound destinations are permitted | | Connected Apps | Which external systems may be read or changed, and what returned data Fluso may persist | - Running Fluso on-premises does not automatically keep model inference or connected-App data on-premises. External providers keep their own processing boundaries. Confirm every provider and route as part of the deployment design. + Running Fluso on-premises does not automatically keep model inference or connected-App data on-premises. External providers keep their own processing boundaries. Confirm every provider and route as part of the deployment design; [Privacy](/resources/privacy#sub-processors) lists the current sub-processors. -## Telemetry +## Operational telemetry -AWS deployments use CloudWatch for service logs, dashboards, and alarms. Fluso's knowledge service can emit structured logs, OpenTelemetry data over OTLP, and optional Prometheus metrics. For an on-premises deployment, agree which signals and customer-owned collectors are supported before implementation. +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. + +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. diff --git a/content/docs/developers/export-import-and-share-agents.mdx b/content/docs/developers/export-import-and-share-agents.mdx index c32027b..7bae0a0 100644 --- a/content/docs/developers/export-import-and-share-agents.mdx +++ b/content/docs/developers/export-import-and-share-agents.mdx @@ -5,4 +5,4 @@ icon: share-2 description: Find the combined guide to Agent versions, export, import, and sharing. --- -Export, import, and sharing now live in [Agent versions and portability](/developers/versions#move-an-agent-between-workspaces). +Export, import, and sharing now live in [Agent versions](/developers/versions#move-an-agent-between-workspaces). diff --git a/content/docs/developers/threads-and-contexts.mdx b/content/docs/developers/threads-and-contexts.mdx index 5e6101d..1c7f10e 100644 --- a/content/docs/developers/threads-and-contexts.mdx +++ b/content/docs/developers/threads-and-contexts.mdx @@ -68,7 +68,7 @@ A top-level Agent thread can create direct child threads for separate tasks. Eac ### Give a child enough context -A child sees the task message, not the parent's transcript. Include the task, source material, constraints, approval boundaries, and expected result. The parent can receive the result, send follow-up work to that child, or cancel its delegated request. +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. ### Work in parallel safely diff --git a/content/docs/features/open-architecture.mdx b/content/docs/features/open-architecture.mdx index ffe12f1..6f1d645 100644 --- a/content/docs/features/open-architecture.mdx +++ b/content/docs/features/open-architecture.mdx @@ -13,8 +13,10 @@ Different exports serve different purposes. A project ZIP is a file backup; an A | Data | Export path | What you receive | | --- | --- | --- | -| **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, folders, `context.md`, and project metadata | +| **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 | | **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 | @@ -40,7 +42,7 @@ Agent export and sharing deliberately omit: - 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 and portability](/developers/versions#move-an-agent-between-workspaces) for the full handoff flow. +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. ## A practical handoff diff --git a/content/docs/features/projects.mdx b/content/docs/features/projects.mdx index ad863cb..c800cef 100644 --- a/content/docs/features/projects.mdx +++ b/content/docs/features/projects.mdx @@ -41,7 +41,7 @@ Files created in project chats stay in the same workspace. That makes the projec On **Projects**, open the project's **•••** menu and select **Export as zip**. You can also open the project and select **Export**. -The ZIP contains the project's regular files and folders, `context.md`, and project metadata. It skips dotted runtime entries and symbolic links. Conversation history is separate; use **Share chat** for a reviewable snapshot or the [Threads API](/developers/api-ref/threads-and-messages#read-message-history) for persisted messages. +The ZIP contains the project's regular files, their folder paths, `context.md`, and project metadata. It omits empty folders, dotted runtime entries, and symbolic links. Conversation history is separate; use **Share chat** for a reviewable snapshot or the [Threads API](/developers/api-ref/threads-and-messages#read-message-history) for persisted messages. ## Keep context in the right place diff --git a/content/docs/meta.json b/content/docs/meta.json index d91de01..3c8be00 100644 --- a/content/docs/meta.json +++ b/content/docs/meta.json @@ -8,7 +8,8 @@ "---App setup---", "...integrations", "---Deployment models---", - "deployment-models", + "!deployment-models", + "[server-cog][Overview](/deployment-models)", "---Features---", "...features", "---Get started---", diff --git a/content/docs/resources/faq.mdx b/content/docs/resources/faq.mdx index 88f9c4b..f636445 100644 --- a/content/docs/resources/faq.mdx +++ b/content/docs/resources/faq.mdx @@ -1,7 +1,7 @@ --- title: FAQ sidebarTitle: FAQ -icon: circle-help +icon: circle-question-mark description: The questions that come up most often. What Fluso is, how it works, security, pricing, getting started, and the occasional troubleshooting nudge. --- diff --git a/content/docs/resources/pricing.mdx b/content/docs/resources/pricing.mdx index 76cf70c..6e2be55 100644 --- a/content/docs/resources/pricing.mdx +++ b/content/docs/resources/pricing.mdx @@ -114,7 +114,7 @@ Obligation detection scans your connected apps for things you have committed to: The model depends on the feature. Fluso uses open-weight models for some workloads and proprietary model APIs for others. Agent Studio currently uses Gemini through OpenRouter. - European hosting on every plan. Your data does not leave EU infrastructure and is never used to train shared models. + Fluso Cloud stores workspace data in the EU by default. Model inference and connected-App processing follow the provider boundaries in [Privacy](/resources/privacy#sub-processors). Enterprise customers can scope alternative data residency. Your data is never used to train shared models. 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. diff --git a/content/docs/workflows/dev-bug-fix.mdx b/content/docs/workflows/dev-bug-fix.mdx index 6d0f566..6da3f02 100644 --- a/content/docs/workflows/dev-bug-fix.mdx +++ b/content/docs/workflows/dev-bug-fix.mdx @@ -77,7 +77,7 @@ Drop a `context.md` in the repo describing your stack, conventions, and do-not-t The code skills (Q&A, PR review, scaffolding, bug fixes) and the rest of the catalog. - + Setup, permissions, repository scope.