Introduction

Traditional High-Performance Computing (HPC) is central to most scientific computing and engineering applications. These systems are based on well tested, repeatable, and scalable compute processes that enable the large-scale generation and validation that the semiconductor and other industries depend on.

Integrating AI and agentic flows into this traditional model remains a challenge.  Where many agentic systems rely on “modern” compute architecture utilizing REST based communications and object storage, traditional HPC relies on POSIX based file systems and scheduler-based orchestration.  Combining these two different disciplines presents a challenge to many engineering and large-scale research enterprises.

This blog describes how Microsoft Discovery app can directly interoperate with existing traditional HPC deployments utilizing Azure HPC. Microsoft Discovery is an enterprise agentic AI platform for research and development, designed to help specialized agents reason, plan, execute, and learn in a continuous loop across data, tools, and workflows. It is built on Azure and designed to integrate with capabilities such as Azure HPC and Microsoft Foundry, while leveraging industry proven tools and customer flows, making it a natural bridge between AI-native reasoning and compute-intensive engineering execution.

Agentic AI in HPC

The value of agentic AI in scientific and engineering workloads is not just as a chatbot or code generator; it is the ability to participate in an existing workflow: write parameter files, launch simulations, inspect logs, summarize failures, generate follow-on jobs, and preserve artifacts for traceability. To do this effectively, agents must be able also read data from POSIX-based file systems and dispatch jobs to the scheduler. 

To maintain IP security, they must access data while respecting the access limits of the user that dispatched them and write data under the same RBAC rules as that same user. That way organizations can be assured that agents operate strictly under the dispatching user's access rights, so they cannot reach data the user isn't authorized to see and the data they write retains the permissions that the user who dispatches the agent enjoys.

Discovery app is currently only available on Windows.  Linux and Mac versions will soon be available.  In the meantime, enabling the Windows based Discovery app to leverage the capabilities on Azure HPC today with little to no change to the current HPC flow.

Reference architecture

The architecture has five primary components: a Windows VM running the Discovery app on Azure, an Azure NetApp Files volume that is mounted by both Windows and Linux clients, an Azure CycleCloud-managed HPC cluster with a Linux login node used for job submission and monitoring, and a scheduler that dispatches work to compute nodes.

• Discovery app on Windows: Runs on a Windows VM placed inside the same VNet, or reachable through controlled private networking, so it can access storage and the login node without exposing the HPC environment publicly.
• Azure NetApp Files: Provides the shared file namespace for input decks, scripts, logs, generated data, and results. Linux nodes mount the volume with native NFS. Windows can mount the same namespace through the Windows NFS client or an equivalent enterprise file-access solution.
• Azure CycleCloud: Provisions and manages the HPC cluster, including scheduler, login node, execute nodes, autoscaling, and cluster configuration.
• Login node: Acts as the controlled command endpoint. Discovery should submit jobs and query scheduler state from here, not run heavy tools directly on the login node. This protects the actual Cyclecloud scheduler and cluster manager from being overwhelmed if the dispatch volume is high. This also allows for scalability if there are many clients scheduling jobs at once.
• Scheduler: Incumbent schedulers that customers are already using with Azure Cyclecloud handles execution. Discovery creates scripts and submits them through the scheduler so compute runs on the correct nodes with the correct environment, licenses, and policies. This remains the same as how traditional HPC schedules jobs today.

Connectivity model

Running on a Windows VM in the Azure VNet aligns with many enterprises’ requirement that none of their data or IP can leave their network. Doing this avoids the need to run jobs through a user laptop or unmanaged public endpoint. This also allows the user to start an agentic workload then disconnect from the VM while the job runs and reconnect when they come back. Maintaining the same working model most engineers have with their HPC environment today.

For Discovery to access Azure HPC, it needs to map the Azure NetApp Files volumes and command access to the Linux login node. File access lets agents create and read files. Command access lets agents run Linux commands, submit jobs, and monitor execution. Discovery writes execution scripts to the ANF volume, then uses SSH to dispatch the job to the schedule with the execution script.

The advantage of this model is that the user can directly provide Unix-style paths to Discovery and tell it to execute tools without the user worrying about being on a Windows platform.  For example, CAD teams often provide setup scripts with paths to tools that users are supposed to reference in creating their own tool execution scripts.  Using this model, I just tell Discovery to use the setup script /mount/setup/tools/vendora.csh as a template and it will happily find the file and do so.  I can then tell Discovery to dispatch the job to the hpc queue and it will schedule to the appropriate SLURM queue where a system is provisioned and assigned to run using the new execution script Discovery creates.

This model also gets around the temporary limitation of Discovery app, unlike the enterprise Discovery service, only being available on Windows.  In this model, Windows is only acting as a terminal interface so it doesn’t matter that it’s not a platform that normally works with most EDA tools. In fact, users can deploy Discovery app on either x86 or ARM Windows since all the actual tools run on the Linux-based HPC deployment in Azure anyway.

Mapping Windows drive to NFS volumes

Discovery agents must understand how to access files on the mapped NFS volume from the Windows VM. The same file may appear as Z:\project\run1\exec.csh on Windows and /mount/project/run1/exec.csh on Linux. The skill or instruction file used by Discovery should explicitly describe that mapping and instruct agents to use Linux paths inside batch scripts and scheduler commands.

A typical instruction might say: the Windows drive Z: maps to the Linux mount point /mount. If Discovery sees /mount/designs/test.sv, it can read or write the corresponding Windows file at Z:\designs\test.sv. When generating job scripts, it should always use the Linux path, because those scripts run on the cluster.

Implementation steps

 

1. Deploy the HPC foundation

Start with the standard Azure HPC foundation: a virtual network, Azure CycleCloud, a scheduler-backed cluster, and shared storage. CycleCloud can deploy and manage Slurm clusters and supports external NFS mounts, including Azure NetApp Files. Configure the cluster so the scheduler and compute nodes mount the shared file system at a stable Linux path such as /mount, /shared, or a customer-specific project path.

Make sure that systems can ssh to the login node using a public/private key pair.  The login node should be accessible using a command like:

% ssh -i .ssh/keyfile user@login-node

2. Place the Windows VM in the same network boundary

Create a Windows VM that can reach both the Azure NetApp Files endpoint and the CycleCloud login node over private IP. The required Windows NFS client is available on Windows 11 Pro, Enterprise, and Education. It is not available on Windows 11 Home. Install the Discovery app on that VM. This VM becomes the user’s Discovery workstation for the HPC-connected workflow. Keep the VM inside the same security boundary as the HPC deployment, and use standard enterprise controls such as private networking, restricted inbound access, managed identity where appropriate, and least-privilege SSH keys.

3. Install Microsoft Discovery app

1. Download and install Microsoft Discovery app from:
   https://github.com/microsoft/discovery
2. Once installed, start Microsoft Discovery app and connect to your Github Copilot account in order to configure access to the LLM AI models.
3. Create a new project

4. Mount the Azure NetApp Files volume into Windows

Mount the same shared storage namespace into Windows. The Windows NFS client can map the NFS export to a drive letter such as Z:. The Windows NFS is sufficient for reading logs, results, and data files, and writing execution scripts, parameters, and configuration files. Heavy simulation I/O remain on Linux compute nodes running HPC tools.

To configure the Windows NFS Client, you will need to have administrator privileges on your Windows VM.

To mount the ANF volume with the Windows NFS client. 

1. Press Win+R
2. Run “optional features”
3. Select “More Windows features”
4. Expand “Services for NFS”
5. Enable “Administrative Tools” and “Client for NFS”
   
6. Click “OK” to install the components.
7. By default, Windows will mount the NFS volume as an anonymous user. To set the correct user, you can define the correct Linux User ID and Group ID in the registry.
   
   Note: This is an example of a functional baseline to mount a Linux volume with a user identity as an example.  Production environments should employ proper identity mapping for security.
   
   
8. Press Win+R
9. Run “regedit” to start the Registry Editor
10. Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ClientForNFS\CurrentVersion\Default
    
11. In Default, right click and add two new DWORD entires: AnonymousUID and AnonymousGID
    
12. Set the values to the decimal value of your Linux UID and GID. This will ensure that you connect to the ANF volume as the correct user.
    
13. Select OK and then launch the Command Prompt as Administrator.
14. To allow the NFS Client to accept the new registry entries, restart the NFS Client with the following commands:
    nfsadmin client stop

nfsadmin client start

 

15. Mount the ANF volume to a Windows drive:
    
16. You should now be able to access your NFS volume by going through the Z: drive.

5. Configure SSH access to the login node

Configure the SSH client on the Windows VM with a dedicated key for Discovery-driven access. The key should connect to the CycleCloud login node as the user (same as with NFS above) with permissions to submit jobs, read scheduler state, and access the shared project directory. Verify connectivity by connecting to the Cyclecloud login node using ssh from the Command Prompt. 

In this example, the username is ai4semi, the IP address of the login node is 10.16.16.25, and the cc_rsa is the keyfile located under the .ssh directory of the user’s home directory on Windows. Since this is the first time for this system to log into the Linux machine, you must accept the connection registration.  This will not be necessary for subsequent ssh connects by Discovery using this method.

 

 

5. Teach Discovery how to use Azure HPC

Now that you have the NFS and SSH connections established in Windows, you simply need to tell Discovery how to use these connections properly to run HPC workloads. In the Discovery chat window, tell Discovery to map the Z: drive on windows to the /mount volume on NFS and how to interact with the files.

The Windows drive `Z:` is mapped to the cluster NFS volume `/mount`.

- `/mount/<path>` on the cluster corresponds to `z:\<path>` locally.

- Example: when a file is referenced as `/mount/test.txt`, look at `z:\test.txt`.

Test to make sure Discovery understand by asking it to read a file on the NFS volume using POSIX nomenclature.

       read the contents of /mount/newfile.txt

Discovery should show you the file contents

 

 

Next, instruct Discovery on how to access and interact with Cyclecloud

      Connect to the CycleCloud login node over SSH using "ssh -i .ssh\cc_rsa ai4semi@10.16.16.25"

 

Then tell Discovery which scheduler Cyclecloud uses and tell it to check the queue.

 

       Cyclecloud is using SLURM as the scheduler. Check the status of the hpc queue.

 

Since the Windows VM is only used to run Discovery and the agentic AI part of the workload and the login node is not meant to run actual HPC workloads, be explicit with Discovery on how it should treat HPC job runs.

 

NEVER run EDA/build/simulation tools on the local system or directly on the login node. ALWAYS submit work to the Slurm scheduler via sbatch.

- The login node is for job submission and monitoring only — not for compute.

- Wrap every tool invocation in a batch script and submit it with sbatch.

 

 

6. Validate the end-to-end workflow

Validate that everything works by dispatching a simple test script to Cyclecloud

Create a batch script that references the Linux path, submit it to Cyclecloud.

dispatch /mount/proj/ai4semi/exec.csh to the hpc queue

 

 

 

7. Save the knowledge for future reference

Now that Discovery understands how to access Linux-based files on NFS and how to dispatch jobs, tell it to save the information.

Save this knowledge to a skill and use it for all subsequent job runs and file access for the project

 

 

You see that Discovery now saved the information on how to access files and run jobs to a SKILL.md for general knowledge and updated the copilot-instructions.md to ensure that all subsequent agents and engines understand how to access Azure HPC.

 

 

Note: These instructions are only scoped to a single project.  When creating a new project, you can simply tell Discovery to reach over to your older project to copy the knowledge:

copy over instructions on how to access NFS files and paths, and how to dispatch and execute hpc jobs from workspace1

 

 

 

 

If you want to make this a portable instruction that you can just load for each new project, tell Discovery to create a portable file.

package the instructions on how to access NFS files and paths, and how to dispatch and execute hpc jobs into a a single instruction I can provide to new workspaces

 

 

You can then copy the file to a central location like: C:\Users\ai4semi\project

Then for each new project you can tell Discovery to use this file.

read and understand the instructions in C:\Users\ai4semi\project\cyclecloud-hpc.instructions.md. Use for all agents and engines in this project and save this information as skills to use in the project

 

 

 

 

Operational considerations

• Identity and permissions: Keep SSH access scoped to the project and avoid broad administrative privileges. For NFS, verify UID/GID mapping and file ownership behavior before production use.
• Performance: Use the Windows mount for orchestration artifacts, scripts, and logs. Let Linux compute nodes perform heavy I/O through native ANF mounts.
• Security: Keep Discovery, storage, and the login node on private networking. Avoid public exposure of scheduler or storage endpoints.
• Scheduler hygiene: Enforce a rule that Discovery submits jobs through the scheduler and does not run heavy tools interactively on the login node.

Conclusion

Connecting Microsoft Discovery app to Azure HPC allows users to seamlessly use their existing HPC environment. The most practical approach today is to place Discovery on a Windows VM inside the Azure network, map the shared Azure NetApp Files namespace into both Windows and Linux, and use SSH to submit scheduler-managed jobs through CycleCloud.

Using this method, customers can quickly and easily use Discovery to integrate Agentic AI into their current HPC flows. Users can take advantage of AI agents to read and understand specification files, generate code and testbenches based on those specifications, run existing HPC tools on their Azure HPC environment. They can direct Discovery to use the scripts and resources which their CAD teams have developed. Users can create bookshelves by pointing to the documentation directories many tool vendors include in their installations, allowing Discovery to take advantage of documentation which most users don’t have time to fully digest.

Over time, native Linux support can reduce the need for Windows-hosted bridging. Until then, this architecture gives teams a secure, and repeatable way to let Discovery agents create, launch, monitor, and learn from real HPC workloads on Azure.