Where should the kernelProcess object exit?

[drive-files]

Regarding the KernelProcess in https://github.com/microsoft/semantic-kernel/tree/167308f53c3ea15aed5ed1140210eed56474c968/dotnet/samples/GettingStartedWithProcesses

Take this code for example -
`
// Build the process to get a handle that can be started
KernelProcess kernelProcess = process.Build();

    // Start the process with an initial external event
    await using var runningProcess = await kernelProcess.StartAsync(
        kernel,
            new KernelProcessEvent()
            {
                Id = ProcessEvents.StartProcess,
                Data = null
            });

`

Question is: Where should the kernelProcess object exit?

In an ASPNET Core App?

• the HTTP protocol is a disconnected protocol, so it can't persist there. Attempting to persist as a Singleton will be difficult if hundreds of users login into a successful website.

In a Windows Console/Desktop App?

Seems possible, but API Keys cannot live in the App. No matter where I keep them on the remote server, they have to travel down the internet.

What do you say? Or Am I doing something wrong?

[Samielakkad]

The key distinction is between a process definition/running object and a durable job. A KernelProcess started with StartAsync is an in-process execution whose lifetime is owned by the returned running instance (normally an await using scope). It is not, by itself, a durable workflow host that survives an HTTP request, process restart, or machine failure.

For a short process that must finish before the HTTP response, request scope is fine. For work that must continue after the client disconnects, use this shape instead:

1. The controller validates the request, creates a job/correlation ID, and puts work on a bounded server-side queue.
2. A hosted background worker creates its own dependency-injection scope and Kernel, starts and disposes the process, and persists status/results.
3. The API returns 202 Accepted plus the job ID; the client polls a status endpoint or receives streamed/pushed updates.

Do not keep one running process object per user in a controller, session, or singleton dictionary and treat that as persistence. For hundreds of users, add bounded concurrency, timeouts/cancellation, durable job state, and a real durable queue/workflow system if jobs must survive deployment or crashes. The Process Framework is currently experimental, which is another reason to keep a persistence boundary around it.

The Kernel and AI services should be configured on the server through dependency injection and created/scoped for each execution as their thread-safety requirements dictate.

For desktop clients, never ship the model provider API key in the application. The desktop app authenticates to your backend; the backend owns the provider credential and runs the Kernel/process. If you support bring-your-own-key, store each user's key encrypted in a server-side secret store and authorize access to it. A client disconnect then does not terminate the work because the background worker, not the connection, owns the execution.