One agent is easy. You give it a dev, a test, and a prod, you wire up a pipeline, and you ship. ALM at that scale barely needs a strategy - it needs a checklist.
The decision gets harder when the org wants its fifth agent, then its tenth. Each one arrives with a different sponsor, a different level of sensitivity, and a different shape, and how to lay out environments stops having an obvious answer. You can feel two pulls. One is to isolate everything - a dev, a test, and a prod per agent - which stays clean right up to the point where you're maintaining thirty-six environments and the isolation has become the overhead. The other is to pool everything into one shared set and move fast, which works until a single bad deployment takes down five unrelated solutions at once. The shape I aim for sits between them.
The approach I take is to carve environments up on purpose, using three checks weighted in order: cost, then access, then complexity. In practice I start with cost. A cost-centre exercise up front usually draws most of the lines on its own, and access and complexity refine them. Around that I give builders a locked-down sandbox to learn in, and I fan the build environments into shared test and prod. Decide that shape once and the fiftieth agent is no harder to place than the fifth.
Start with the cost-centre exercise
Cost is the check I start from, and I run it as an explicit exercise before provisioning anything. Sit down with whoever owns the budgets and map which teams or departments are funding which agents.
This one stopped being abstract a while ago, which is exactly why it leads. Copilot Credits are now the single currency the platform bills agent consumption in, and they sit pooled at the tenant - but they do nothing until you assign them to an environment. That assignment is the lever. Allocate a cost centre's prepaid credit pack to that cost centre's environment and you've turned a budget line into a hard, observable boundary. Wrap it in a billing policy per business unit, and the admin centre will hand you daily credit consumption per environment going months back - the chargeback evidence finance actually wants, rather than a figure you reverse-engineered from a spreadsheet.
Share an environment across two budgets and that legibility evaporates. The meter only reads at the environment boundary, so you can no longer attribute consumption to the team that's burning it. You also lose a free piece of blast-radius control: when an environment hits overage, the throttling stays inside it and other cost centres' allocated credits are untouched. Share the environment, and one department's runaway agent can starve everyone else's.
In most orgs the funding lines are the cleanest, least arguable boundaries you have, which is why this one exercise usually does most of the work of your environment strategy on its own. Group the agents by who pays for them, assign credits to match, and you've drawn the first and most important set of lines.
I run this first because the alternative is expensive: eighteen months in, the HR director asks what their agents cost and there's no clean answer, because it's been quietly sharing capacity with three other departments the whole time.
The other two corners: access and complexity
Cost usually draws the main lines. The other two checks refine them - and any one of them, on its own, is reason enough to give a solution its own lane.
Access to other agents or resources. If a solution needs to reach other agents, privileged connectors, or sensitive data sources - or if it acts as a hub that other things call - its security surface is no longer the same as its neighbours'. In a shared environment, every connection reference and security role you add for one solution sits alongside everything else. A dedicated environment lets you scope exactly what that solution can touch, without those permissions bleeding across the estate. Multi-agent patterns make this sharper still: once you're wiring agents together, you want clear walls around what can call what. In practice the wall is a data policy scoped to that environment rather than a tenant-wide compromise, alongside the connector and AI-feature controls that grouped rules let you hold consistent across similar environments.
Complexity. Some solutions are genuinely heavy - many flows, custom connectors, several knowledge sources, real orchestration, a release cadence of their own. A solution like that drags on any environment it shares. Its deployments are riskier, its rollbacks affect its neighbours, and its testing needs look nothing like the simple FAQ agent beside it. Its own lane lets it run its own pipeline and its own quality gates - Copilot Studio's agent evaluations, say - at a cadence that doesn't hold up the simpler agents, and it lets the thing fail in isolation when something goes wrong.
The thread running through all three checks is the same: any one of them means a solution's consequences - financial, security, or operational - no longer fit inside a shared boundary. That's the trigger. Not how important the solution is or how senior the sponsor, but whether its blast radius has outgrown the box you'd otherwise put it in.
Govern groups, not environments
Carving environments up by cost, access, and complexity would be a lot of repetitive policy work if you configured each one by hand. Environment groups are what stop that. Group your environments along the lines the strategy already drew - by cost centre, by purpose, by sensitivity - and apply rules to the group rather than to each environment in turn.
The rules are native and specific: sharing limits, solution checker, connector and AI-feature controls, back-up retention, even a default deployment pipeline. Publish one and it's enforced across every member and locked read-only locally, so a policy can't quietly drift out of line on a single environment. A new environment dropped into the group inherits the whole set the moment it joins.
This is the governance backbone, and it's worth treating as best practice in its own right rather than something you rebuild with scripts. Reach for grouped rules first, and let automation handle only the things they don't cover.
Give people a sandbox to learn in
None of this leaves anywhere for people to simply experiment, and they need one. Builders learning Copilot Studio, business users prototyping an idea, someone testing whether an agent is even worth building - that activity shouldn't happen in a real solution's dev environment, and it certainly shouldn't happen anywhere near prod. Give it a home of its own: a sandbox whose entire job is play.
The trick is that "sandbox" doesn't mean "ungoverned" - it's the opposite. A sandbox is where you can afford to lock the policies down hardest, precisely because nothing in it is meant to be real. Tight DLP so experiments can't reach sensitive connectors, no production data, and a clear understanding that anything built there is throwaway. The platform has the plumbing for exactly this: environment routing intercepts new makers and drops them into personal developer environments instead of the default one, and the same grouped rules govern those sandboxes by construction - tight controls and a data policy scoped to the group, applied without anyone having to remember. Lock the default environment down hard while you're there; it's where ungoverned building piles up otherwise. People get a safe place to learn without you policing every click, and the ideas that prove their worth get rebuilt properly in a real environment, on purpose.
A sandbox is cheap insurance. Without one, learning and prototyping leak into wherever there's space - usually a real solution's environment - and the boundaries you drew so carefully start to blur within a month.
Fan many dev environments into shared test and prod
Drawing a boundary per cost centre or per solution sounds like it multiplies everything by three - a dev, a test, and a prod for every lane. It doesn't have to. Separation is cheapest and most useful at the dev tier, and you don't need to replicate it all the way up. Multiple dev environments can fan in to a single shared test and a single shared prod.
So you might run a dev environment per builder, per solution, or per cost centre - wherever the checks told you to draw the line - all promoting their managed solutions, through native Power Platform Pipelines or a GitHub Actions and Azure DevOps setup if you want more control, into one governed test environment for UAT, then into one prod. The separation lives where building happens; the consolidation lives where release discipline matters most. Where a cost centre genuinely needs its spend walled off all the way to production, you keep its prod separate too - fan-in is the option you reach for when the upper tiers don't need splitting, not a rule that forces them together.
This is also why the dev tier can be cheap. Once a solution is unpacked and committed to a repo, the dev environment stops being precious - it's a canvas you build on before exporting back to Git, not the place your work lives. You can hand builders the free Power Platform Developer environments, or stand one up per feature, without it touching your licensing budget. The expensive, governed environments are the shared test and prod downstream, and those are exactly the ones the pipeline protects.
Automate the setup, not just the deployment
It's tempting to automate the deployment and stop there - the pipeline carries a solution from dev to prod, and that feels like the job done. But the provisioning around it is just as repeatable, and with grouped rules already handling governance, provisioning is what's left to get right. None of it needs to be clever - a rough starting point removes most of the variance.
Start with the environments themselves. Provisioning them by hand - a dev here, the shared test and prod there - means trips through the admin centre, chances to pick the wrong region or Dataverse setting, and environments that drift subtly apart by the time you're finished. Scripting the creation through the PAC CLI or the Power Platform admin PowerShell module, named to your convention and configured identically by construction, means every lane comes out the same shape. When the checks tell you to carve off a new one, you're running the same script with different inputs, not reinventing the setup.
Then the security groups. Environments should be bound to an Entra security group so access is managed in one place rather than fiddled per environment. Provisioning that group alongside the environment, and binding it at creation, means an environment is never born open - it has an owner and a membership list from the first minute. Tie that to your joiner/mover/leaver process and access stays correct without anyone having to remember to tidy up.
Group membership and role assignment fall out of the same idea. Adding the environment to the right admin groups, assigning security roles, and creating the application user for your pipeline are all things you'd otherwise do by hand every time - and the application user is the one that bites you. A service principal that works perfectly in dev will fail in test for no obvious reason if it was never added as an application user there with the right role. Scripting that step turns a recurring afternoon of confusing permission errors into a non-event.
Finally, the CI/CD bootstrap. The pipeline itself has prerequisites - an app registration, that service principal present in every target environment, a repo scaffolded with the solution unpacked, and the workflow definitions that promote managed builds upward. Standing these up consistently is the difference between onboarding a new lane in an afternoon and losing a week to plumbing. It's also the piece most worth turning into a template, because every solution you onboard after the first inherits it for free.
You don't need a polished platform to get the benefit. A starting point that creates an environment to convention, binds a security group, registers the pipeline's service principal, and drops in a working workflow already removes the bulk of the manual variance.
Match the ceremony to the consequence
The point of a strategy is that you decide it once and stop relitigating it. Start with the money - run the cost-centre exercise and let the funding lines draw most of your boundaries - then use access and complexity to refine them, give people a sandbox to learn in, and fan your build environments into shared test and prod. None of it is exotic. It's just decided on purpose, before you have forty agents and no plan.
Decide it on purpose and the estate stays legible no matter how many agents you add - that's the whole return on the exercise. The shape I'm working to avoid is the one that turns up by default: environments multiplying with no logic, or everything funnelled into a single bucket because that was the path of least resistance, until you've got thirty-six environments and no one who can remember why.