ORGANIZATIONAL CONTROL FOR AI WORK
Know your organization as it was, as it is, and as it could be.
WORKING ALPHA Open-source foundations are available now. Packaging and production guarantees are still developing.
TRUSTED BY
Organizations leveraging the Simmis stack.
WHY SIMMIS
AI work needs organizational control.
More agents and tools should not mean more coordination work.
AI makes intelligent work cheaper to attempt and easier to run in parallel. Disconnected agents, chats, documents, and databases make people reconstruct context and decide by hand which result became authoritative.
A stronger worker does not create a coherent organization by itself. Simmis keeps the shared basis, separate attempts, and path to accepted change in one control loop.
PUBLIC PERSPECTIVES ON AI AT WORK
These leaders describe their own organizations’ experience. These are external perspectives, not endorsements of Simmis.
“greater value comes from disciplined platform-orientation, not tool-proliferation”
“We have established a global technology stack together with a group-wide AI governance framework”
“That’s why we have a governance framework and set up a control plane”
HOW IT WORKS
Keep one basis. Branch the attempt. Adopt the result.
People and agents can explore consequential work without changing accepted organizational state. An authorized decision determines which result, if any, joins it.
- 01 · SHARED BASIS Begin from one accepted version.
Records, files, decisions, and relevant context have an exact starting state.
- 02 · SEPARATE ATTEMPT Give the work room to diverge.
Participants, tools, limits, and mutable execution state stay with the attempt.
- 03 · CONTROLLED ADOPTION Merge, revise, or discard.
Review the result rather than every intermediate step. Retain the decision and history.
CURRENT PROTOTYPE
Decide what becomes organizational truth and progress.
The working alpha combines persistent Teams, shared organizational state, bounded agent work, branches, proposals, and retained history.
Choose a scenario. Engineering, Marketing, and Accounting are example workflows shown in the real Simmis interface, lightly enhanced for legibility.
Engineering recover a failed operation
A team diagnoses a provisioning failure, tests a proposed correction, challenges its recovery design, and accepts the reviewed result.
- 00:00–00:23.6 · Define the failure
A person defines the incident, constraints, and authority for a shared retained Team context.
- 00:23.6–00:42.5 · Inspect and test
Agents inspect an imported source snapshot, reproduce the failure, test the proposed operation, and expose their tool evidence while accepted state remains unchanged.
- 00:42.5–00:57.5 · Review the proposal
The semantic summary orients the reviewer while the complete code and knowledge diff remains available for exact review.
- 00:57.5–01:03.5 · Retain the decision
The accepted recovery and identity decision becomes durable organizational memory linked to its proposal and evidence.
- 01:03.5–01:16.5 · Inspect accepted history
A question is answered from retained context, and Timeline changes only after the viewer selects a past point.
- 01:16.5–01:30 · Schedule controlled recurrence
The recurring check produces regression evidence and a review task on failure without merging a change automatically.
Inspect the foundations.
Open-source components underpin the prototype. Explore the code, check the current access and licence terms, and follow how the product is developing.