Guide / Hosting & operations

A library in your process

You host the app.
Not another squad server.

The .NET application runs the native runtime and MAF agents. There is no mandatory MCP service, backend process, or additional agent server to install.

For a business application, ProjectPath can identify an isolated bid, feedback, or knowledge-article case directory. It is storage for authorized inputs, evidence and session state, not a requirement that end users work in a source-code repository. See the RFP portal job example for the host boundary.

The smallest deployment is your existing app.

Your .NET process · One active owner per project

Application boundary

Configured IChatClient
Human approval and question UI
Explicit host functions
Lifecycle and cancellation

Native runtime

Coordinator and specialist MAF agents
Released skills and instructions
Bounded dispatch and gates
Deterministic Scribe

Outside the processWhy it is needed
Model provider or local model endpointYour IChatClient must reach a compatible model. The runtime does not include weights, inference hosting, credentials, or a model subscription.
GitHub, Git, and APM dependenciesNeeded during release acquisition. A complete preinstalled artifact tree can remove this network dependency during execution.
Writable project storageHolds project inputs, allocated outputs, and versioned native state. Preserve it across process restarts.
Optional external capabilitiesOnly those your registered functions actually use, such as a search API or an authenticated cloud operation.

The release's APM target is called copilot because it selects an artifact layout. It does not mean the native runtime calls Copilot CLI or needs its MCP service.

Choose the host you actually need.

Responsibility matrix
ConcernLocal CLIDesktop appYour web/service host
ExecutableThe repository sample or your console app.Your .NET desktop process.Your own API and worker application. Not shipped here.
Human interactionConsole approvals and questions.Your confirmation dialogs and input UI.Your authenticated, correlated approval/question flow.
Model ownershipLocal host configures IChatClient.App configures IChatClient.Service configures provider identity, model selection, quotas, and tenant policy.
Project isolationDedicated writable checkout.User/workspace isolation.Server-chosen tenant/project mapping, storage isolation, and tool authorization.
State ownershipOne running owner per project.Serialize all workspace turns.Route each project to one active worker. Own the queue and ownership protocol.
StorageLocal disk retained between runs.Durable app/project storage.Persistent volume with verified locking and backup behavior. Not an ephemeral instance filesystem.
LifetimeCtrl+C, await completion, dispose.Cancel on user request and close gracefully.Graceful drain, cancellation, recovery, idempotent tools, and operational monitoring.

No turnkey service is included. There is no shipped web API, Docker image, Helm chart, managed Azure service, approval transport, or distributed job runner. Cloud hosting is possible by deploying your own consumer app, not by enabling a library flag.

A suggested service design, not a deployment recipe

If your users need browser access, the following is a design checklist for a service you build. A container platform, VM, or managed application host may fit, but none removes the native runtime's ownership and human-interaction constraints.

  1. Authenticate at your application boundary

    Map identity to allowed tenant/project IDs. Resolve filesystem paths server-side. Never pass an arbitrary browser-supplied path, tool allowlist, model credential, or approval assertion into the runtime.

  2. Queue work for the correct project owner

    Maintain one active native run per project. Different isolated projects can be handled by different workers. Do not scale horizontal replicas against the same state and assume the local file lock is a distributed coordination service.

  3. Acquire and preserve the artifact installation

    Pre-acquire the pinned release into an approved image or artifact store when practical. Record provenance and validate the complete deployed tree. Keep the project-bound release available throughout its session lifetime.

  4. Implement a genuine human callback

    Show the exact proposal, arguments, relevant evidence, and project identity to an authorized person. Bind the answer to that pending request, reject replay or stale answers, and honor cancellation. The native callback waits within the run's timeout; durable suspension and cross-restart resumption are not shipped.

  5. Constrain host effects and capture receipts

    Use least-privilege credentials for narrowly scoped tools. Implement idempotency and cancellation where possible. Extract evidence only from successful results. Deny by default if no authorized human responds.

  6. Report the real outcome

    Keep the run ID, scope, status, partial evidence, and exception diagnostics. A transport timeout is not proof that an external operation failed or rolled back. Reconcile actual effects before retrying.

Do not leave a user-facing HTTP request open for an entire long-running workflow by accident. Your job API and UI can observe host-owned job state, but that job layer is distinct from the native Scribe and must not rewrite it. A background worker with human callbacks is still Mode = "interactive"; it does not turn this preview into autonomous mode.

An operational checklist worth keeping

Before launch

  • Pin the library and artifact release independently.
  • Verify installed profiles and required council/intake seats.
  • Configure provider secrets outside the repository.
  • Test denial, unanswered questions, and missing evidence.
  • Validate storage locking on the actual deployment filesystem.

During each run

  • Keep one project owner and bound all call/depth/time budgets.
  • Display exact approvals, not just a generic “continue”.
  • Isolate tool resources and protect Scribe state.
  • Record honest receipts and observed provider usage.
  • Surface partial and blocked results without a success label.

On shutdown or failure

  • Stop admitting work, cancel if needed, and await active runs.
  • Dispose runtimes only after execution settles.
  • Let the application own model-client disposal.
  • Preserve evidence; reconcile external effects before retries.
  • Do not delete a live lock to force another worker through.

For maintenance

  • Back up project data and native state consistently while idle.
  • Retain the matching artifact tree and configuration.
  • Protect transcripts, questions, outputs, and logs as sensitive data.
  • Test restore and interrupted-run behavior.
  • Review compatibility before changing release or roster bindings.

OpenTelemetry is optional. Your host owns exporters, access controls, redaction, retention, and provider pricing. Unknown model costs are not zero-cost runs.

GitHub Pages hosts these docs. Not the agents.

This site is plain HTML, CSS, JavaScript, and SVG. GitHub Pages serves those files under the repository path. It does not execute .NET, hold model credentials, persist squad sessions, or expose an approval endpoint.

A maintainer must activate the repository's Pages publishing configuration. The existence of docs\ or a Pages workflow does not mean that GitHub settings have been enabled. See Pages activation and maintenance.