Most company-wide agent projects break at the same seam: one assistant, one memory, one keychain, and thirty people writing into it. qm refuses the shared brain. Every employee gets an isolated workspace, and so does every channel, group message, and project. Scope is the unit of everything, not just conversation history. Each person and each room carries its own memory, files, keychain view, permissions, crons, web apps, and durable sandbox.
That reads like a partitioning detail. It is the decision the rest of the system hangs off. Once a scope owns a sandbox and a credential view, "make the agent work for the whole company" stops being an integration problem and becomes an identity problem, which is a much better problem to have.
The sandbox is a computer, not a session
The agent gets a small, fixed tool surface. One of those tools is execute, which runs commands in the scope's own isolated sandbox. The README calls that sandbox a durable computer, and durable is doing real work in that sentence: installed tools stay installed. Whatever you set up on Tuesday to parse a vendor export is still sitting there on Friday. Compare that to the usual pattern where every session starts from a clean image and the agent spends its first four tool calls rebuilding the same environment.
Underneath, a headless core handles API, identity, policy, and scheduling alongside the agent loop, with Postgres holding sessions, memory, and the queue. The web UI, admin panel, and public portal are optional plugins over the core's HTTP API. Slack is an in-process plugin the core starts and supervises through a direct service client. The core runs TypeScript on Node with Fastify for HTTP, the Slack plugin uses Bolt, and the web UI builds with Vite and renders with Lit.
The harness itself is a substrate, not a commitment. Pi, OpenCode, Codex, and Claude Code all drive the same core. Session store, sandbox, and memory sit behind interfaces too, with production implementations swapped in through one wiring file. A deployment that outgrows its model vendor changes a line, not an architecture.
Three postures, and a policy that never switches off
Security here follows the local coding agent model: the agent acts as the person it works for, using their credentials and permissions, and everything it does is audited. An org picks one posture and narrower scopes can only tighten it.
Strict pauses every harness tool call for human approval, with an exception for the two no-effect turn enders. Auto, the default, runs a classifier over provenance-labelled external data and tool results before they reach the model, and a deployment can point that classifier at its own screening proxy. Dangerous drops screening and inter-call pauses.
The part I would highlight to anyone evaluating this is the predeclared command policy. Approval rules and hard denials for things like recursive deletes or destructive SQL apply in every posture, Dangerous included. That is the right shape. Postures govern how much a human watches; the command policy governs what is never allowed to happen regardless of who is watching.
Customization is treated as an operations problem
Everything company-specific lives in a deployment directory that the qm CLI validates and deploys. Initialization materializes a deployment skill for an agent and walks through infrastructure, web sign-in, connector credentials, optional Slack access, deployment, and live verification, with no source checkout required. Each deployment runs in the operator's own cloud account. The repository ships no production deployment workflow and initialization does not enable one.
Then there is the private fork guidance, which is the most unusual documentation in the repo. Some organizations want the whole codebase in one place so engineers and coding agents can read core and customizations together. The README tells you to build that with a bare clone and a mirror push, and never with GitHub's Fork button. The reasoning is concrete: a GitHub fork inherits the visibility of its parent, so a fork of a public repo cannot be made private, and it shares one object network, so commits pushed to the fork stay fetchable by SHA from the public side. The plain clone avoids both and costs you one thing, which the README names honestly: upstream CI workflows now run live in your account, so supply their secrets or disable them.
Two skills maintain that boundary. update-qm merges upstream in and opens the sync PR. upstream-pr cuts a branch from upstream/main and scans the outgoing diff, commit messages, and screenshots for organization identifiers before pushing. Core stays byte-identical to upstream, which keeps merges small.
One last thing that tells you who this project expects to be doing the typing. Contributions are accepted as human-written text, not code. You describe the change informally in a text file under adrs/, and if there is agreement, the maintainers handle the implementation.
GitHub: https://github.com/yc-software/qm
Curated by Agent Palisade — practical AI for small and mid-sized businesses.
Top comments (0)