Organization Structure Best Practices

Use folders to organize assets in ways that make sense for your workflow:

By asset type:

Project: Marketing
├── 📁 Agents
│   ├── Content Writer Agent
│   ├── SEO Optimizer Agent
│   └── Social Media Agent
├── 📁 Tools
│   ├── Content Analysis Tool
│   └── Keyword Research Tool
├── 📁 Knowledge
│   ├── Brand Guidelines
│   └── Product Information
└── 📁 Workforces
    └── Content Production Workforce

By use case or workflow:

Project: Sales
├── 📁 Lead Generation
│   ├── Lead Finder Agent
│   ├── Lead Enrichment Tool
│   └── Company Database (Knowledge)
├── 📁 Lead Qualification
│   ├── Lead Scorer Agent
│   └── Qualification Criteria (Knowledge)
└── 📁 Outreach
    ├── Email Writer Agent
    └── Outreach Workforce

By status or stage:

Project: Customer Success
├── 📁 Active / Production
├── 📁 In Development
├── 📁 Testing
└── 📁 Archived

Establish clear naming conventions for consistency across your organization:

For projects:

• Use descriptive names: Marketing - Production not Mktg Prod
• Include environment if applicable: Sales - Development
• Use consistent separators: - or |

For assets:

• Start with asset type: Agent: Lead Qualifier or Tool: Data Enrichment
• Include purpose: Agent: Customer Support - Tier 1
• Use version numbers if needed: Agent: Content Writer v2
• Avoid special characters that may cause issues

For folders:

• Use emojis for visual clarity: 📁 Active Agents, 🔧 Tools, 📚 Knowledge
• Keep names short and clear
• Use consistent capitalization

Owner role:

Assign to 1-2 people maximum (CEO, CTO, or Head of Operations). These users have full control including billing.

Admin role:

Assign to IT leads, platform team, or workspace admins. Typically 2-5 people depending on company size. These users manage projects, users, and security.

Member role:

Default role for most users. Can create their own projects and assets. Good for power users and builders.

Viewer role:

For external collaborators or users in onboarding. Cannot create anything until assigned to a project. Good for stakeholders who need visibility only.

Admin role:

Assign to project owners (1-2 per project). These users manage project permissions and settings.

Editor role:

Assign to core contributors and builders. Can create and edit all assets in the project. Typically 20-40% of project users.

Member role:

Default role for most project users. Can create their own assets but don’t see others’ by default. Good for independent contributors.

Chat role:

For users who only need to interact with agents via Chat. Cannot access the web app. Perfect for end users and external users.

Viewer role:

For stakeholders who need visibility only. Cannot run or edit anything. Add only to specific assets they need to see.

Default approach: Let project-level permissions handle most access control.

When to use asset-level permissions:

• Sensitive agents with confidential data
• Agents that should only be run by specific users
• Shared agents that need different permissions than project default
• Agents used by external collaborators

Best practice: Start with project-level permissions and add asset-level permissions only when needed. Over-complicating permissions makes administration harder and can cause confusion.

A centralized team manages the platform and creates shared resources.

Structure:

Organization: Acme Corp
├── Project: CoE - Shared Agents (managed by platform team)
├── Project: CoE - Shared Tools (managed by platform team)
├── Project: CoE - Knowledge Libraries (managed by platform team)
├── Project: Marketing (uses shared resources)
├── Project: Sales (uses shared resources)
└── Project: Support (uses shared resources)

Best for:

• Companies with dedicated AI/automation team
• Organizations wanting centralized governance
• Companies with compliance requirements

Why this works:

The CoE model ensures consistency and quality across the organization. A centralized team becomes experts in the platform, creates reusable resources, and maintains governance standards. Teams benefit from professionally-built shared resources without needing deep platform expertise.

Each team manages their own projects with light central governance.

Structure:

Organization: Acme Corp
├── Project: Marketing (self-managed)
├── Project: Sales (self-managed)
├── Project: Support (self-managed)
├── Project: Product (self-managed)
└── Project: Shared Resources (light governance)

Best for:

• Companies with autonomous teams
• Organizations with distributed decision-making
• Companies prioritizing speed over standardization

Why this works:

The federated model empowers teams to move quickly and innovate independently. Each team controls their own destiny while a lightweight shared resources project prevents complete duplication. This works well for organizations that value team autonomy over centralized control.

Combines centralized shared resources with team autonomy.

Structure:

Organization: Acme Corp
├── Project: Platform - Shared Agents (centrally managed)
├── Project: Platform - Shared Tools (centrally managed)
├── Project: Platform - Knowledge Libraries (centrally managed)
├── Project: Marketing - Production (team-managed)
├── Project: Marketing - Development (team-managed)
├── Project: Sales - Production (team-managed)
├── Project: Sales - Development (team-managed)
└── Project: Innovation Sandbox (open to all)

Best for:

• Most Enterprise organizations
• Companies wanting balance between governance and autonomy
• Organizations with both shared and team-specific use cases

Why this works:

The hybrid model combines the best of both worlds. Teams get autonomy for their specific needs while benefiting from centrally-managed shared resources. This prevents duplication, maintains quality standards, and still allows teams to innovate. It’s the most scalable and flexible approach for growing organizations.

Document policies for:

• Who can create new projects
• Naming conventions for projects and assets
• Approval process for new integrations
• Usage limits and escalation procedures
• Asset archival and deletion policies

Share these policies in a central location that’s easy to find and keep them updated as your deployment evolves.

Conduct quarterly audits to:

• Review project structure and usage
• Remove inactive users and projects
• Verify permissions are still appropriate
• Identify duplicate or unused assets
• Check compliance with policies

Regular audits prevent organizational drift and keep your structure aligned with your business needs.

Every project should have:

• Primary owner (Project Admin) — responsible for day-to-day management
• Secondary owner (Project Admin) — backup for primary owner
• Executive sponsor — business stakeholder who approves major changes

Clear ownership ensures accountability and makes it easy for users to know who to contact for access or questions.

Track these metrics:

• Number of active projects and assets
• Users per project
• Usage per project (credits consumed)
• Permission changes and access requests
• Asset creation and deletion rates

Use these metrics to identify:

• Projects that should be merged or split
• Users who need training or support
• Opportunities to create shared resources
• Potential security or compliance issues

Data-driven optimization keeps your structure efficient as your organization grows.

Start with 3-5 projects and add more as needed. Most organizations have 5-15 projects. If you have more than 20 projects, consider consolidating.

Yes, but this requires proper permissions. Contact support for assistance with bulk asset moves.

For Enterprise deployments, yes. This provides safer testing and better governance. For smaller teams, you can use folders within a single project.

Create a “Shared Resources” or “Platform” project that all teams can access. Use asset-level permissions to control who can edit vs. use shared resources.

Use folders extensively to organize by use case, status, or team. Consider splitting into multiple projects if agents serve very different purposes.

Yes, users can be members of multiple projects with different roles in each project.

Require approval for new projects, conduct regular audits, and establish clear criteria for when a new project is needed vs. using an existing one.

Start with project-level permissions for simplicity. Add asset-level permissions only for sensitive or special-case assets.