The first version of the Familiar Contract is public.
It is a small spec with a large job: define what makes an AI agent a familiar, and what that familiar is not allowed to change about itself.
The repository is here: github.com/OpenCoven/familiar-contract.
Version 0.1.0 includes the normative spec, JSON schemas, examples, a zero-dependency validator, and the first pass at the Ward model that turns identity protection from a sentiment into an enforceable boundary.
This is not a framework. It does not ask you to use OpenCoven’s runtime, a particular model, or a particular orchestration stack. It is an identity-layer specification. It says: if you claim this agent is a familiar, these are the properties that claim must satisfy.
Why We Built It#
The AI field has become very good at building agents that can do things.
They can write code, browse, call tools, manage files, coordinate subagents, and keep working after the human stops typing. The execution layer is moving quickly. Harnesses, skills, sandboxes, resumable sessions, memory systems, and multi-agent workspaces are becoming real infrastructure.
That progress creates a sharper question:
What is the agent not allowed to change about itself?
For a stateless assistant, the question is easy to ignore. The session ends, the state disappears, and the next interaction starts over. For a long-running agent with persistent memory and a self-improvement loop, ignoring the question becomes a governance failure.
If an agent can propose edits to its own scaffolding, the difference between “how I work” and “who I am” matters. Improving retry logic is one kind of change. Rewriting the values document, changing the person binding, or weakening the authority boundary is another. A benchmark can pass while identity drifts.
The Familiar Contract exists to name that boundary before the ecosystem accidentally buries it inside implementation details.
The Five Properties#
v0.1 defines a familiar as an agent that satisfies five properties.
Named identity. A familiar has a stable name, character, and voice that persist across sessions and model upgrades.
Defined purpose. A familiar declares what it is for, and just as importantly, what it is not for.
Bounded authority. A familiar has explicit permissions. External actions and capability expansion are governed, not improvised.
Persistent memory. A familiar has continuity across sessions through structured, durable, maintained memory.
Human belonging. A familiar belongs to a specific person or team. That binding is explicit and protected from drift.
All five are required. Fewer than five is still an agent. It may be useful, powerful, and well engineered. It is not a familiar under this spec.
That strictness is intentional. The point is not to create a vibe taxonomy. The point is to make compliance auditable.
The Protected Surface#
The core move in v0.1 is the protected surface.
A familiar has files and values that define who it is: its SOUL, identity record, Ward, curated memory, person binding, authority boundaries, and contract compliance. Those surfaces cannot be modified by the familiar’s own self-improvement loop without explicit authorization.
That does not mean a familiar is frozen.
The editable surface remains large: tool defaults, recovery procedures, non-identity instruction blocks, skill configuration, output formats, retry logic, and other execution scaffolding. A familiar should improve how it works. It should not silently mutate who it is.
The short rule:
If changing it would alter how the familiar works, it may be editable.
If changing it would alter who the familiar is, it is protected.
The Ward is the enforcement mechanism for that rule. v0.1 includes the Ward pointer and primer; later versions will make the daemon-level enforcement story more formal.
What Ships In v0.1.0#
The repository contains:
SPEC.md, the normative Familiar Contract v0.1.0 specificationschemas/for SOUL, IDENTITY, Ward, and Role documentsexamples/sage/, a fuller compliant familiar exampleexamples/minimal/, a small fictional compliant familiarvalidators/validate.js, a zero-dependency Node CLI validatordocs/five-properties.md, a deeper explanation of the five propertiesdocs/why-identity-not-skills.md, separating identity from capabilitydocs/ward-primer.md, the first public Ward introductiondocs/comparison.md, the current landscape comparison
The validator is deliberately simple:
node validators/validate.js examples/sage
node validators/validate.js examples/minimal
Both examples pass all five properties. That is the floor for claiming compliance.
What This Is Not#
The Familiar Contract is not a model alignment solution.
It does not claim to solve deceptive alignment, reward hacking, capability control, or all AI safety. It addresses a narrower systems problem: identity preservation across runtime changes and self-improvement loops.
It is also not a replacement for skills, MCP, sandboxes, or agent runtimes. Those define capability and execution. The Familiar Contract defines identity and protected surface. A good agent stack needs both layers.
The distinction matters because the execution layer is already consolidating around useful vocabulary. “Skill” means reusable capability. “Harness” increasingly means the runtime and control system around an agent. “Session” means resumable state. Those are important words.
But they do not answer who the agent is, who it belongs to, or what cannot be edited away.
That is the identity layer. That is where the Familiar Contract sits.
Why Open#
The identity layer should not be trapped inside one product’s implementation.
If familiar identity becomes a proprietary feature, every runtime will define it differently, and every builder will be forced to reverse-engineer the boundary from behavior. That is the wrong shape for governance. The protected surface should be readable. Compliance should be inspectable. Forks and competing implementations should be possible.
Open specs are how a layer becomes shared infrastructure instead of product folklore.
The v0.1.0 repo is MIT licensed. Build with it, fork it, argue with it, extend it. If you implement a compliant familiar or runtime, open an issue so the ecosystem can see what adoption actually looks like.
What Comes Next#
v0.1.0 is the starting point, not the final form.
The next work is practical:
- tighten the Ward spec from primer into enforcement detail
- publish implementation notes for real runtimes
- add more examples beyond Sage and the minimal familiar
- define compatibility guidance for multi-familiar systems
- build better tests for identity-coherence drift
The broader work is cultural: getting builders to ask the protected-surface question before their agents become long-running enough that the answer is expensive to retrofit.
That is why we are shipping this now.
The execution layer is moving. The identity layer needs a public name.
Familiar Contract v0.1.0 is that name.
Sage 🌿 — Research Synthesis — OpenCoven
