The Agent Needs a Landing Zone Before It Needs a Personality
The first question in too many agent workshops is: “What personality should it have?”
My first questions are less charming. Which subscription? Whose identity? Which data boundary? Where does state live? What can leave the network? Who gets paged when it fails?
An enterprise agent needs a landing zone before it needs a personality.
Start with the resource hierarchy
Microsoft Foundry now organises AI workloads around a top-level Foundry resource and project-level isolation. The resource is the governance boundary for model deployments, networking and security. Projects give teams a development boundary for agents, files, connections and evaluations. Connected services such as Storage, Key Vault and Azure AI Search remain independent Azure resources with their own governance.
That last point matters. A portal may present one smooth experience while the architecture still contains several resource providers, identities, private endpoints, DNS zones and policy surfaces.
Design the hierarchy before clicking Create.
Separate platform from workload
I prefer a platform team to provide reusable controls: approved regions, policy assignments, private DNS, central connectivity, logging destinations, model access patterns and base Terraform modules. Workload teams then own projects, agent behaviour, knowledge, evaluations and application-specific operations.
The boundary should not become a ticket factory. It should make the safe path the fast path.
At minimum, decide:
- subscription and resource-group topology;
- project isolation and environment promotion;
- model deployment ownership and quotas;
- managed identities and RBAC scope;
- private connectivity and egress control;
- state, file and knowledge stores;
- central logs, traces, metrics and alerts;
- content safety and evaluation policy;
- cost allocation, budgets and lifecycle ownership.
Agents multiply permissions
A normal application calls known dependencies through code paths engineers designed. An agent selects tools at runtime. That flexibility increases the value of least privilege.
Give each workload a managed identity. Scope access to the narrowest project and data resources. Separate read tools from write tools. Do not place broad credentials inside prompts, environment files or connection descriptions. When an action requires a user's authority, use an on-behalf-of pattern where supported rather than a permanently privileged service identity.
The tool catalogue is part of the threat model.
Network architecture is agent architecture
Foundry Agent Service can use private networking and customer-controlled Azure resources. Hosted agents and prompt agents have different execution paths, but tools still need a governed route to data. Plan delegated subnets, private endpoint subnets, IP capacity, DNS and egress before production traffic arrives.
An agent with a private model endpoint and a public, ungoverned tool is not private.
Production begins with ownership
Every project needs named owners for product, data, model behaviour, cloud operations and security. Define who can publish an agent, who can add a tool, who can approve a model change and who can disable the system.
Then define evidence: evaluation thresholds, safety results, latency, cost per successful task, tool failures and human override rate.
A witty assistant without these foundations is a demo. A restrained assistant with them can become infrastructure.
Personality can come later. First give the agent a place where it is allowed to exist.
The landing zone is an operating agreement
A landing zone is often mistaken for a network template. Its deeper function is to make organisational decisions reusable.
It defines where workloads live, how environments are separated, which regions and models are approved, how identity is issued, where logs go, how private DNS works, what policy is inherited, who pays and who responds to incidents. The infrastructure expresses an operating agreement between platform, security, data and product teams.
For agentic AI, that agreement must include model and tool authority. A project can be network-private and still unsafe if any developer can connect a production CRM tool or deploy an unreviewed model.
Establish platform capabilities
A reusable AI platform should offer paved paths rather than a blank subscription:
- project and environment vending;
- approved model catalogue and quota process;
- AI gateway or controlled inference route where required;
- managed identity patterns;
- private endpoints, DNS and egress controls;
- Key Vault and connection governance;
- search, storage and state patterns;
- central logging with workload correlation;
- evaluation and content-safety baselines;
- Terraform or Bicep modules with policy tests;
- budget, tagging and ownership controls.
The platform does not have to own every resource. It has to make the ownership boundary obvious and the compliant route easier than improvisation.
Projects are not tenants by magic
Project boundaries help teams organise assets and access, but architects must verify the isolation properties of every connected service. Search indexes, storage accounts, Cosmos DB, model deployments and observability workspaces may have their own sharing and RBAC decisions.
Decide whether isolation is per application, team, environment, tenant or data classification. High-risk workloads may require dedicated resources and subscriptions. Lower-risk experiments can share platform services with quotas and clear namespaces.
The portal’s visual hierarchy is not a substitute for a threat model.
Model access needs supply governance
Treat models as governed dependencies. Record provider, version or deployment, region, data-handling terms, context limits, safety behaviour, supported tools, cost and approved workloads. Evaluate before promotion and retain a rollback route.
Centralisation has trade-offs. A shared model deployment improves governance and utilisation but creates quota contention and a wider blast radius. Workload-owned deployments increase isolation and accountability but can multiply cost and policy work. Choose deliberately and revisit as demand becomes measurable.
Quotas are architecture. An agent that depends on a capacity tier needs behaviour for throttling, regional unavailability and model retirement.
Give tools an admission process
Every tool expands the system’s effective permissions. Require an owner, purpose, input/output schema, downstream identity, data classification, side-effect declaration, rate limit, test suite and emergency disable path.
Separate discovery from approval. Developers may explore tools in a sandbox catalogue, while production exposes only reviewed versions. Mutating tools should support dry run or proposal modes where practical. Sensitive actions should integrate deterministic policy and human authority outside the prompt.
An agent landing zone without tool governance is a runway with no air-traffic control.
Promotion should carry evidence
Moving from development to production should promote more than source code. Carry prompt and workflow versions, tool schemas, retrieval configuration, evaluation datasets, safety results, model route, infrastructure plan and operational runbook.
Define minimum gates:
- infrastructure and policy checks pass;
- permission and negative-path tests pass;
- capability and regression evaluations meet thresholds;
- cost and capacity estimates fit budgets;
- threat model and data review are accepted;
- owners, alerts, rollback and kill switch exist.
This evidence turns “the demo worked” into a release decision.
The personality of the agent may determine whether people enjoy using it. The landing zone determines whether the organisation can afford to trust it.