Refine Agent docs and document deployment models

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.

content/docs/deployment-models.mdx

@@ -0,0 +1,66 @@
+---
+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 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)
+
+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 | 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 |
+
+<Warning>
+  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.
+</Warning>
+
+## 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.
+
+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.
+
+## 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).

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

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](/developers/versions#move-an-agent-between-workspaces).

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"
   ]
 }

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

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