People first · technology second
SHAPER OS: a solid framework for evolving systems
SHAPER OS is an organisational framework for building and evolving systems with AI agents. It connects human intentions, responsibilities, action rules and verification of results. Business solutions build on this framework: shared building blocks adapted to your activity, with broad freedom of composition. You remain in control; technical details stay accessible to those who need them.
Solid foundations that allow movement
SHAPER OS is a framework for a human and AI agents working in tandem. The human brings intention, experience and judgment; agents expand their ability to explore and build. The framework connects that freedom with clear responsibilities and verification of results.
A cognitive immune system
Preserving the foundations that help us understand and act, while remaining free to question them: that is the purpose of the cognitive immune system. Counter-view, verification and correction help identify fragile assumptions, examine what holds up and evolve our thinking. The checking mechanisms themselves are also subject to scrutiny.
Bring different perspectives into dialogue
Agents from different providers can bring different reasoning habits and blind spots. Their counter-view helps compare assumptions and results, including those of the framework’s author. Diversity alone does not guarantee sound judgment: arguments must be examined and actual effects verified.
Learn without becoming stuck
A difficult experience teaches us something; it does not close off every future possibility. We preserve the facts and examine whether the causes of failure still apply. When conditions change, a new approach can be tried within an appropriate scope. This allows learning, improvisation and adaptation without losing our bearings.
Enduring intentions, evolving implementations
The SHAPER OS repository describes intentions, principles, roles and relationships; code belongs in separate implementations. Future agents may propose simpler or safer ways to realize those intentions. Working solutions remain versioned and reusable. Each change must preserve data, respect the mandate and be verified; principles can also evolve through an explicit human decision.
Two profiles, one architecture
The page begins with uses and organisation, then explains the technical mechanisms. Go directly to the level of detail that interests you.
Day-to-day business operations
You steer your business, clients and cases. We prepare and adapt the tools with you, without asking you to administer servers.
Technical architecture & governance
Containerized execution, access controls, AI model topology, backup strategy, and disaster recovery. Comprehensive specifications in the “under the hood” section.
Five ways to understand SHAPER OS
These five readings move from everyday needs to fractal architecture. They describe the same organisation at different depths; they are not access-permission levels.
Controlled autonomy
SHAPER OS lets systems work with bounded autonomy. AI agents observe what is happening, carry out the planned tasks and report anomalies; they repair only what their mandate allows, and everything else goes up to the level above. The human retains control whenever an action exceeds authorized boundaries.
Autonomous universes
A universe brings together the functional units that perform an activity: applications, services and agents, with their rules and dependencies. Each functional unit has its own database. A space groups the universes belonging to one entity.
Declarative orchestration
We describe what should exist, its dependencies and authorised operations. The governor maintains this desired state; makers carry out operations on machines and report results. SHAPER OS defines the framework in which these tools work.
Unit of responsibility & parent supervision
Responsibilities are defined for each universe. The agent maintains components within its mandate; deep changes go through the parent. The planned process prepares an isolated version, checks changes and authorises production deployment with a rollback option.
Recursive fractal architecture
A universe can manage other universes (Brick → Universe → Parent Universe → Root Universe); machines are where universes run, not a level of management. Every tier applies the same invariant cycle: intent → materialization → execution → observation → proof → repair → validation → promotion.
Repair here, escalate above
Swipe to see the whole diagram
Three layers: framework, execution and everyday work
SHAPER Three Layers connects three complementary roles: OS sets intentions and boundaries; Runtime carries operations and data; Workspace lets people see, request and act. This map describes the organisation. Software implementations and technical kits are separate projects.
Purpose and boundaries (SHAPER OS)
Intentions, ethics, responsibilities and mandates: what an agent may do, what must be checked and what requires a human decision. Framework documents translate into controls in each implementation.
The operational core (Runtime)
Identity, objects, queues, audit, agents, vault: what keeps running even if the UI is reinstalled. This is what you deploy with the bricks (vault, queue, logger, maestro, bridges).
The work surfaces (Workspace)
Applications, conversations and voice provide access to Runtime. This layer names the work environment as a whole; SHAPER Workspace is the solution that brings together the team, its cases and its tools.
Full three-layers map
The SHAPER Three Layers repository explains the relationships between OS, Runtime and Workspace for people and agents building or evolving the system.
Three layers of one system
Swipe to see the whole diagram
Design scenario: a fractal SaaS for managing online stores
How the exact same recursive mechanics orchestrate one shop, a client’s shops, then an entire multi-tenant platform. The foundation is public and verifiable; the business brick is shaped for you. The detail is on the page « The SaaS fractal ».
The store agent: autonomous in its frame
The shop owner steers their shop with Helm, within their jurisdiction: “Update my products”, “Analyse my errors”, “Stage the next version”. The agent knows its own shop’s environment, whatever technology runs it, its tools and its limits. A risky action, or one beyond its frame, is escalated to the parent.
The shop manager: parent universe of the stores
Within their space, the client uses Helm to steer a management universe connected to their shops. This manager observes their state, receives alerts and coordinates authorised changes. Deep changes go through the parent and are carried out by makers.
Multi-tenant SaaS: grandparent universe
The SaaS acts as governor: it maintains the registry of what should exist according to approved orders and service rules. Makers consult this registry, carry out authorised operations and report results. The same logic recurs at several scales.
One single architecture, all technologies
A packaged shop, a hosted service, or a bespoke application: we do not build one fragmented system per technology. SHAPER provides the common frame and the conventions; each universe brings its own specialisation. The public foundation deliberately ships no third-party product, which is what lets it carry several of them.
The SaaS fractal, from one shop to the fleet
Explore the client space, its jurisdiction, steering through Helm and cooperation between governor and makers.
The same mechanics at every scale
Swipe to see the whole diagram
What this framework brings to your activity
What you choose on top: the solutions
SHAPER Enterprise, Workspace, Vox and Helm build on this foundation. Start with the one that touches your work.
A pillar, then your trade
The same core serves a tradesperson, an SME, an association. What changes is the tool shaped on top: follow-ups, stock, shop, members, planning.
An assistant connected to your data
An AI agent wired to your operational context can perform business tasks: classify, follow up, prepare, notify. Interfaces adapt directly to your workflows.
Not one cloud, not one model
We decide with you where the data goes: a provider, hybrid, or on your premises. A local model is possible when the case requires it. Architecture choices follow your real constraints.
You stay the owner
The code of your application is transferred to you — the assembly of open-source building blocks and the specialisation programmed for you; hosting, export and the backup policy are written into the contract. We can run it for you, or hand it over. Shaping is the method; Shaper OS is the operating model underneath.
Sovereign by design, not by promise
Sovereignty is not declared in a brochure: it is decided in how things are built. Here is what the foundation imposes on every project, and what remains to be written into the contract.
A dedicated space for each organisation
The space groups your universes. Within each, functional units have their own data and defined access. The project specifies boundaries between organisations and the controls needed to verify this separation.
Your secrets in your vault
Passwords and access keys are encrypted in a vault belonging to the universe. The key that opens it does not travel with it, and the backup has its own key.
The way out written in from the start
The universe template provides for an end-of-life declaration: what becomes of your data at the end, and what is handed to you. The export format is set in the project contract.
Interchangeable AI models
No model is carved into the foundation: we keep the ones that work from your machine, and change them when the landscape moves. What is sensitive can stay on a local model, or with a provider you accept.
Free to take over
Mainstream technologies, delivered documentation, and a public foundation that another competent team can read and redeploy.
What design does not do on its own
When an outside service is used, for example speech recognition during a call, the data concerned passes through it, and that is written down. Hosting, export and backups are set in each project’s contract.
Business continuity and modular resilience
Business continuity aims to limit the interruption of your operations during updates and to preserve your data through each evolution; its scope is written for each project. Resilience relies on five complementary backup tiers: the universe container, persistent volumes, transactional databases, versioned source code, and an off-site encrypted replica.
Five safety nets, one per layer
Swipe to see the whole diagram
Rebuild the system and recover your data
The recovery plan describes how to restore a usable system after a major incident: prepare a machine, retrieve the required images, restore data and check services. Recovery scope and requirements are defined for your project.
Duration depends on image availability, networking, storage and the data to restore. A recovery exercise checks the process and measures delays in your configuration.
What bounds recovery time
Swipe to see the whole diagram
Under the hood: for those who want to know or understand the engine
This section describes the technical side: where the code runs, who accesses what, which AI models, backups and recovery. An owner can skip it. A CIO or CTO should be able to read it without a meeting.
Runtime contract
Standardized Linux and containerization (Podman). Deployable on cloud servers, VPS, on-premises hardware, or an isolated Linux workstation. Operations can be fully managed by us or handled by your team.
Model and agent independence
Each task specifies its needs: result quality, response time, required context and budget. Models are evaluated on these tasks from the chosen environment. Selection may favour lower cost, better performance or a spending ceiling. If no model meets requirements, the system asks for a decision rather than silently selecting one.
Case 1: images already cached
Container images are already present (local cache or registry). The technical foundation deploys without rebuilding images; data restoration comes next.
Case 2: images pulled or rebuilt
Fresh machine or remote registry: fetching and building containers scales with network bandwidth and compute capacity prior to launch.
Case 3: restoring business data
Databases and volumes are restored, then their consistency and service operation are checked. Duration depends on volume, storage, networking and restoration operations.
Five backup levels
A copy of the universe container; persistent-volume archives; database exports; versioned code; an encrypted off-site copy. These protections cover different needs and complement one another. The restoration process is defined and tested for the chosen environment.
Control data flows and access
Deploying local models enables processing sensitive data without third-party transit. Compliance is grounded in traffic isolation, audit logging, and transparent qualification of technical processors.
Nothing of yours is published
Client data, secrets and deployment-specific configuration stay outside public repositories. Shared code uses separate configuration for each deployment. Publication checks look for information that must not be exposed.
Documentation usable by humans and agents
The repository addresses two readers. Humans climb by level, from owner to architect. AI agents are routed by capability: powerful models get the principles everything derives from, fast models get literal steps and explicit stopping points. The documentation is itself put to the test: an agent that has never seen the system must be able to act without a human explaining anything. Otherwise, the documentation is what is at fault.
Public repository and verification
The installation kit and architectural conventions are public: the system’s law can be read and verified before any commitment.
Choose by cost and performance
Swipe to see the whole diagram
A separate project: PodMesh
PodMesh manages the containers carrying universes: creation, movement with memory state, replication and recovery. Its fractal organisation supports work at several scales on independent Linux machines. This independent project can be used with SHAPER OS.
Explore the documents and implementations
The SHAPER OS V1.15 framework sets out intentions, principles and contracts. SHAPER Three Layers describes the organisational layers. The V1.14 kit contains a technical implementation and its tests: it lets you inspect mechanisms while keeping that software distinct from the broader framework.
Frequently asked
- Do I need to understand IT to use it?
- No. You talk about your trade; we shape the tool. The technical section above is for those who want to inspect, not an entry requirement.
- What role do AI agents play in SHAPER OS?
- Agents help understand, prepare, carry out and verify work. SHAPER OS organises their work with people: mandates, responsibilities, boundaries and correction. Specific agents and tools are chosen for each project’s needs.
- Where does it actually run?
- Wherever your obligations and choices require: in our cloud, in the cloud of your choice (including a certified health-data host when health data is involved), on our machines, on yours, or on an isolated Linux workstation we deliver. It is in your name or run by us, and that is written into the contract. If your data must not pass through the big platforms or through American or Chinese model providers, the chain is chosen accordingly. Cloud is not forbidden: it is a cursor, not a religion. The sovereignty detail is on the AI page.
- Is PodMesh the same thing?
- SHAPER OS defines the organisational framework and action rules. PodMesh carries out management operations on the containers that host universes. The projects can work together, and PodMesh can also be used independently.
Curious whether this is for you?
Owner or CIO: we talk about your activity first, not the tech. Thirty minutes to see if the subject resonates, no strings, and what comes next is decided together.