> ## Documentation Index
> Fetch the complete documentation index at: https://docs.duckie.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Workspaces and System Boundaries

> Decide how to separate teams, products, regions, and support motions in Duckie

Boundaries help teams keep the right people, knowledge, channels, actions, and analytics together.

The practical question is: which part of the business should this agent belong to, and what should it be allowed to see or do?

## Organization vs Workspace

A **top-level organization** is the billing and account umbrella. A **workspace** is an isolated Duckie environment under that organization.

Billing rolls up to the top-level organization. Configuration and data stay separate inside each workspace.

## What a Workspace Separates

Each workspace has its own:

| Area                   | What is scoped                                                                    |
| ---------------------- | --------------------------------------------------------------------------------- |
| Members and roles      | Workspace membership and role assignments                                         |
| Connections            | Connected integrations and credentials                                            |
| Agents and deployments | Agent configuration, deployment settings, and production runs                     |
| Knowledge and training | Knowledge items, guidelines, guardrails, runbooks, snippets, tools, and workflows |
| Analytics and testing  | Runs, usage attribution, playground activity, and batch tests                     |

Changing one workspace does not change a sibling workspace.

## Workspace Examples

| Workspace                               | Why it helps                                                                                |
| --------------------------------------- | ------------------------------------------------------------------------------------------- |
| EMEA Support                            | Regional ownership, channels, localized knowledge, and escalation paths                     |
| Product A Support and Product B Support | Separate docs, agents, tools, and analytics by product                                      |
| Internal Support and Customer Support   | Different audiences, policies, integrations, and tone                                       |
| Enterprise Support                      | High-touch customers, stricter guardrails, dedicated connections, and specialist agents     |
| Pilot Support                           | Useful only when the pilot needs separate data or configuration; otherwise use Testing mode |

## Boundary Choices

| Use this                  | When                                                                                    |
| ------------------------- | --------------------------------------------------------------------------------------- |
| **Workspace**             | You need hard separation of members, connections, agents, knowledge, runs, and settings |
| **Knowledge Tags**        | The same workspace is fine, but an agent should search only certain knowledge           |
| Separate **agents**       | Jobs, tone, tools, or escalation rules differ                                           |
| Deployment filters        | The same agent should handle only certain channels, groups, tags, events, or schedules  |
| Tool access and approvals | You need to limit what agents can do                                                    |
| Guardrails                | You need shared restrictions and escalation rules                                       |
| Testing surfaces          | You want to validate behavior before expanding live scope                               |

## Recommended Setup Flow

1. Start from your business structure: teams, products, regions, customer segments, and support motions.
2. Create workspaces only where separation is needed.
3. Connect only the integrations each workspace should use.
4. Configure agents with scoped knowledge, tools, guidelines, guardrails, runbooks, and workflows.
5. Deploy in **Testing** mode first.
6. Review **Analyze > Runs** and testing results.
7. Expand to **Live** once behavior and ownership are clear.

## Related Docs

<CardGroup cols={2}>
  <Card title="Workspaces" icon="building" href="/settings/workspaces">
    Create and manage isolated Duckie workspaces.
  </Card>

  <Card title="Members" icon="users" href="/settings/members">
    Manage people and roles.
  </Card>

  <Card title="Knowledge Tags" icon="tags" href="/knowledge/tags">
    Scope knowledge within a workspace.
  </Card>

  <Card title="Connections" icon="plug" href="/settings/connections">
    Connect the right systems to each workspace.
  </Card>
</CardGroup>