The current rush to integrate AI agents into the enterprise has hit a predictable wall: the tension between autonomy and control. Most development teams are currently grappling with the same nightmare—how to give an agent enough power to be useful without granting it the ability to accidentally wipe a production database or leak sensitive credentials across department lines. The industry has moved past the simple chatbot phase, but the infrastructure required to manage a fleet of agents that can actually execute code and manage state in a shared corporate environment remains fragmented and risky.

The Architecture of a Model-Agnostic Harness

At the center of this challenge is qm, a multiplayer agent harness designed to decouple the intelligence of the model from the infrastructure of the execution environment. The system is built on a headless core written in Node.js and TypeScript, utilizing Fastify for its HTTP interface to ensure high-performance request handling. To manage the complexities of persistent state, qm integrates Postgres, which serves as the central nervous system for user data, session histories, task queues, and agent memory.

One of the most critical design choices in qm is its commitment to model independence. Rather than locking users into a single ecosystem, the core is engineered to interface with a variety of models, including Pi, OpenCode, Codex, and Claude Code. By placing session storage, sandboxing, and memory functions behind a standardized interface, qm ensures that the underlying LLM provider can be swapped without rewriting the agent's operational logic. In a production setting, this is handled via a single wiring file that defines which implementation is currently active.

Deployment is handled directly through the operator's own infrastructure, specifically AWS or Fly.io, ensuring that data residency remains under the organization's control. The qm CLI provides a validation layer for deployment directories, allowing teams to initialize their environment with the following commands:

npm exec --yes --package=@yc-software/qm@latest -- qm init . --org --target

npm install

To bridge the gap between the headless core and the end user, qm provides a web UI built with Vite and rendered via Lit, alongside a Slack plugin based on Bolt. This allows the agent to exist where the work already happens, moving the AI from a standalone tab into the flow of team communication.

The Shift from Simple Prompts to Scope-Based Isolation

While many agent frameworks focus on the prompt, qm shifts the focus to the scope. The fundamental unit of the system is the scope, which creates a hard boundary between individual and shared workspaces. In a typical organizational deployment, an employee's personal workspace operates in total isolation. However, when the agent moves into a shared scope—such as a specific Slack channel or a group message—multiple users can collaborate with the same agent instance.

This is where the architecture deviates from standard AI wrappers. Each scope is not just a logical grouping but a fully provisioned environment. Every scope possesses its own dedicated memory, file system, keychain, permission set, scheduled cron jobs, web apps, and a permanent sandbox. The execute tool does not run commands on the host machine; instead, it operates within a permanent computer assigned to that specific scope. This means that any tools installed or configurations changed by the agent persist even after a session ends, effectively giving the agent a long-term digital workspace.

Security is managed through three distinct operational modes that dictate how the agent interacts with these tools. Strict mode is the most conservative, pausing all tool calls for human approval, with the exception of two specific turn-ending operations that do not impact the system state. Auto mode, the default setting, employs a classifier to inspect external data and tool results before they are passed back to the model, with the option to route these through a custom inspection proxy. Dangerous mode removes these safeguards entirely, allowing for maximum autonomy at the cost of oversight.

Regardless of the chosen mode, qm enforces a system-level command policy. This is a hard-coded safety layer that rejects destructive operations—such as recursive deletions or destructive SQL commands—regardless of whether the user or the model approved the action. The agent acts as a proxy for the collaborating user's credentials and permissions, and every single action is captured in a comprehensive audit log for forensic review.

Beyond the runtime, qm addresses the long-term maintenance of agent infrastructure through a strategic separation of the deployment repository. Infrastructure settings, custom tools, and sandbox images are stored in a separate `deploy/layers/` directory. This allows the core system to remain byte-for-byte identical to the upstream source, minimizing the friction of updates. Teams use `update-qm` to merge upstream changes and `upstream-pr` to contribute organization-independent improvements. To prevent the accidental leak of internal organizational identifiers, the system scans diffs and commit messages before they are sent upstream.

Furthermore, qm explicitly discourages the use of GitHub forks in favor of mirror repositories. This is a nuanced security decision based on how GitHub handles object networks; because public forks cannot be made private and their commits can often be discovered via SHA values on the public side, mirroring provides a cleaner break from the public eye. While this requires a more manual setup for CI workflows and secret management within the organization's account, it eliminates a significant metadata leak vector.

For practitioners implementing this system, the primary challenge shifts from prompt engineering to scope design. The decision of where to draw the line between personal and shared scopes, balanced against the infrastructure costs of maintaining permanent sandboxes on AWS or Fly.io, becomes the primary lever for scaling AI agency within an organization.

This transition from treating AI as a stateless API to treating it as a stateful, isolated entity marks the beginning of true agentic infrastructure.