Organizational Commons · Framework v5

Information as the organization's commons

Intelligence isn't in the AI — it's in how the organization accesses, connects, and acts on its information. The Organizational Commons is the layer that sits on top of AI and turns it into organizational intelligence: a Commons Farm that consolidates the data and a Commons Chat that makes it accessible to whoever needs to decide. It operates on the existing structure — it doesn't require redesigning it.

7 Design principles

3 Lifecycle stages

4 Learning loops

4 Access types

Central definition

Commons describes a resource accessible to everyone who belongs to the community, with agreed rules of use that protect its integrity without concentrating its control in the hands of a minority.

What the OC does

A system that eliminates information intermediaries

It isn't an AI tool. It's organizational-autonomy infrastructure. The difference is in the design, not the technology.

Sales team Waits for Monday

"How did the team evolve versus last week? What's the trend across branches?" — Answered in seconds, in natural language, with no analyst.

Area lead Waits for the close

Asks how much has been spent, at what rate it's being consumed, when a line will run out. Simulates scenarios in the same conversation without asking for approval.

Leadership Receives presentations

Accesses any level of detail when needed. Detects anomalies before they become problems.

Why "Commons"

The name isn't accidental. A commons is a resource accessible to everyone who belongs to the community, with agreed rules of use that protect its integrity without concentrating its control in the hands of a minority.

In the current model, information is the property of whoever holds the position. In the OC, information belongs to whoever needs it to act.

What the OC is not

It isn't a digital-transformation project. It isn't a dashboard with more features. It isn't an AI assistant that automates individual tasks.

It's a redesign of the organization's informational power model — with systemic consequences for autonomy, decision speed, and adaptive capacity.

Navigate the framework

Sections of the OC Framework

Section 01

The 7 operating principles of the OC Framework

These are the principles that govern how the commons is designed and implemented. They complement the seven conceptual principles of the OC developed in the paper, translating them into decision criteria for each implementation. Violating them isn't a technical error — it's a model error.

01

Information belongs to whoever needs it to act

Not to whoever holds the position that historically received it. The criterion is functional, not hierarchical.

02

Access by nature of the information, not by hierarchy

The nature of the information determines who needs it. The model has 4 categories — none depends on the asker's position.

03

The commons is designed from the periphery's questions

Not from the reports leadership already receives. The teams in direct contact with the market are the ones who most need real-time information.

04

The feedback loop is visible to everyone

The quality of the commons is measured in the field. Every query without an adequate answer is a visible blind spot — not a private anomaly for IT to resolve.

05

Budgets as context for action, not as a control ceiling

The base budget is built on the previous comparable period plus two adjustment options. It eliminates the annual negotiation cycle as an instrument of hierarchical control.

06

Implementation is incremental and produces results before it's complete

Starting with the highest-value questions for peripheral teams builds the confidence to continue before the system is complete.

07

Permanent anti-hierarchical audit — Principle 7

Every design decision is evaluated against the question: are we designing for team autonomy or for leadership control? The tendency to reproduce hierarchy inside the commons is the OC's central design risk — it happens when leadership unilaterally decides what enters, when "access levels" are created that replicate the org chart, or when information requires expert intermediation to be interpreted. The OC Architect has the explicit responsibility of detecting and naming that risk in every implementation.

Central design risk — audit permanently

When leadership unilaterally decides what enters the commons, when "access levels" are created that replicate the org chart, or when information is presented in a way that requires expert intermediation to be interpreted — the commons stops being a commons and becomes a new control mechanism with a friendlier interface. That outcome is exactly what the OC Framework exists to prevent.

Conceptual foundation

Rooted in the BetaCodex

The OC Framework is explicitly built on the BetaCodex ontology: the center/periphery distinction, transparency as autonomy infrastructure, and the rejection of the annual budget cycle as an instrument of control.

BetaCodex Law 5 — "Transparency as flow intelligence, not power obstruction" — is the philosophical foundation of the OC's concentric architecture.

The most relevant tension: BetaCodex §5 proposes near-radical transparency. The OC has an access-by-nature model with four levels. The convergence is in the destination — universal transparency. The difference is in the path: the OC provides for opening cycles as a transitional device while the organization matures its capacity to operate with open information.

The difference between Position → Access and Nature → Access is the distinction that defines the OC. The direction of movement is always toward greater openness — any differentiation observed at a given moment is a state of transition, not a permanent architecture.

Section 02

Access by nature of the information

The right question isn't "who do we give access to?" The right question is "what kind of information requires what kind of care?"

Current model

Position → Access

vs

OC Framework

Nature → Access

The access model

4 categories, 0 positions

This model doesn't describe fixed categories but states of transition. The direction of movement is always toward organizational Universal.

Universal access

Aggregate operational

Team results, area metrics, sales trends, branch comparisons. The same analytical context for everyone enables autonomous decisions and peer comparison.

Monthly sales · Trend by branch · Area operational indicators

Team and peers

Team operational

Internal metrics, project status, operational capacity. Visible to team members and their direct counterparts — not by hierarchy but by relevance to action.

Status of ongoing projects · Available capacity · Internal team metrics

By direct relevance

Individual nominal

Specific salaries, performance evaluations, identifiable client data. In the opening process, salaries first become visible grouped by team.

Individual evaluations · Identifiable client data · Salaries by team (progressive opening)

Explicit agreement

Sensitive strategic

Information whose economic value is tied to its safeguarding: intellectual property, patents, trade secrets, negotiations where premature exposure destroys value. Economic and legal criterion — not hierarchical. Regardless of the asker's position.

IP and patents · Ongoing negotiations · Pre-public financial data

The distinction that defines the model

In the current model, position determines access. In the OC, the nature of the information determines it. This distinction is fundamental because it changes the control variable — and that changes everything that follows: who decides, who acts, and at what speed.

Model dynamics

The direction of movement

The access-by-nature model isn't static. Opening is progressive, in opening cycles — each implementation wave moves more information toward broader access categories.

Salaries, for example, go from invisible to grouped by team before becoming individual. The movement always goes in one direction: more information accessible to more people.

Progressive opening denaturalizes hierarchy. When teams have access to the same information as leadership, leadership's role changes: from information filter to generator of context and criterion.

That role change is what the OC produces — and what Principle 7 protects throughout the design process.

Section 03

The lifecycle of the Commons: Design, Value, Team

The Commons isn't installed and left running. It goes through three stages: it's designed, it starts creating value, and it becomes self-sustaining in a team of its own. The difference between a commons that produces autonomy and one that reproduces hierarchy with a friendly interface lies in how these three stages are traversed.

01

The design of the commons

The most critical intervention of the project — and the one with the greatest risk of being done badly.

What it is

The co-design of the commons is the participatory process of deciding what information enters, with what access criteria, what questions it must be able to answer, and how it's structured so as not to reproduce hierarchies in a new form.

Those decisions require the OC Framework and experience applying it. Without this intervention, the commons is a data repository with a conversational interface. With it, it's organizational-autonomy infrastructure.

The risk Adaptant prevents

The most frequent error in conversational-AI implementations over proprietary data: leadership decides what enters the commons, creates access levels that replicate the org chart, and presents information in ways that require expert intermediation to be interpreted.

Principle 7 of the OC Framework and the participatory co-design process are exactly what prevents that outcome.

Deliverables of the intervention

01

Question map by role

The bank of questions the commons must be able to answer, organized by team and role. Designed with the peripheral teams — not with leadership.

02

The commons's access model

The classification of each data source according to the access-by-nature model. Documented, audited, and signed by leadership and teams.

03

Semantic datamart architecture

The specification of which sources are integrated, how they're transformed to be understandable in natural language, and what organizational-context metadata is added.

04

Phased implementation plan

The activation sequence of the commons, ordered by value to the peripheral teams. Each phase produces results before the system is complete.

Transitional phase — from embedded skill to the Commons Farm

Not every implementation starts with the full architecture

Some clients — for reasons of maturity, budget, or a strategic decision to validate before investing — start with a simplified version of the commons that operates on an embedded skill instead of a living Commons Farm. That simplified version isn't a design failure: it's a documented transitional stage of the adoption process. It resolves the first obstacle of any implementation — the investment decision — by letting the client see the commons working with their own data before committing to the full architecture.

Dimension	Transitional phase · Embedded skill	Full architecture · Open
Data source	Snapshot embedded as text in the system prompt	Living Commons Farm, synced via Airbyte
Data refresh	Manual — the custodian regenerates the skill	Continuous — C2 agents detect changes and sync
Active layer	Not available — the stack doesn't support it	Operational — agentization protocol active
Feedback loop	Operational (thumbs up/down)	Operational + cross-referenced with Commons Farm data
Implementation time	4–6 weeks	3–6 months
Cost	Low — Claude Pro or API, no infrastructure	Medium-high — infrastructure + integrations

When it's the right decision

· The client hasn't decided whether to proceed with the full investment and needs evidence with their own data.

· The current cycle's budget doesn't cover the full architecture but does cover a functional demonstration.

· The organization is validating the OC against alternatives and needs to compare real implementations.

· The internal team doesn't yet have the technical maturity to operate Open and needs a learning stage.

When to advance to the full architecture

The three thresholds indicating that the migration has operational grounds:

· Adoption ≥50% of the target team uses the commons at least 1×/week for 4 consecutive weeks.

· Agentization candidate patterns at least 3 patterns meet the eligibility criteria (see Section 08).

· Required refresh frequency the data needs updating at a cadence of ≤7 days to retain its value.

Design error to avoid

Some transitional-phase implementations skip forming the Commons Team until the full architecture arrives. That's a mistake. Even if the architecture is simplified, the commons needs a Curator, Sensor, and Custodian operating from day one. Without those three roles, the commons doesn't stay alive and the evidence that justifies the migration doesn't accumulate. A transitional phase without a Commons Team is a demo, not a commons. See Section 07 — Commons Team for the detail of the roles and the governance rhythm.

02

Value creation

The designed Commons already answers. This stage makes sure it starts creating measurable value: faster decisions, better market response, better cashflow. The time that gets freed is a consequence of the value — not the starting point.

What it is

Value isn't declared — it's produced. And it's produced when the teams in the most significant value focuses have complete, real-time information to decide and act without waiting for anyone. Adaptant intervenes from day one: the value focuses the Commons can enable today are activated today.

For that value to emerge, three levers operate simultaneously: freeing the time trapped in visibility structures, building what sustains the new way of deciding, and refining the Commons in use — more useful, more precise, more reliable each cycle.

The three waves of freeing time toward value

Wave A: Reporting structures immediately replaceable by the commons in the first weeks. Weekly reports, status meetings.

Wave B: Structures that require the commons to reach a certain coverage level. Monthly close meetings, management reports.

Wave C: Structures that require agreement changes between teams. Follow-up committees, cross-functional alignment meetings.

The 5 deliverables

01

Value and freed-time map

Complete inventory of meetings and reporting structures with their real cost: total hours, participants, frequency, estimated cost in money. Classified by category A/B/C.

02

Replacement question bank

The questions the commons must be able to answer to make the elimination of each structure possible. Direct methodological link to Intervention 1.

03

Phased elimination plan

The documented three-wave sequence: what gets eliminated, when, with what replacement, who is responsible, and the criteria to evaluate whether the replacement works.

04

Value-creation dashboard

Week-by-week measurement of the percentage of time devoted to value creation vs. reporting. Visible to everyone in the commons. Target: 70–80% in value creation at 6 months.

05

Bank of value stories

Documentation of the first concrete cases: value enabled, time reinvested, decisions made without escalation, better client response. Basis for internal communication of results.

Reporting structures aren't eliminated out of philosophical conviction. They're eliminated because the commons makes possible what was impossible without them: that peripheral teams have complete, real-time information to decide and act.

03

Establishing the Commons Team

A living Commons needs someone to sustain it. The third stage establishes and launches the Commons Team — the team of one's own that maintains information access and evolves the AI that operates the Commons. The OC Architect is who forms it and transfers the operation to it.

Why this stage exists

A Commons that creates value but depends on Adaptant to be maintained isn't autonomy — it's dependency with a better interface. This stage builds, inside the organization, the team that sustains the Commons once Adaptant withdraws: the Curator, the Sensor, and the Custodian, with their own governance rhythm.

The OC Architect — the profile that carries the methodology in each implementation — is who forms that team and transfers the operation to it progressively. The product of the stage isn't a certificate: it's the team operating autonomously.

The key positioning

Certification isn't bought — it happens. It's a consequence of having completed a real project with active mentoring from Adaptant.

It isn't a finish line. It's an ongoing relationship with Adaptant and the network of OC Architects. Knowledge flows in both directions: OC Architects in the field feed the framework's evolution.

What the intervention produces

01

Commons Team established

The three roles — Curator, Sensor, Custodian — assigned to people from the domain, trained by operating the real Commons, with their own governance rhythm.

02

Operation transferred and documented

The responsibility of sustaining access and evolving the AI, transferred from the OC Architect to the Commons Team — with criterion decisions recorded and reviewed.

03

Capacity for autonomous evolution

The team incorporates new sources, manages the opening cycles, and improves answer quality with accumulated feedback — without Adaptant's intervention.

04

Access to the network and updates

Active membership in the network of certified OC Architects, with access to OC Framework updates and to documented cases from other implementations.

The component that closes the intervention

The transfer to the client's Commons Team

The OC Architect doesn't operate the commons indefinitely. They form the client's first Commons Team and transfer the operation progressively over six months. At the end of that period, the client sustains the commons autonomously. A well-implemented OC Architect leaves the client with an internal team functioning without them — that's the objective success condition of the intervention, regardless of the system's technical quality.

M1 The OC Architect operates all roles Month 1

The freshly deployed commons is maintained exclusively from Adaptant. The client's Commons Team observes and learns.

M2 The Commons Team takes on the sensor role Month 2

Conversations with the periphery pass to the internal sensor. The OC Architect continues leading curator and custodian.

M3 The Commons Team takes on the curator role Month 3

The decision about what enters and leaves the commons passes to the internal curator, with the OC Architect's review.

M4 The internal custodian takes on technical operation Month 4

Deployments, integrations, and maintenance pass to the custodian. The OC Architect accompanies from a distance.

M5–6 Remote accompaniment Months 5–6

The OC Architect no longer operates the commons. Available for specific consultations and quarterly strategic review. By the end of the sixth month, the transfer is complete.

The objective success indicator

If after six months the client still depends on the OC Architect to keep the commons operational, the implementation failed — regardless of the system's technical quality. The Commons Team's self-sufficiency is the objective indicator that the transfer happened. For the detail of the three internal roles and the governance rhythm, see Section 07 — Commons Team.

Section 04

The OC Architect

It combines four domains that don't usually coexist in a single profile — scarce and impossible to replace while the Commons is designed and established. It isn't a position that stays: it forms the Commons and transfers its operation to the client's team within six months.

Central positioning

"It isn't bought. It happens."

Certification is a consequence of implementation, not a product. The OC Architect isn't a title — it's the result of having completed a real project with active mentoring. The framework's IP is transmitted in practice, not in the classroom.

The 4 domains

The profile — four domains in a single person

Domain 01

Data architecture and technical understanding of the OC

Functional understanding of the four layers of the OC architecture. Not a data engineer — someone who can converse with data engineers, detect technical decisions with methodological consequences, and guarantee that the architecture serves the design.

Data architecture RAG / LLM Access by nature Semantic datamart

Domain 02

Mastery of the OC Framework

Deep knowledge of the OC's principles: the access-by-nature model, design from the periphery, the feedback loop as diagnosis, the implementation sequence, and Principle 7. This is who detects when a decision reproduces the model the OC is meant to transform.

OC Framework v5 Anti-hierarchical design Feedback loop Principle 7

Domain 03

Facilitation of participatory co-design

The ability to lead question-mapping sessions with peripheral teams, access-model design sessions with leadership, and reporting-structure diagnosis sessions in organizations with active resistances and agendas in tension.

Participatory co-design Resistance management Facilitation

Domain 04

Accompanying the middle management role change

Middle management is the most critical actor in any OC implementation — and the one that most frequently blocks the process silently. The OC Architect reads that resistance, names it without confrontation, and involves the threatened roles in co-design in a way that makes their knowledge valuable to the commons.

Power dynamics Change management Middle management

The training program

4 modules in sequence

The first two are Adaptant's public trainings. The last two are exclusive to the OC Framework and take place in the context of the first real project.

M1 Adaptive Organizations 2 days · in person

Intensive training based on the concepts of Beta organizations and Niels Pflaeging's BetaCodex. The 12 Laws of the BetaCodex, cell structures and autonomous teams, relative targets, and decentralization in practice. The conceptual base without which the commons's design decisions lack a frame of reference.

M2 Changing the System 2 days · in person

Training in organizational-transformation models and strategies. It complements the previous module with the method: how a real organizational system is intervened with concrete tools. How to read an organization through the ALPHA/BETA frame and design systemic transformation moves.

M3 OC Framework 3 days · with an OC Architect mentor

Specific training in the Organizational Commons Framework. Exclusive to Adaptant — not available outside the certification program. The candidate works on documented cases from previous implementations, makes design decisions on real scenarios, and develops the judgment to detect the most frequent error: reproducing hierarchy in the commons in a new form.

M4 Supervised practice Months 2–5 · in the field

The candidate co-facilitates their first complete implementation project under the direct supervision of an Adaptant OC Architect mentor. The certification evaluation isn't a theoretical exam — it's an evaluation based on observed practice and on the quality of the design decisions documented during the first project.

The certified OC Architect isn't the result of the third intervention — it's the condition that makes all the others possible. Without that carrier of the IP in each implementation, the commons is an IT project with transformation ambitions. With it, it's the beginning of an organization that learns to decide with real autonomy.

The structural counterpart — the Commons Team

The OC Architect is the external role that facilitates the initial implementation. The structural counterpart is the client's internal team that sustains the commons once the OC Architect withdraws: curator, sensor, custodian. The transfer is progressive over six months — at the end, the OC Architect no longer operates the commons. For the detail of the three internal roles, their governance rhythm, and the anti-patterns to avoid, see Section 07 — Commons Team.

Section 06

Reference technical architecture

The complete stack to implement the OC on the Open line — no vendor lock-in, interoperable with Anthropic, OpenAI, Google Gemini, Microsoft Azure, and local models.

Context note

This stack applies exclusively to the OC Open line (Open Standard and Open Enterprise). The OC Native line uses the Anthropic ecosystem directly — Claude.ai for Native Start, the Anthropic API for Standard and Enterprise — and doesn't require this abstraction architecture.

6 design principles — non-negotiable

Anti lock-in as architecture

Any implementation decision that violates these principles breaks the promise of the OC Open line and turns it into a vendor-dependent solution.

P1 · Open standards between layers

Each layer communicates with the next via HTTP/REST, SQL, JSON, WebSockets. No layer knows the internal implementation details of the next layer.

P2 · LLM swappable by configuration

OC Open never calls the Anthropic, OpenAI, or Google API directly — it always goes through LiteLLM. Changing models means changing one environment variable.

P3 · Client data on client infrastructure

The Commons Farm lives on the client's infrastructure. If local models are required, Ollama is deployed without modifying any other layer. Data doesn't leave without explicit consent.

P4 · 100% open-source stack (except LLMs)

The entire orchestration, storage, embeddings, and agents stack is open source. The only exception is third-party LLMs — which are swappable by design.

P5 · Thin interfaces without business logic

C5 is a thin layer with no business logic. Switching from Slack to Teams requires modifying nothing in C4 or C3. Adding a new interface is just adding a new thin client.

P6 · Self-hostable without depending on Adaptant

The stack is self-hostable on any cloud (AWS, GCP, Azure) or the client's own servers. There's no dependency on Adaptant infrastructure to operate in production.

Overview of the complete stack

Layers C1 → C5

Layer	Component	Function	License	Interoperability
C1 · Source systems	Any ERP / CRM / HR	Source of truth — not modified	Client property	Airbyte + webhooks
C2 · ETL extraction	Airbyte + n8n / Airflow	ETL → event-driven sync. 300+ connectors: SAP, Salesforce, HubSpot, Oracle, MySQL, REST APIs.	Apache 2.0 / MIT	DB, REST API, SFTP, SQL
C3 · OC Datamart	PostgreSQL 16 + pgvector	Vector + relational storage + access-by-nature model. Adaptant's IP lives in the schema design and taxonomies.	PostgreSQL Lic. / MIT	SQL or REST
C4a · Conversational	LiteLLM + LangChain	LLM abstraction — one endpoint, any model. RAG pipeline: embedding → pgvector → context → LLM → answer.	MIT	Anthropic, OpenAI, Gemini, Azure, Llama
C4b · Agentic	LangGraph + Temporal	Stateful agents, memory across sessions, proactive briefings, multi-step orchestration. 24/7 statistical anomaly-detection jobs (z-score). Natural-language alerts generated by LLM.	MIT / Apache 2.0	On LiteLLM — model-agnostic
C4c · Human judgment	No stack — by design	Requires no technical component. It's the space reserved for human judgment by design and by principle. Significant decisions, validation, and the assumption of responsibility live here. Any attempt to agentize C4c breaks the OC's fundamental principle.	—	—
C5 · Interfaces	Slack Bolt · Bot Framework · FastAPI+React · Twilio	Thin clients — presentation only, no business logic. Swappable without modifying C4 or C3.	MIT / BSD	Slack, Teams, WhatsApp, Web, mobile
Observability	Langfuse (self-hosted)	Conversation traceability, latency, cost per query, feedback loop, map of the Commons Farm's blind spots.	MIT	Agnostic — via LiteLLM

C3 — The core of the OC

The OC Datamart — PostgreSQL + pgvector

C3 is the heart of the OC. Adaptant's IP lives in the schema design, the taxonomies, the access-by-nature model, and the embeddings logic. PostgreSQL + pgvector combines classic SQL with semantic vector search in the same database.

The vector search function filters by privacy_level before searching — never after. That makes the access-by-nature model a primitive of the architecture, not an application layer.

The main oc_records schema includes privacy_level and team_id fields and a 1536-dimension vector with an ivfflat index for cosine search.

Access categories in the schema: universal · team · individual · sensitive — mapped directly to the 4 types of the access-by-nature model.

LLM interoperability

Model decision matrix

Model choice isn't technical — it's a matter of data policy, budget, and use cases. LiteLLM guarantees that any change requires no modification of the OC's code.

Criterion	Anthropic Claude	OpenAI GPT-4o	Google Gemini	Meta Llama (local)	MS Azure OAI
Reasoning quality	★★★★★	★★★★★	★★★★	★★★	★★★★★
Data privacy	Anthropic API	OpenAI API	Google API	100% local — no data leaves	Azure — client tenant
Cost / M tokens	$3–15	$5–15	$1–7	$0 (own infra)	$5–15 + Azure
Context window	200K tokens	128K tokens	1M tokens	8K–128K	128K tokens
Self-hosted	No	No	No	Yes — Ollama + GPU	No (Azure managed)
OC use case	Production default	Production alternative	High volume	Strict data policy	Microsoft enterprise

Prototype guide

The first 4 weeks

The full stack runs on Docker Compose for local development. The prototype produces a functional end-to-end demo by the end of week 4.

Week 1

Infrastructure and data

Docker Compose with PostgreSQL + pgvector + Airbyte running locally. One connector configured. First real client data in the Commons Farm.

→ Commons Farm with real data operational

Week 2

Conversational engine

LiteLLM running as a local server. Complete oc_query() function: embedding → pgvector search → context → LLM → natural-language answer.

→ First query answered by the system

Week 3

Slack interface + feedback

Slack Bot connected to the engine. Langfuse running and recording conversations. Feedback mechanism working — every answer evaluable by the user.

→ Pilot team using the system in Slack

Week 4

Proactive agent + demo

Proactive briefing agent with LangGraph running every morning. Anomaly detection with Temporal. End-to-end demo for stakeholders.

→ Complete demo for the Go / No-Go decision

Security and privacy

Implementation considerations

All communication between layers via HTTPS/TLS. LLM API keys in environment variables or a secrets manager — never in code. The Commons Farm in PostgreSQL with at-rest encryption and encrypted backups.

Conversation logs in Langfuse with at-rest encryption. Full audit: every conversation is traceable to the Commons Farm fragments that informed it.

Every query to the Commons Farm includes user_id and team_id. The vector search filters by privacy_level before executing — it's a control in C3, not in the application.

For clients with strict data policies (finance, health, government): Ollama + nomic-embed-text, 100% on-premise with no data leaving.

"OC Open doesn't require the client to buy any new software. It requires them to connect what they already have, organize it with an access-by-nature model, and make it accessible in natural language to the people who need to act on that information." — Adaptant, 2026

Double-click on the C4 layer

This section describes what OC Open is built with — the technical components per layer. For the detail of agentic behavior (what each layer does in active mode, how an agent is specified, the operational lifecycle), see Section 08 — The System that Learns.

Section 05

Product Portfolio

Two independent product lines. The same methodology and the same conceptual frame. What differentiates them is the technology ecosystem and the degree of vendor independence.

Native line

OC Native

For organizations that prioritize implementation speed, operational simplicity, and the backing of a consolidated vendor. Anthropic manages the intelligence infrastructure. Ideal when the data policy allows queries to travel to the Anthropic API.

Native Start Native Standard Native Enterprise

Open line

OC Open

For organizations that require vendor independence at the intelligence layer, 100% on-premise data, or integration with multiple models (Claude, GPT-4o, Gemini, local Llama). The LLM is swappable by configuration — without modifying code.

Open Standard Open Enterprise

The 5 tiers

Profile, scope, and investment

Native

Native Start

Up to 15 people

Small companies and shops with data in spreadsheets that want a conversational assistant for the whole team, without their own infrastructure and with minimal entry cost.

Includes

Structured Excel · Configured skill · Activation session · 30-day onboarding support

Requires

Claude Pro $20/mo per user. No additional infrastructure.

$2,000

USD · Adaptant project

1–2 weeks to deploy

Native

Native Standard

15 to 150 people

Medium companies with differentiated operational teams that want to unify access to their information in a proprietary conversational interface, with their own URL and user management.

Includes

PostgreSQL datamart · Skills per area · Node.js backend / Anthropic API · Own URL · User panel · 90 days of accompaniment

Monthly client stack

$55–270/mo (API + hosting + auth)

$30,000

USD · Adaptant project

4–8 weeks to deploy

Native

Native Enterprise

150+ people

Large organizations that require operation within their own infrastructure, under full control of the internal technical team, with integration to corporate directories and existing systems.

Includes

Full Anthropic architecture · ERP/CRM/AD integrations · Commons per area · Admin panel · Technical team training · SLA

Monthly client stack

$560–2,620/mo (Enterprise API + infra)

From $60,000

USD · Adaptant project

8–16 weeks to deploy

Open

Open Standard

15 to 150 people

Medium companies that require vendor independence at the intelligence layer, the ability to switch models without rewriting code, or whose data policy demands self-hosted traceability.

Technical stack

PostgreSQL + pgvector · LiteLLM · LangChain RAG · Keycloak OSS · Langfuse self-hosted · Docker Compose

Monthly client stack

$70–305/mo (LLM API + hosting)

$40,000

USD · Adaptant project

6–10 weeks to deploy

Open

Open Enterprise

150+ people — full C1→C5 stack

Large organizations that require full vendor independence, on-premise data, layered architecture, proactive agents, continuous monitoring, and integration with any corporate channel.

Full stack

C2: Airbyte 300+ connectors + n8n/Airflow · C3: PostgreSQL + pgvector · C4a: LiteLLM + LangChain · C4b: LangGraph + Temporal (stateful agents, proactive briefings, anomaly detection) · C4c: no stack — human judgment by design · C5: Slack + Teams + WhatsApp + Web · Full Langfuse

Additional options

Ollama + local LLM for 100% on-premise data · Kubernetes for high availability · Corporate SSO (OAuth2/SAML/AD) · Monthly client stack: $580–2,500/mo (or $0+ on-premise)

From $90,000

USD · Adaptant project

12–20 weeks to deploy

Full comparison

The 5 versions side by side

	Native Start	Native Standard	Native Enterprise	Open Standard	Open Enterprise
Size	Up to 15	15–150	150+	15–150	150+
Platform	Claude.ai	Own URL	Client infra	Own URL	Client infra
AI layer	Claude.ai	Anthropic API	Anthropic API	LiteLLM (any)	LiteLLM (any)
Semantic search	—	Basic SQL	Basic SQL	pgvector RAG	pgvector RAG
ETL / connectors	Manual (Excel)	Manual / basic	Custom connectors	Basic Airbyte	Airbyte 300+
Proactive agents	—	—	Optional	—	LangGraph + Temporal
Interfaces	Claude.ai	Web React	Web + custom	Web React	Slack · Teams · Web · WhatsApp
Observability	—	Basic logs	Basic Langfuse	Self-hosted Langfuse	Full Langfuse
AI vendor lock-in	Claude.ai	Anthropic API	Anthropic API	No lock-in	No lock-in
On-premise data	No	No	Optional	No	Yes (Ollama)
Deploy time	1–2 wks	4–8 wks	8–16 wks	6–10 wks	12–20 wks
Adaptant price	$2,000	$30,000	From $60,000	$40,000	From $90,000

Decision criterion

Native vs Open

The choice between lines isn't technical — it's strategic. It depends on the client's data policy, their tolerance for vendor lock-in, and their technical capacity.

Client situation	OC Native	OC Open
Strict data policy (data cannot leave)	Not recommended	✓ Recommended — Ollama on-premise
Implementation speed is the priority	✓ Faster	More time — more complex stack
AI vendor independence required	Anthropic-dependent	✓ Agnostic — LiteLLM
Tight infrastructure budget	✓ Minimal own infra	Requires more infrastructure
Native Slack / Teams / WhatsApp integration	Only in Enterprise custom	✓ C5 standard in Open Enterprise
Semantic search (RAG) required	Not available in any tier	✓ pgvector in every Open version
Proactive agents and automatic briefings	Only Enterprise with custom	✓ LangGraph standard in Open Enterprise
Client in a regulated sector (finance, health, government)	Requires case-by-case analysis	✓ On-premise with Ollama
Client already uses Microsoft 365 / Teams	Possible with custom development	✓ Bot Framework standard in Open Enterprise

Section 07

The Commons Team of the commons

Three roles, one rhythm, no hierarchy. The internal structure that sustains the commons once the OC Architect withdraws.

The problem this component solves

Without a Commons Team, the commons degrades

The OC Architect facilitates the commons's initial design. The Commons Team sustains it over time. Not because the design is defective — no organizational information system survives without distributed, rhythmic care that is the client's responsibility. The frequent error is assuming IT will absorb it. It doesn't. The commons isn't just another technical tool; it's an organizational infrastructure whose health depends on specific functions that rarely align with a classic IT team's profile.

The 3 roles

Curator · Sensor · Custodian

In small organizations the three roles can fall to the same person with partial dedication. In medium and large organizations, the reasonable arrangement is that each role has at least one dedicated person with a rotating backup. What isn't reasonable, at any scale, is any of them being vacant — each fulfills a function the other two can't replace.

Role 01

Curator of the commons

Mission: keep alive the quality of the information the commons processes. Review accumulated feedback, identify usage patterns, decide what information to add, modify, or remove from the datamart and the skill. Identify candidate patterns for agentization and lead the specification protocol.

Profile: business vision with basic technical comfort. Doesn't need to code, but understands how data is structured. Has recognized authority over the business domain.

~3 hrs/wk Decision over data Domain mastery

Role 02

Team sensor

Mission: capture what the commons doesn't yet answer well. Regularly converse with the periphery to detect the questions that don't reach the system, the outputs that generate friction, the answers the team avoids because it doesn't trust them.

Profile: good listening and an active internal network. Ideally, someone from the periphery with seniority — a senior AE, an experienced implementer, a technical reference — who keeps their operational role and dedicates part-time to the commons.

~2 hrs/wk Internal network Qualitative listening

Role 03

Technical custodian

Mission: keep the commons's infrastructure operational and evolving. Apply the updates prioritized by the curator, manage agent deployments, ensure system availability, and integrate new sources when the organization advances to the full architecture.

Profile: technical profile — internal to the organization or externally contracted from Adaptant or a certified OC Architect partner. Able to edit code, manage the repository, and operate infrastructure.

~4 hrs/wk Technical operation Agent deployment

The curator decides what enters and what leaves the commons. The sensor captures what the commons doesn't yet see. The custodian implements the changes. The three are independent — and operational interdependence is the guarantee that none accumulates unilateral power over the commons.

Governance rhythm

Predictable cadence, not rigidity

The commons isn't maintained in real time. It doesn't need to be. What it does need is a predictable rhythm — where each maintenance activity happens when it should and nobody accumulates the anxiety of "everything has to be up to date right now." The rhythm frees the Commons Team's cognitive capacity to do its work well.

Cadence	Activity	Who	Duration
Daily	Capture in the flow — the periphery updates its systems as it already does. The commons consumes from the natural flow, without asking for extra work.	All users	Not assigned
Weekly · Mon	Feedback review — the curator reads the thumbs-down, prioritizes what to correct, opens skill-update tickets.	Curator	1 hour
Weekly · Thu	Skill update — the custodian applies the prioritized updates and deploys the new version.	Custodian	2 hours
Biweekly	Sensor with the team — short conversations with 4–5 people from the periphery. What frustrated you this week? What information are you looking for and not finding?	Sensor	2 hours
Monthly	Patterns published — the curator identifies patterns of lessons learned that appear in ≥3 cases and integrates them into the commons as structured knowledge.	Curator	3 hours
Quarterly	Strategic review — the Commons Team and leadership review: which OC sensors rose? What dimensions are missing? What needs to be redesigned?	Team + leadership	2 hours
Biannual	Mastery review — the periphery self-declares and cross-validates its domains. The commons's mastery map is updated.	Full team	1 hour

The 4 anti-patterns

How a well-designed commons degrades

These are the four most frequent modes in which well-intentioned organizations degrade their commons until they render it irrelevant. Naming them explicitly is the most effective prevention tool — when they appear, the Commons Team recognizes them before they take hold.

AP1

The mandatory form

When the commons requires the team to fill out separate forms to feed it, the commons dies. Capture outside the flow equals capture that doesn't happen — or that happens in bad faith. The rule is absolute: if the team has to open something different from their usual tools to feed the commons, the design is wrong.

AP2

The validation committee

When the validation of what enters the commons goes up the hierarchy — "before publishing this pattern the executive committee reviews it" — speed drops to zero. The commons stops being timely and becomes a museum. Validation must be by mastery, not by rank.

AP3

The obsession with completeness

When the Commons Team waits to have "all the data" before publishing, the commons isn't born. Publishing at 70% and improving with feedback is always superior to publishing at 100% in six months. Waiting for no negative feedback is waiting for the commons to be irrelevant.

AP4

The single custodian

When a single person can maintain the commons, the commons isn't resilient. The organization becomes tied to that person — and that reproduces exactly the hierarchical dependency the commons was meant to transform. The three roles must each have at least one identified rotating backup.

The transfer from the OC Architect

A six-month sequence

The OC Architect leads the initial implementation and forms the first Commons Team. The transfer of responsibilities is progressive — it isn't an event but a sequence.

M1

Month 1 — The OC Architect operates all roles

The freshly deployed commons is maintained exclusively from Adaptant. The Commons Team observes and learns.

M2

Month 2 — The Commons Team takes on the sensor role

Conversations with the periphery pass to the internal sensor. The OC Architect continues leading curator and custodian.

M3

Month 3 — The Commons Team takes on the curator role

The decision about what enters and leaves the commons passes to the internal curator, with the OC Architect's review.

M4

Month 4 — The internal custodian takes on technical operation

Deployments, integrations, and maintenance pass to the custodian. The OC Architect accompanies from a distance.

M5–6

Months 5–6 — Remote accompaniment

The OC Architect stops operating the commons — but doesn't disappear from the relationship. They remain available for quarterly strategic review, and the organization joins the network of OC Architects that feeds the framework's evolution. By the end of the sixth month, the transfer is complete.

A well-implemented OC Architect leaves the client with a Commons Team functioning without them. If after six months the client still depends on the OC Architect to keep the commons operational, the implementation failed — regardless of the system's technical quality. The Commons Team's self-sufficiency is the objective indicator that the transfer happened.

Foundations in the BetaCodex

The Commons Team as a practice of the frame

The design of the Commons Team isn't an operational choice — it's the materialization of the BetaCodex applied to sustaining the commons. Every structural decision described in this section is anchored in one or more principles of the frame.

Principle	Application in the Commons Team
§5 Transparency	Open capture and distributed validation — whoever has mastery over the data publishes, without prior hierarchical filter.
§9 Rhythm	Each part of the commons sets its natural rhythm — daily in capture, weekly in review, monthly in patterns, quarterly in strategy.
§10 Mastery	The curator isn't whoever has the highest rank — it's whoever has recognized authority over the domain. The sensor isn't appointed, it's someone with a real internal network.
§12 Flow coordination	Sensor, curator, and custodian don't report to one another — they coordinate through the natural flow of work. Interdependence is operational, not hierarchical.

The Commons Team isn't a tool separate from the culture the commons builds. It's the operational materialization of that culture. Every time the curator publishes a pattern without waiting for authorization, they're practicing autonomy. Every time the sensor brings the curator a qualitative observation from the periphery, they're practicing transparency. Every time the custodian implements the change without adding approval layers, they're practicing flow coordination.

Section 09

The periphery capture of the Commons

How what no system records enters the Commons: the human read of those who are where things happen. The third source of the system that learns — with mechanics, not as a declaration.

The central idea

The Commons integrates three sources: internal transactional, market and macro context, and human periphery. The first two have mechanics — C2 extracts from systems, external sources are incorporated by design. Periphery capture is the piece that resolves the third: the people who operate in the value flows know things no system records — the nuance of a client meeting, the market rumor, the risk intuited before it appears in an indicator. The direction of flow inverts: in normal use, the person asks the Commons; here, the person tells the Commons — or the Commons asks the person.

The three surfaces

Three entry forms of the same channel

They don't compete with each other: they cover three distinct types of signal.

Surface	What it captures	Mechanics
1 · Spontaneous capture "I want to tell you something"	What no one knew they had to ask about — the unknown unknowns. The salesperson's perception leaving the meeting, the data the technician overheard in the client's hallway.	A permanent button in Commons Chat. The person writes freely. The engine extracts entities, proposes links to what already exists in the Commons Farm, and stores the signal linked.
2 · Playful capture The Commons trivia	Distributed perceptions on topics the question bank defines: client climate, market signals, intuited risks.	The Commons asks, the person answers in seconds. The question bank is curated by the Sensor — whose role changes in nature: it stops sensing itself and becomes the curator of the sensing network the entire organization constitutes.
3 · Directed pulse Hot topics	Signal density on what the organization needs to clarify now. The answer is cross-referenced with transactional data: "the system says green; the periphery perceives risk."	With disciplined frequency, the Commons sends a directed question about a current topic. The Sensor proposes the topics, the Curator curates them. Leadership can request — through the Commons Team, never directly.

The single pipeline

Signal, human decision, consolidation

The three surfaces feed the same pipeline: capture → entity extraction and linking → periphery signal state → Curator's curation → consolidation or discard → loop closure back to the contributor. It's the same structure as the agentization protocol and the knowledge-canonization one: the OC always learns the same way.

Signal is not knowledge

If the raw account enters the Farm as fact, the Commons is poisoned with rumors — and the first time it answers something false based on an unverified comment, confidence in the whole system is injured. The "periphery signal" state exists for that: the Commons can say "there's a registered perception that…" without asserting it as data. The distinction between what systems record and what people perceive remains always visible. Loop closure — "your signal about X was incorporated" — isn't courtesy: it's the fuel of the channel.

The three design guards

Conditions, not recommendations

Without these three rules, any of the mechanisms can mutate into the opposite of what the OC preaches.

01	Never ask the periphery what the systems already know. A trivia that asks "how is project X?" when the status lives in the systems is the report reconstructed through the back door, with playful makeup. Periphery capture asks only the invisible. The question bank is audited against this rule — the Sensor's responsibility.
02	Periphery never feeds individual evaluation. The day a periphery signal shows up in a performance conversation, the channel dies forever — and rightly so. Signals feed the Commons according to the access-by-nature model, not a managerial dashboard.
03	The signal record inherits the access model. Who said what, about which topic, is itself information with a nature — and a delicate one. Without this guard, the capture channel becomes the surveillance instrument that Principle 7 prohibits.

The decision record

The connection with human judgment (C4c)

The human judgment layer is, by design, a space without agents. What the framework wasn't capturing is the learnable trace of that judgment — what was decided, with what context, and what resulted.

The record is a conversational act

The person closes a Commons Chat consultation with "record this decision: we're going with X because of Y." The decision remains in the record, marked as a decision, with the Commons context that fed it already linked.

The follow-up is a directed pulse

When a decision is recorded, a C4b agent schedules the outcome pulse: at 30/90 days, the Commons asks those who were close — "60 days ago, X was decided; how did it turn out?" The cycle closes: decision, context, outcome.

The complete map

The four learning loops of the Commons

The AI model doesn't learn anything about the organization — it's frozen, and that's a guarantee, not a limitation. All the learning resides in the context the organization builds and curates around the model. The substrate of learning is the Commons. The intelligence is the organization's.

Loop	What it learns	Signal	Who decides	Where it consolidates
Agentization	What gets asked	Recurring query patterns	Commons Team	Deployed C4b agents
Canonization	What is known	Validated answers, corrections, re-asks	Curator	Curated bank — versioned in git
Periphery capture	What is perceived	The three capture surfaces	Curator (question bank: Sensor)	Consolidated signals in the Farm
Decision record	What worked	Recorded decisions + outcome pulses	The person who decides (C4c)	The organization's memory of judgment

Periphery capture completes the promise of the three sources: the Commons stops knowing only what the systems record and starts knowing what the organization perceives. The distinction between both remains always visible — and the decision to turn perception into knowledge always stays in human hands.

The name — glossary candidates

Commons Sense (the double meaning in English as an asset: common sense / the Commons' sensing) and Commons Signals (literal and transparent — "periphery signal" is already the pipeline's term). Both in the candidate bank until the decision.

Section 08

The system that learns

The active layer turns the commons from reactive to active — into a system that learns from how it's used, from what people correct, and from what the organization delivers. Four loops sustain that learning: agentization (this section), knowledge canonization, periphery capture, and the decision record — see Section 09.

This section describes what each layer of the OC does in agentic mode and how the agentization protocol is operated. For the technical stack that implements this architecture — components, licenses, interoperability — see Section 06 — Technical Architecture.

The confusion problem this section resolves

A conversational datamart already exists. They call it Copilot.

Microsoft has Copilot. Power BI has Copilot integrated. SAP has Joule. Any BI vendor will have their version in 18 months. If the OC is described as "you query your organizational information in natural language," it's commodity by 2027. The difference between the OC and a conversational BI isn't the interface. It's the combination of three things BI vendors don't have together: the access-by-nature model, the integrated adoption methodology, and — what this section develops — the active layer that turns the commons into a system that learns.

Reactive vs. active — the difference isn't of degree

A datamart with a conversational interface is reactive: it answers when asked. The agentized OC is active: it detects, syncs, alerts, and prepares without anyone requesting it. That difference isn't of degree — it's of purpose.

The 5 layers of the agentized OC

Layered architecture with reactive and active modes

The OC's 5-layer architecture remains. What's added is an active-mode dimension in each layer: what each layer does when asked (reactive) and what it does without being asked (active mode, agents). The C4 layer subdivides into three: conversational, agentic, and human judgment.

Layer	Base role	Reactive mode	Agents — active mode
C1 Source systems	CRM, ERP, HR, billing. Source of truth — not modified.	Data available via scheduled extraction.	C2 agents detect changes and trigger immediate synchronization.
C2 Extraction	Connect source systems to the Commons Farm.	Batch ETL: extract, transform, load in scheduled cycles.	Event-driven sync — prioritizes by relevance and impact.
C3 OC Datamart	Core of the commons. PostgreSQL + pgvector with the access-by-nature model.	Answers questions with historical context.	Monitors patterns, detects anomalies, identifies dependencies, generates proactive alerts.
C4a Conversational	AI that answers in natural language.	Retrieves, synthesizes, and contextualizes information on demand.	None — C4a is purely reactive by design.
C4b Agentic	Orchestration of context and proactivity.	Coordinates multiple sources, adds unrequested context when relevant.	Prepares anticipated briefings, detects query patterns, suggests next questions.
C4c Human judgment	Exclusively human space.	Validate, decide, assume responsibility.	No agents — by design and by philosophical principle.
C5 Periphery	Interface between the commons and people.	Query channel — the person asks, the commons answers.	Proactive channel — agents send relevant briefings and alerts unrequested.

If OC agents start executing actions in the transactional systems, the OC stops being an autonomy infrastructure and becomes a more sophisticated control infrastructure. That's the design error the C4a/C4b/C4c distinction exists to prevent.

Critical distinction

OC agentic vs. McKinsey ERP-agentic

The big consultancies describe a vision where autonomous agents execute end-to-end processes in the transactional systems. That vision is coherent — and radically different from the OC's. The difference isn't semantic: it defines where decision authority resides.

McKinsey agents · ERP agentic	OC agents · Agentized commons
Mediate between systems and business processes	Mediate between data and people — not between people and decisions
Execute transactions and orchestrate end-to-end processes	Synchronize data, detect patterns, and prepare context
Humans define intent, validate results, intervene in exceptions	Humans make all significant decisions
Decision authority migrates to agents for standard processes	Decision authority remains in the human periphery — no exceptions
Objective: operational efficiency — do more with less human intervention	Objective: organizational autonomy — do better with more information for people
Agents operate on the transactional systems — they modify records	Agents operate on the commons — never on the source systems

Operational agentization protocol

How a pattern becomes an agent

The architecture describes where the agents operate. The protocol describes the process by which a conversational pattern becomes a deployed agent. Without a protocol, the decision of what to agentize is left to the individual criterion of the Commons Team — and that reproduces the bias of the first model the OC came to correct.

Eligibility criterion — when a pattern is a candidate

Not every repeated pattern warrants an agent. Agentization has maintenance, coordination, and calibration costs. Eligibility operates with a clear quantitative threshold.

Criterion	Threshold	Reason
Minimum frequency	≥3 times per week	Below that, the maintenance cost exceeds the agent's benefit
Minimum persistence	4 consecutive weeks	Filters out situational patterns — project schedules, seasonal peaks, one-off events
Form stability	Equivalent inputs and outputs in ≥80% of queries	If the question varies in structure, it isn't a pattern — it's a topic
Mastery agreement	Validation from at least one peripheral domain reference	The quantitative criterion doesn't replace the judgment of whoever uses that information to act

The 5 agent questions — specification protocol

When a pattern is eligible, the Commons Team answers five questions before implementation. If all five have a clear answer, the pattern is ready. If any remain ambiguous, it goes back to the conversational commons for another cycle.

P1

What inputs does it need?

The Commons Farm sources the agent queries and the parameters it receives. Risk if ambiguous: the agent produces incorrect answers due to undocumented dependencies.

P2

What process does it follow?

The sequence of steps between inputs and output — filters, aggregations, business rules. Risk: the agent becomes a black box no one can correct.

P3

What output does it produce?

Exact format of the deliverable — structure, length, level of detail, language. Risk: the output requires manual reformatting every time, losing the benefit of automation.

P4

How often does it run?

The agent's trigger: temporal (fixed cadence), event (change in the source system), or demand (explicit request). Risk: the agent runs when it shouldn't or doesn't run when expected.

P5

When does it need human intervention?

Conditions under which the agent stops and escalates to a person — exception thresholds. Risk: the exception is processed as a normal case and the error propagates unnoticed.

The agent specification isn't a technical document. It's the operational conversation the organization needs to have to define which parts of its work can be executed without human presence — and which cannot. That conversation, done question by question, is the protocol's true deliverable.

Agent taxonomy

Trigger · Output · Channel

An agent is characterized by three operational dimensions. This taxonomy lets the Commons Team talk about agents precisely — without confusing a temporal agent with an event-oriented one, or an agent that posts to Slack with one that writes to a source system.

TRIGGER · what activates the agent

Temporal: runs on a fixed cadence (every Monday at 8:00, every month-end close).

Event: runs when a source system reports a relevant change (a deal enters the CRM, a ticket changes state).

Demand: runs when a person invokes it explicitly from C5.

OUTPUT · what it produces

Summary: synthesis of information already existing in the commons.

Alert: signal about an anomaly or a pattern that deserves attention.

Recommendation: action suggestion with data-based justification.

Structured document: formal deliverable (proposal, analysis, report).

CHANNEL · where the output appears

Slack / Teams: message to the relevant team channel.

Email: one-to-one or defined-group communication.

Comment in source system: the output appears in the context of the record it refers to.

Commons dashboard: the output remains available in C5 for later consultation.

The agent's identity card

The combination of trigger + output + channel is the agent's identity card. Two agents with the same combination are functionally equivalent — their difference is only in the inputs and process. That standardization facilitates the agent inventory and the conversation with leadership about what the system automates and what it explicitly leaves to human judgment.

Agent lifecycle

From proposal to retirement

An agent isn't deployed and left the same indefinitely. It has a lifecycle the Commons Team must sustain — and the last stage, retirement, is as important as deployment. An agent that no longer serves and keeps running is noise, not signal.

E1 Proposal Curator

A pattern meets the eligibility criteria. The curator answers the five questions and produces the agent's card with trigger + output + channel.

E2 Validation Curator + peripheral reference

The card is reviewed with a peripheral domain reference — the person who will use the agent's output to act.

E3 Deployment Technical custodian

The agent is implemented, tested with real data, calibrated against expected outputs, and enters operation.

E4 Monitored operation Sensor · 4 weeks

During the first 4 weeks, the agent's output is accompanied by explicit feedback from the recipients.

E5 Stable operation Technical custodian

The agent runs with passive feedback. Corrections accumulate and are applied in scheduled reviews.

E6 Periodic review Curator + sensor · every 6 months

The Commons Team evaluates whether the agent is still useful — whether its output is still being acted on, whether the pattern is still stable.

E7 Retirement Curator + custodian

When the pattern stops being stable or the output stops being used, the agent is retired. Its logic is documented — not deleted — in case the pattern reappears.

The protocol described in this section isn't an administrative process the Commons Team follows to comply. It's the operational discipline that distinguishes a well-designed agentized commons from a collection of scripts someone put together because they thought it was a good idea. The difference between the two is the difference between infrastructure and dependency.