>_ The Manifest

The gap between “works on my machine” and “available to every employee” has derailed more projects than bad code ever will. For declarative agents, the publishing pipeline is built into the platform and the governance model is one IT already knows. Let’s take the HR Onboarding Buddy from F5 to production.

The Publishing Pipeline: Five Stages to Production

Publishing a declarative agent follows the same path as any Teams app. There are five stages.

Stage 1: Developer Sideload (Where It All Starts)

The F5 experience in VS Code is where development begins. The Agents Toolkit packages your app and uploads it to your personal scope. Only you can see it, only you can test it. Fast and iterative, but invisible to the rest of the organization.

# Preview your agent locally in Microsoft 365 Copilot
atk provision --env local

Stage 2: Share with a Small Group

Before submitting to the org catalog, share the agent with a small group of trusted colleagues (5 to 10 people) who can give you honest feedback in a real environment. Package the dev build and let them install it directly.

# Package the agent for sharing
atk provision --env dev

# Share to team membersi or groups directly
# Share with specific users
atk share --env dev --scope users --email '[email protected],[email protected]' -i false

# Or share for a specific group
atk share --env dev --scope users --email '[email protected],[email protected]' -i false

# Or share with all users in the tenant
atk share --env dev --scope tenant -i false

This stage is your last quality gate before handing control to IT. Use it to catch the edge cases your own testing missed.

Stage 3: Organization Submission

When the agent is ready for a broader audience, submit it to your organization’s app catalog. In the Agents Toolkit sidebar, click “Publish to Organization”, or run the CLI command directly:

# Submit the agent to the organization's app catalog for admin approval
atk publish --env dev

At this point, you hand control to the admins. The app sits in a “Pending approval” state until an admin reviews it.

Stage 4: Admin Review and Approval

An admin opens the Microsoft 365 Admin Center, navigates to Settings > Integrated Apps, and finds your HR Onboarding Buddy in the “Pending approval” list. They see:

  • App details: Name, description, developer info
  • Permissions requested: What Graph scopes the app needs, what APIs it connects to
  • Data access: Which SharePoint sites the agent reads from
  • Copilot agent details: The fact that this is a declarative agent, what actions it includes

Once submitted, your agent appears in the Microsoft 365 Admin Center under Integrated Apps with a ‘Pending approval’ status until an administrator reviews and approves it.

These fields in manifest.json drive what the admin sees:

{
  "$schema": "https://developer.microsoft.com/json-schemas/teams/v1.24/MicrosoftTeams.schema.json",
  "manifestVersion": "1.24",
  "name": {
    "short": "HR Onboarding Buddy",
    "full": "HR Onboarding Buddy: Declarative Agent"
  },
  "description": {
    "short": "Helps new employees navigate their first weeks",
    "full": "Answers onboarding questions using HR SharePoint content and real-time API data."
  },
  "copilotAgents": {
    "declarativeAgents": [
      {
        "id": "HROnboardingBuddy",
        "file": "declarativeAgent.json"
      }
    ]
  }
}

For our HR Buddy, the permissions are straightforward: it reads from the HR SharePoint site and calls two APIs (onboarding status and helpdesk). No broad permissions, no write access to sensitive data.

💡 Tip

Make your admin’s job easy. Write a clear app description, document the data sources your agent accesses, and keep your permission surface small. The faster an admin understands what your agent does, the faster it gets approved.

Stage 5: Rollout to Users

Once approved, the agent appears in the organization’s catalog. Users browse available agents or search for “HR Onboarding,” see your icon, description, and conversation starters, and start chatting with one click.

For a new employee like Alex, the experience is seamless: open Copilot, tap “What’s my first-week checklist?”, and get a personalized answer grounded in SharePoint documents and the onboarding API.

Access Control: Who Gets the Agent?

Once an admin approves your agent, they decide who can use it. Three options:

  • Everyone: All users in the organization see and can use the agent
  • Specific groups: Only members of specific Entra ID security groups get access
  • No one: Approved but not rolled out (useful for staged deployments)

In the access control panel, administrators can assign the agent to specific security groups, controlling exactly who in the organization can discover and use it.

For our HR Buddy, assigning it to a group called “New Hires 2026” makes perfect sense. Only employees who started this year see the agent. As new cohorts join, we add them to the group. HR staff might get a separate group so they can test the experience their new hires will have.

⚠️ Warning

Access control determines who can discover and use the agent, but it doesn’t replace data-level permissions. If your agent pulls from SharePoint, users will only see content they already have access to. The Microsoft 365 permission model still applies underneath.

This layered model: app-level access plus data-level permissions: keeps governance robust without requiring anything custom.

Version Your Instructions Like Code

Your instructions file defines the persona, boundaries, tone, and guardrails: everything that makes your agent your agent. Treat it like code:

  • Keep them in source control. Every change is tracked, every version is recoverable.
  • Review changes in pull requests. A one-word change in instructions can dramatically alter behavior. “Never discuss compensation” vs. “Avoid discussing compensation” produces very different results.
  • Test instruction changes in the Playground before merging. The Agents Toolkit gives you a fast inner loop: use it.

Your instructions are your agent’s code. Apply the same discipline you’d give any user-facing configuration.

Staged Rollout: Don’t Go Big Bang

Skip the big bang. A staged rollout works better:

  1. Pilot group: Start with 10-20 users who understand the agent’s scope and will give honest feedback. Your HR team is perfect for this.
  2. Expand to target audience: Once the pilot confirms the agent handles real questions well, roll out to the intended group (e.g., all new hires).
  3. Monitor and iterate: Pay attention to what users ask that the agent can’t handle. If 30% of conversations end with “I can’t help with that,” you’ve found your next sprint.
  4. Broaden access: Only expand to a wider audience after you’ve addressed the top gaps from monitoring.
💡 Tip

The “No one” access setting is your best friend for staged rollouts. Approve the agent, set access to “No one,” then flip it to a specific group when you’re ready. No redeployment needed.

Resources

Have questions or want to share what you're building? Connect with me on LinkedIn or check out more on The Manifest.