Agent apps, Foundry deployments, and enterprise AI control-plane patterns.
View All Tags
A public POC proves the product loop. A private MVP proves you can survive enterprise networking.
Those are different architectures. Do not fake the second by adding more env files.
Figure 1. Private endpoint pattern for App Service. Source: Microsoft Learn: App Service private endpoints.
Multi-agent shells rot when every new assistant becomes an if-else on agent ids. Microcopy forks. Export prefixes fork. Access checks fork. Soon the SPA is a customer-specific catalog pretending to be a product.
Default-open with overlays. Product feature flags gate shared UX. Per-agent overlay rows carry scope, starters, export prefixes, and access arrays. The SPA never parses JWTs to invent policy. White-label cores stay clean because domain agents are data, not code forks. Test matrices expand by flag, not by customer branch.
Figure 1. Shared shell UX is a product feature. Agent differences belong in overlay flags the API already authorizes. Source: Microsoft Learn: manage feature flags.
Figure 2. Feature flags gate surfaces. App roles still decide what the catalog may show. The SPA should not invent policy from JWTs. Source: Microsoft Learn: manage feature flags.
Most “AI app” demos collapse three different questions into one login button:
In a real enterprise agent webapp, those are three different control planes. Treat them as one and you get either a security hole or a support nightmare.
Figure 1. SPA calling a web API. Authentication gets you a token; authorization still has to happen on the API. Source: Microsoft Learn: authentication flows and app scenarios.
An agent that answers from documents is only as trustworthy as the document permissions behind it.
Teams often lock the chat endpoint carefully, then leave library browse and citation PDF downloads open to anyone who can sign in. That is not a knowledge boundary. That is a second door with a nicer UI.
*Figure 1. Product capabilities belong as app roles on the API. Source: Microsoft Learn: add app roles.
Enterprise agent programs often start from a menu: models, tools, maybe a multi-agent diagram copied from a keynote. The catalog feels like progress. Users still do not know which job the system is supposed to finish.
Start from ranked use cases. Decide orchestrator versus single agent versus tools per job. Pilot decision quality and handoff clarity before you bet the platform on a topology that looked good in a slide.
Figure 1. Pilot the job the shell must serve. Agent topology follows the use case, not a catalog of models looking for work. Source: Microsoft Learn: authentication flows and app scenarios.
Support opens a session. The UI says two searches and six tools. Foundry traces show something else. App Insights has a third story. Nobody can tell whether the agent searched knowledge, hallucinated a citation path, or the counter lied. That is not a cosmetic bug. That is a missing product surface.
Activity timelines must reconcile platform traces, MCP knowledge searches, and UI counts. Persist normalized events, not only chat bubbles. Count knowledge searches separately from generic tool invocations. Traceability is part of the customer contract for regulated knowledge agents.
Figure 1. The shell shows activity chips. Correlated traces must tell the same story, or support has three truths. Source: Microsoft Learn: Application Insights correlation.
Figure 2. Persist normalized activity events and reconcile them with platform traces. UI counts alone are not an audit trail. Source: Microsoft Learn: Application Insights overview.
Users expect ChatGPT rules: close the tab, come back, the thread is still there. Platform agent services often have their own conversation store. Your shell is a third thing.
If those three disagree, you get untitled threads from the portal, agents that look "stopped" after refresh, and incomplete chats that vanish after a new sign-in.
Figure 1. The shell acquires tokens and calls APIs. Conversation durability is a separate design. Source: Microsoft Learn: authentication flows.
Teams still celebrate when the container listens on the right port. For Foundry-backed agent webapps, that is the easy half. The hard half is who the app runs as, how OBO flows, and how egress reaches Foundry, Search, and storage without turning the VNet story into folklore.
Deploy the pattern as identity and networking first. Hostname and Node version are table stakes.
Figure 1. Foundry webapps deploy as identity and egress. VNet integration changes name resolution and outbound paths more than hostnames do. Source: Microsoft Learn: App Service VNet integration.