you got Qs we got As.

Simmis is control infrastructure for work shared by people and AI agents. Each persistent Team connects its participants to the same accepted managed state, tools, history, and repeatable work.

When work could change accepted managed state, Simmis can isolate the attempt and return its result for review rather than quietly making every experiment official. The current product is a development environment rather than a hardened production system of record.

Simmis gives people and AI helpers one shared place to work. They use the same company memory, try work without changing the official version, and ask a person to approve important changes.

Most agent products treat work as temporary and private. Context is reconstructed for each run, decisions scatter across conversations, and tools act against systems that do not share one history.

Organizations are shared and historical. Simmis closes that mismatch by giving people and agents persistent shared context and a controlled way to change accepted managed state. More work can happen without every attempt immediately becoming official.

In the product, people and agents work in persistent Teams. Dvergr calls the underlying runtime context a room. Each Team stays connected to the same work, shared context, and history while keeping its participants distinct.

People can supervise, redirect, and hand off work. Agent activity can continue asynchronously and return as visible artifacts or proposed changes. Participants share the work and accepted managed state alongside any activity in the chat window.

A knowledge base or RAG system primarily helps an agent retrieve relevant material. Simmis treats knowledge as part of registered organizational state that people and agents can query, work from, propose changes to, and inspect historically.

Documents remain evidence, but they are not the only form in which the company exists. Decisions, obligations, structured records, provenance, work status, and rejected alternatives can also be represented and related.

Today, Simmis combines persistent Teams for people and agents, shared knowledge and structured managed state, durable or scheduled agent work, branching, proposals, and retained history.

It is best suited to trusted internal workflows such as market research, document work, technical investigation, and recurring operational tasks. Packaging, onboarding, detailed delegated authority, guest access, and production guarantees are still developing.

Suppose a Team needs a recurring competitor briefing. Its shared context already contains the company’s market assumptions, prior research, sources, and earlier decisions. Two agents can investigate from the same basis without rewriting accepted managed state as they work.

They return evidence and proposed updates. An authorized reviewer compares the results, resolves disagreements, merges the useful changes or discards the attempt, and keeps the history of what was considered. The next briefing begins from accepted knowledge rather than reconstructing the company’s context again.

Agents are probabilistic, while shared mutable state is unforgiving. A branch gives an agent a separate basis on which to investigate and make consequential changes while accepted managed state remains unchanged.

This changes the review bottleneck. An authorized reviewer can inspect completed work and its proposed changes rather than approving every intermediate step. Several attempts can proceed from the same basis, and only a merged result becomes official.

It does when review means reading every transcript or generated document. Simmis instead aims to concentrate attention on the records or files that changed, the supporting evidence, unresolved conflicts, and the choice of what becomes official.

Branching allows work to happen before review. Structured proposals and diffs reduce the amount of material a reviewer must inspect. For high stakes work, human review remains the default.

Before merge, an authorized reviewer can discard the attempt, merge only a supported result, or request another revision. If incorrect information has already entered accepted managed state, its retained history helps identify when it changed and supports a recorded correction.

This protection applies to state managed in Simmis. It cannot reverse an email already sent, money already transferred, or another irreversible external action. Those effects require separate capability limits and approval policies.

Agent workspaces and harnesses can research, code, operate software, and update connected systems. Simmis does not depend on pretending otherwise. Those systems primarily optimize a worker or task. Simmis organizes how work from many replaceable people and agents begins, remains separate, and becomes official.

The durable asset is company owned accepted managed state and the process through which proposed work is accepted or discarded. Models and runtimes may improve or be replaced without erasing the organization’s memory or decision history.

You can, and a narrow deterministic workflow may not need Simmis. The burden grows when the repository, database, chat instructions, execution environment, credentials, and retained history pile up.

Simmis manages registered organizational state and the agent workflows that change it in one controlled lifecycle. The alternative is an internal platform your team must continuously inspect, reconcile, and maintain.

No. A new company can establish Simmis as its shared operating core from the beginning. An existing company can place one real, consequential operation inside Simmis while the rest of the business continues where it already runs.

The goal is a deliberate boundary rather than a disposable experiment. Value grows as related work shares the same accepted state and history, but Simmis does not require a full organization migration before it can do useful work.

Using Simmis as a product should not require Clojure. The intended user experience is a working interface with documented installation and integration points.

Changing the current core stack, however, does require familiarity with Clojure or ClojureScript. The language supports the system’s emphasis on immutable state, explicit transitions, structural sharing, and programmable abstractions, but you can experience those advantages without adopting the implementation language.

Identity, visibility, and authority are different questions. Simmis currently has authenticated access, Team membership backed by Dvergr room ownership and membership, knowledge grants, RPC policy checks, scoped tools, and budgets.

Detailed delegated authority is not yet complete. Being able to participate in a Team should not imply permission to perform every action available to another participant.

Source and licences are available for Simmis and its public stack components, including Dvergr, Datahike, Yggdrasil, Spindel, Kabel, and Konserve.

You can inspect and build with the components today. A supported public installation path and operator documentation for the integrated product are not yet released.

Not yet. Simmis currently suits trusted internal workflows, technical evaluation, and teams helping shape the programming model.

Its state, Team, history, agent, branching, and proposal foundations are substantial, but packaging, onboarding, detailed delegated authority, guest access, test coverage, reliability guarantees, and managed cloud operations remain incomplete. It should run beside production systems of record rather than replace them. For high stakes work, human review remains the default.

Model memory and company memory solve different problems. A model’s memory belongs to that worker, model, or provider. Company memory must survive replacing the model, changing vendors, employee turnover, permission changes, corrections, and disputes over what was approved.

A new agent should inherit the organization’s tenure. The organization should not have to inherit a particular agent provider’s private memory system.