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?

Think Infrastructure as Code

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.

Non-Blocking

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.

Manifest Structure

A manifest is a YAML or JSON file with these top-level sections:

Section	Required	Description
name	Yes	Human-readable team name
slug	Yes	URL-friendly identifier
version	Yes	Semantic version
description	No	What this team does
components.agents	Yes	Agent definitions with refs, versions, and overrides
components.skills	No	Skill packages to attach
components.avatars	No	Avatar/voice providers
orchestration	No	Routing mode, intent routing, fallback behavior

Orchestration Modes

Mode	Description
Hierarchical	Entry agent routes to specialists based on intent; supports fallback
Parallel	Multiple agents process concurrently with configurable aggregation
Sequential	Agents execute one after another in a defined order
Round Robin	Incoming requests distributed evenly across agents
Smart Routing	LLM-scored dynamic routing to the best-fit agent

Customizations

Override component behavior without forking the original:

• Context prompt templates -- inject tenant-specific variables like industry or region
• Memory configuration -- adjust context token limits per agent
• Skill overrides -- swap one skill for another (e.g., replace Salesforce CRM with HubSpot CRM)

Lock Files

When you deploy a manifest, MeetLoyd generates a lock file that records exact resolved versions, timestamps, and checksums. Lock files ensure reproducibility, provide an audit trail, and enable rollback to previous known-good states.

Deploying a Manifest

From the Dashboard

1. Navigate to Teams and click Deploy from Manifest
2. Upload or paste your manifest file
3. Review the resolved versions and any warnings
4. Click Deploy

From a Catalog Template

1. Go to Teams and click New Team
2. Choose a template from the catalog
3. Customize settings if needed
4. Click Deploy

Version Management

Checking for updates: The dashboard shows a badge when newer versions of your components are available.

Upgrading components: Select which components to upgrade (or upgrade all), with an option to dry-run first.

Locking versions: Mark individual components as locked: true to prevent auto-updates.

Rolling back: Return any component to a previous version via the deployment detail view.

Best Practices

1. Use Semantic Versioning -- 1.0.0 to 1.0.1 for bug fixes, 1.1.0 for new features, 2.0.0 for breaking changes
2. Lock production deployments -- use exact versions or set locked: true for stability
3. Test in staging first -- deploy to a staging team before production
4. Use version ranges wisely -- ^1.0.0 for development, 1.2.3 (exact) for production, ~1.2.0 for CI/CD
5. Document breaking changes -- include changelogs with your version updates

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