Team Manifests
Team Manifests are the foundation of composable AI teams in MeetLoyd. Think of them as "npm for AI agents" -- a declarative way to define, version, and deploy complete AI team configurations.
What Manifests Do
A Team Manifest defines everything about a team in a single, portable file:
| Component | Purpose |
|---|---|
| Agents | Which agents make up the team, with their models and roles |
| Skills | Domain expertise packages attached to agents |
| Avatars | Video/voice representations from built-in or external providers |
| Orchestration | How agents communicate, route tasks, and escalate |
| Versioning | Lock files ensure reproducible, auditable deployments |
| Customizations | Override configurations without forking the original |
Why Use Manifests?
Manifests bring the same benefits as Terraform or Kubernetes YAML to your AI workforce: version control, reproducibility, and declarative configuration.
- Reproducible deployments -- the same manifest produces the same team every time
- Audit trail -- lock files record exactly which versions are running and when they were deployed
- Rollback -- return to a previous known-good state instantly
- Composability -- mix Store components, local agents, and external providers in one file
Component References
Components are referenced using URIs that specify their source:
| Reference Type | Pattern | Use Case |
|---|---|---|
| Store | store://agents/sdr-agent@^1.0.0 | Published components from the MeetLoyd Store |
| Local | local://agents/my-custom-agent | Custom components in your tenant |
| External | external://heygen/avatar-emma | Third-party avatar/voice providers |
| Catalog | catalog://sales-team | Pre-built team templates from the MeetLoyd catalog |
Version Specifiers
| Specifier | Example | Behavior |
|---|---|---|
| Exact | 1.2.3 | Only this version (no updates) |
| Caret | ^1.0.0 | Compatible with 1.x.x (minor and patch updates) |
| Tilde | ~2.1.0 | Patch updates only (2.1.x) |
Team Catalog
MeetLoyd ships with 23 pre-built team manifests covering common enterprise use cases. These are the single source of truth for all team templates, Store listings, and preset deployments.
| Team | Category | Description |
|---|---|---|
| Sales Team | sales | Complete AI sales operations |
| Support Team | support | Customer support escalation |
| C-Suite Team | executive | Executive leadership team |
| DevOps Team | engineering | Infrastructure and deployment |
| Marketing Team | marketing | Content and campaign management |
| Finance Team | finance | Financial operations and reporting |
| Legal Team | legal | Legal review and compliance |
| Product Team | product | Product management and roadmap |
| Strategy Team | strategy | Strategic planning and analysis |
| HR Team | hr | Human resources operations |
| Customer Success Team | customer-success | Customer retention and growth |
| Healthcare Team | healthcare | Healthcare operations (HIPAA) |
| Insurance Team | insurance | Insurance operations |
| Real Estate Team | real-estate | Property management and sales |
| VC/PE Team | finance | Venture capital and private equity |
| ...and 8 more |
Model Aliases
Instead of hardcoding specific model IDs, you can use human-friendly aliases that resolve automatically at deploy-time:
| Alias | Resolves To |
|---|---|
claude-opus-latest | claude-opus-4-6 |
claude-sonnet-latest | claude-sonnet-4-6 |
claude-haiku-latest | claude-haiku-4-5-20251001 |
gpt-latest | gpt-4o |
gpt-mini-latest | gpt-4o-mini |
gemini-latest | gemini-2.5-pro |
gemini-flash-latest | gemini-2.5-flash |
mistral-latest | mistral-large-latest |
deepseek-latest | deepseek-r1-distill-70b |
glm-latest | glm-5 |
qwen-coder-latest | qwen3-coder-30b |
Aliases are resolved both at deploy-time and as a runtime safety net, so agents always route to the correct LLM provider.
Agent Authorization in Manifests
You can declare per-agent resource permissions directly in your manifest. These are provisioned as OpenFGA authorization tuples at deploy-time.
Common resource types:
| Type | Example | Description |
|---|---|---|
crm_object_type | hubspot/contacts | CRM object access |
git_repository | github/acme/website | Git repo permissions |
drive_folder | shared/reports | Drive folder access |
email_domain | acme.com | Email sending scope |
Common relations: reader, writer, editor, committer, admin.
Authorization provisioning is non-blocking. If OpenFGA is not configured in your environment, deployment continues with a warning.
Agent Identity (SPIFFE)
Agents automatically receive a SPIFFE identity at deploy-time, following the pattern spiffe://meetloyd.com/tenant/{tenantId}/agent/{agentId}. This enables cross-service authentication, token exchange, and trust verification by external services.
You can optionally configure SVID parameters such as custom audiences and TTL in the manifest's identity section.
Catalog Validation
All catalog manifests are validated against a strict schema when loaded. Validation is informational -- errors are logged as warnings but never prevent the catalog from loading. Validated fields include agent definitions, orchestration config, interaction rules, authorization grants, and identity config.
Development Hot-Reload
When developing locally, the catalog loader watches for changes and automatically refreshes the cache. Edit a YAML file and your next API request uses the updated version -- no restart needed. Hot-reload is debounced (300ms window) and automatically disabled in production.
See Also
- Store Publishing - Publish components to the Store
- Store Browsing - Browse and discover components
- Avatar Providers - Configure external providers
- Agent Authorization - OpenFGA authorization details
- Agent Identity - SPIFFE identity system