Doctrine
Polymantic Systems
One substrate. Many valid views.
Open Interpreter's June 10, 2026 release gave the agent stack a useful phrase: harness emulation.
Their claim is simple. Coding models do not interact with the world in a vacuum. They learn to act through a harness: tool behavior, terminal affordances, system instructions, permission patterns, context compaction, output conventions, and the general shape of the environment they are driving.
So Open Interpreter does not force every model through one generic agent interface. It emulates the harness each model is best suited to use. GPT gets a Codex-style harness. Claude gets a Claude Code-like harness. Other models get provider-recommended harnesses.
Open Interpreter: one runtime for many coding agents
That is a smart product move for low-cost coding agents. It is also a stake in the ground for something larger.
Agent systems are becoming polymorphic at every layer.
- The model varies.
- The harness varies.
- The tool surface varies.
- The context strategy varies.
- The permission model varies.
- The memory view varies.
- The semantic interface varies.
Not anything-means-anything. Not semantic chaos. Not a pile of adapters, prompts, and tool descriptions pretending to be architecture.
A polymantic system separates the shared substrate from the views compiled out of it.
One substrate. Many valid views.
The monomantic default
Most enterprise software is monomantic. It assumes important concepts should eventually resolve to one canonical meaning.
One account status. One customer health score. One readiness stage. One risk level. One object model. One source of truth.
That instinct made sense when software mostly stored records and served dashboards. Analytics needs shared definitions. Master data management needs canonical records. Reporting systems need agreement about metrics.
But intelligent software does not only store and report. It interprets, retrieves, plans, extracts, escalates, decides, and acts.
Dashboards consume definitions. Agents consume worlds.
A dashboard can survive on a metric definition. An agent needs to know what that definition means for action: what it can touch, whose judgment applies, which exceptions matter, what evidence is valid, what confidence threshold is required, and when to ask a human.
Once a reasoner consumes the system, the semantic layer stops being passive documentation. It becomes runtime behavior.
The polymantic condition
Organizations are not monomantic. They are made of teams, tools, workflows, customers, regulators, executives, and agents that need different valid views of the same operational reality.
Consider enterprise readiness.
| Perspective | Valid view of the same referent |
|---|---|
| Sales | A revenue blocker. |
| Engineering | A capability bundle. |
| Legal | A liability posture. |
| Finance | An unpriced support obligation. |
| Support | A future escalation pattern. |
Those are not five sloppy labels for one hidden truth. They are perspective-scoped claims over a shared referent. Each view has different action affordances. Each can be valid. Each can also be wrong, stale, under-evidenced, or politically convenient.
A monomantic system collapses this into one field. A fragmented system lets each team reinvent the concept in its own tool. A polymantic system keeps the shared referent while allowing governed views over it.
What lives in the substrate
The substrate is where meaning gets a stable address. It preserves the things that need to remain interoperable even when the operational view changes.
- Referents: the things the system is talking about.
- Slots: durable semantic positions where meaning can be expressed, constrained, interpreted, and governed.
- Shapes: graphs of slots that encode a domain frame.
- Claims: perspective-scoped assertions about a referent.
- Evidence: the source material behind a claim.
- Policies: rules for visibility, authority, reconciliation, decay, and mutation.
- Versions: semantic history, not just document history.
The view is the operational surface compiled from that substrate: a UI, API schema, MCP tool, prompt packet, retrieval policy, eval rubric, workflow, dashboard, or permission set.
The basic polymantic architecture
The substrate preserves shared meaning. Views project that meaning into the interface required by the work.
Perspective-scoped claims
The core unit of plural truth is the perspective-scoped claim.
A claim is not just a value in a field. It carries the referent it is about, the slot it fills, the perspective it comes from, the evidence behind it, the confidence attached to it, the authority boundary around it, the timestamp, the visibility rules, and the reconciliation policy.
| Claim component | Why it matters |
|---|---|
| Referent | What this claim is about. |
| Slot | Which semantic position the claim fills. |
| Perspective | Whose view this claim represents. |
| Evidence | Why the system should believe or inspect it. |
| Authority | Who is allowed to assert or change it. |
| Policy | Whether to preserve, reconcile, decay, restrict, or escalate it. |
The system does not need to pretend every claim is the same statement. It also does not need to lose the fact that the claims may be about the same operational situation.
That is the difference between plurality and chaos.
Why harness emulation matters
Harness emulation is useful because it treats the interface as part of performance.
The same model behaves differently depending on how tools are named, how permissions are surfaced, how context is compacted, what format the harness expects, and what the agent thinks the environment affords.
That lesson generalizes beyond coding agents.
| Consumer | Needs a different projection of meaning |
|---|---|
| Human expert | Explanation, provenance, disagreement, and control. |
| Coding agent | Compact tools, constraints, and a harness it can drive well. |
| Workflow agent | Policy-bounded actions and the slots relevant to the workflow. |
| Evaluator | A rubric compiled from the same domain semantics. |
| API consumer | Stable schema with unnecessary operational affordances removed. |
The model does not just need the right information. It needs the right world, presented in the right shape.
Semantics and ergonomics are now the same problem. The way you present a domain to an intelligent system changes what that system can perceive, choose, and do.
Reconciliation is policy
Polymantic systems do not worship disagreement. Sometimes action requires collapse.
A contract either gets signed or it does not. A customer either receives a commitment or it does not. A deployment either meets the release gate or it does not. Some slots must resolve to canonical state because the organization has to act.
But reconciliation should be governed. It should not happen merely because the system is uncomfortable with multiple meanings.
- Preserve disagreement when plurality is informative.
- Canonicalize when action requires one state.
- Escalate when authority is unclear.
- Decay claims when freshness matters.
- Restrict claims when visibility is sensitive.
- Refuse modeling when legibility would create more harm than value.
Reconciliation is not the absence of plurality. It is the governed decision that a particular action requires collapse.
Agents as participants
Agents are not just consumers of a polymantic system. They become participants in it.
They can read perspective-specific views, fill slots, propose claims, detect drift, suggest referent merges, stage mutations, and request reconciliation.
They should not, by default, redefine canonical types, erase plural claims, override reconciliation policy, or change the constitutional semantics of the system.
Why this needs a runtime
The current agent stack is assembled from primitives: prompts, tools, retrieval, memory, evals, workflows, APIs, schemas, guardrails, and UI surfaces.
Each primitive quietly carries its own private semantics. The tool schema defines the domain one way. The prompt defines it another way. The eval rubric defines it another way. The UI labels define it another way. The CRM, ticketing system, warehouse, and vector index each add another local interpretation.
That is why drift begins immediately.
The answer is not more ontology everywhere. The answer is a runtime that can preserve shared meaning underneath while compiling the right operational projection above.
For humans, that may look like an interface for expert judgment. For agents, it may look like tools, schemas, context packets, permissions, and harness-specific affordances. For governance, it may look like provenance, policies, semantic diffs, and review workflows.
The Penumbra thesis
Penumbra is built around this thesis: intelligent software needs shared structure, not shared sameness.
The semantic layer cannot stay trapped in the warehouse. It has to become an operational runtime for agents, tools, humans, and workflows. It has to preserve the domain model underneath while projecting the right interface for the intelligence doing the work.
This is what makes polymantic systems different from ordinary integration layers, generic knowledge graphs, static ontologies, and generic agent frameworks.
The goal is not one perfect ontology.
The goal is a substrate where meaning has somewhere stable to occur, enough structure to remain interoperable, and enough plurality to stay true to the work.
The future is not one ontology. It is one substrate, many valid views.