A joint development team from Microsoft and Novo Nordisk has reimplemented an AI agent that medical experts use to explore Novo Nordisk clinical trial data, moving it onto Microsoft Foundry as a hosted agent. In a post published on Command Line, the authors say the switch simplified operations, strengthened the separation between user sessions and connected the agent directly to Foundry's tracing, evaluation and optimization tools.
What the agent does
The agent supports secondary analysis, meaning work that goes beyond a trial protocol, such as testing a hypothesis or comparing patient groups. According to the team, its central tool is code that it writes and runs in a controlled environment, after which it returns a summary and a chart. The project grew out of a forward-deployed engineering engagement. Its first production version ran on Azure Container Apps, with PostgreSQL storing conversations and Azure Container Apps dynamic sessions supplying sandboxes for code. That left the team responsible for scaling, session lifecycles, isolation, networking and telemetry.
Under the new arrangement, the authors say they still pick the models and tools and decide how the agent orchestrates its work. Foundry now runs the endpoint and the agent's identity, provides compute for each session, persists state and handles scaling.
Keeping sessions apart
One change the authors highlight is how sessions are separated. Each one now runs in a dedicated sandbox isolated at the VM level, which Foundry starts on demand and removes once a configured idle period passes. The team says this matters because the agent's own generated code operates on sensitive clinical data. Foundry Agent Service also offers private networking, which the authors say lets them govern inbound and outbound traffic for data that must stay within an approved boundary.
The platform does not absorb responsibility for security or quality, the team stresses. They still had to set access controls, protect and reduce telemetry, test the agent against their own use case and vet every system the agent can call.
Plan the network early
The authors argue private networking should be settled at the design stage. Sessions draw on IP addresses, and the subnet tied to a Foundry account cannot be changed later, so a range that is too small could turn a routine capacity increase into a wider infrastructure migration. They cite Foundry's current guidance: a /24 subnet for production, with /27 the smallest supported size for smaller deployments.
Traces and quality checks
Foundry tracing relies on OpenTelemetry and keeps data in Azure Monitor Application Insights; during the transition the team also sent traces to Langfuse. Because a trace may record prompts, outputs and tool inputs and results, the authors say clinical telemetry deserves the same handling as other sensitive production data, including redaction, minimization, retention limits and restricted access.
The team left its backend contracts untouched, so its existing evaluation framework could reach the rebuilt agent unchanged and score it with the same test set and graders, including comparisons with reference answers from subject matter experts. Those scores served as a migration baseline and a check against regressions, the authors say.
The post is the project team's own account rather than an independent assessment.
