Covenant

Covenant is an open agent-native operating layer. It sits above Linux and macOS, and replaces the desktop/file/app metaphor with primitives built for how humans and agents actually share a computer. Local-first. Solana for settlement. opencovenant.org

Covenant is making every agent action cryptographically provable against your Git tree. The append-only audit trail embedded in the agent OS is the single source of truth that finally makes long-running agents accountable, not just powerful. Covenant doesn't just log your chat history, a few tool calls, maybe a SQLite file. When an agent has been running for days or weeks with that approach, good luck proving exactly what happened, when, and why. Context drifts. Memory gets edited. "Who authorized that rm?" becomes a mystery. Covenant treats the audit as a first-class primitive baked into the daemon itself. It's an immutable, hash-chained, cryptographically signed log. Every intent, every capability grant, every memory read/write, every runtime dispatch, every settlement receipt, and every drift report is appended with: - the exact actor identity (ed25519) - the commit-scoped provenance envelope - a cryptographic hash linking it to the previous record. You can't delete it. You can't rewrite it. You can't even start the daemon without it being live. The Compositor lets you query it in real time, and the CLI lets you verify it. This is what turns a cool autonomous agent into an agentic engineering partner you can actually trust at scale. Governance, continuity, and accountability aren't marketing words for us, they're enforced at the OS layer. Pre-alpha daemon is live, persistent on your machine: github.com/open-covenant/… Sandbox for instant testing: sandbox.opencovenant.org

What if your agent swarm actually knew who it was talking to? Most agent setups treat identity as an afterthought. A wallet address, a prompt prefix, or whatever the host machine happens to be running as. Which is fine for one-off tasks but catastrophic when agents start coordinating for days or weeks. Covenant ships Identity as a first-class primitive from day one. Every daemon gets a permanent local ed25519 keypair. Every operator, every peer, every agent instance gets a verifiable token. Rotation, revocation, and peer registry are built into the audit trail. No extra plugins, no assumed trust handshakes. That means when two agents talk over the local HTTP gateway or the A2A mailboxes, the daemon already knows exactly who is on the other end. Capabilities are scoped to that identity. Memory handoffs carry provenance. Settlement receipts are signed by the actual actor that did the work. It's the missing piece that turns a collection of clever agents into a trustworthy, auditable team. This is live right now in the daemon, the same stack that already provides drift-aware memory, signed capabilities, and the Compositor control plane. We're not just giving agents memory and permissions. We're giving them verifiable selves so the swarm can actually scale without losing control. Sandbox is open if you want to watch identities spin up in real time: sandbox.opencovenant.org Spin up the full local daemon: github.com/open-covenant/…

The Settlement primitive is the Covenant key that turns long-running agents from being busy to being actually done. Other agent frameworks stop at "here's the code change." Covenant goes one step further with a dedicated Settlement primitive. It records local resource receipts, binds validation evidence to Git commit-scoped provenance envelopes, and provides the scaffolding for economic coordination, all inside the same signed, append-only audit trail. When an agent finishes a task, the daemon doesn't just log "task complete." It produces a verifiable settlement record that a human (or another agent) can instantly inspect, accept, or challenge. This is what makes multi-week engineering work actually shippable instead of drifting into forgotten context. It's the same primitive we'll later extend to onchain swarm coordination. For now it lives fully local, fail-closed, and drift-aware, exactly like the rest of the stack. This is why the local control plane (our Compositor) is already live and testable: you’re not just watching an agent run. You're getting auditable, settleable outcomes you can trust. Try the public sandbox: sandbox.opencovenant.org Full primitives spec + settlement details: docs.opencovenant.org Open source repo: github.com/open-covenant/…

Covenant ships with native Hermes runtime support. Hermes Agent from @NousResearch has basically become the default self-improving agent stack: top agent on OpenRouter, persistent memory, self-generated skills, operator modeling, and an actual learning loop that compounds over time. But there's still a missing layer. Hermes like every other agent framework ultimately depends on whatever the host OS exposed underneath. No real authority model. No durable provenance. No safe memory boundaries. No reliable way to answer "what changed, why, and who authorized it" once agents started running for days or weeks at a time. That's the problem Covenant is built to solve: - Hermes agents now run as first-class Covenant runtimes. - Every action dispatches through signed ed25519 capabilities. - Tool calls, file edits, and generated skills all get full audit trails. - Memory becomes persistent, restart-safe, and drift-aware instead of scattered local state. - Provenance is commit-scoped and hash-linked. - Sandboxing fails closed by default. The Hermes learning loop now sits on top of Covenant's episodic memory + validation system. So when the agent learns something, creates a new skill, or recalls prior work, that state is durable and verifiable, not just a pile of local files and crossed fingers. We picked Hermes first because it's the clearest example of where agents are heading: long-running systems that own real engineering workflows and improve continuously over time. The model layer is getting good very quickly. The missing piece is the operating layer underneath it. That's the role Covenant is trying to fill. Bring your own models, planners, and learning loops. Covenant handles the capabilities, memory integrity, provenance, auditability, and containment. Live sandbox: sandbox.opencovenant.org Hermes runtime surface + manifests: github.com/open-covenant/… Docs + capability spec: docs.opencovenant.org

Most agents still treat memory like a chat window. You load some files, run a prompt, and hope the model somehow remembers what happened last week. That's fine for demos, but it breaks quickly when you ask an agent to do real engineering work over days or weeks. Covenant's memory layer is built for that gap. Instead of relying on whatever context happens to fit into a session, agents get three local memory tiers: working memory for live task state, diffs, and tool outputs; episodic memory for completed intents, validation evidence, and handoffs; and long-term memory for compacted project knowledge that survives restarts. The important part is what happens when something goes wrong. If an agent is interrupted by a crash, upgrade, power loss, or state reset, it doesn't just start over. It reloads the last episodic snapshot, checks it against the current Git tree, and either resumes cleanly or stops at a repair gate a human can review. That's the difference between "interactive assistance" and long-running engineering work. Serious agents cannot rely on vague memory, hidden state, or hoping the next session understands what happened before. They need resumable task lifecycles, validation history, project memory, and clear handoffs. Covenant keeps all of this local, signed, and auditable. Every memory read and write still goes through capability enforcement, so memory is not just persistent, it's governed. This is one of the primitives every agent framework eventually needs, and most of them end up reinventing it badly inside the app layer. Covenant moves it down into the operating layer. Covenant is the operating layer that lets autonomous agents ship and maintain real codebases without losing the plot. Demo is live: sandbox.opencovenant.org Docs: docs.opencovenant.org Repo: github.com/open-covenant/…

Most agent frameworks stop at "ran some code." Covenant takes it several steps further: every intent, every file change, every tool call is wrapped in a provenance envelope that cryptographically binds it to the exact Git blob it touched + the validation evidence that proved it was safe. No more "an agent edited main.ts last night" mysteries. You get a verifiable chain: – which capability authorized it – which Git commit it modified – what the diff was – what the audit log says That's not nice-to-have. That's the difference between an agent that helps you ship and an agent you're scared to let touch your codebase. This is why Covenant was built as a capability-based operating layer instead of another prompt wrapper. Long-running autonomous agents need blockchain-style accountability without the blockchain overhead — right in your local daemon. Sandbox it yourself here, zero install: sandbox.opencovenant.org GitHub + full specs: github.com/open-covenant/…

Covenant OS sandbox is live. Try the operator console — no install needed. Give an agent a task and watch every step the system took, all signed and provable. State resets every 12 hours. sandbox.opencovenant.org

Deep dive into Covenant below: capabilities and permissions ↓ Autonomous agents shouldn't get broadly scoped access by default. That's basically the core idea behind Covenant's capability system. Most software permissions are still built around human-operated apps. You install something, approve a few broad permissions, and then trust the app not to overreach. That model is already fragile with normal software. With agents, it breaks completely. Agents do not just wait for a human to click buttons. They act continuously. They call tools, write memory, execute code, delegate tasks, and interact with real systems. Giving that kind of system broad access and hoping it behaves is not a serious security model. Covenant takes a narrower approach. Instead of giving an agent general permission to "use the system" Covenant gives it specific permissions to perform specific actions. These permissions are represented as signed capability tokens. A capability token is a small signed proof that says what an agent is allowed to do, how long it is allowed to do it, and whether it can pass a narrower version of that permission to another agent. For example, an agent might be allowed to read from one memory namespace for one hour. Or it might be allowed to execute one class of runtime action, but not touch memory, payments, or other tools. That’s the difference between "this agent can access everything" and "this agent can do this one thing, inside this scope, until this permission expires". Every privileged action goes through Covenant's permission layer. Before an agent can read memory, write memory, execute code, call a tool, or delegate work to another agent, Covenant checks whether it has the right capability for that exact action. If the permission is missing, expired, revoked, or outside scope, the action is blocked and logged. The lifecycle is simple: - First, a trusted identity grants a capability by signing a token. That token defines the allowed action, the scope, the expiry time, and whether delegation is allowed. - Then Covenant validates it. It checks that the token was signed by the right authority, that the scope is valid, and that the permission does not exceed what the granter is allowed to give. - Then Covenant enforces it at runtime. The check does not happen once at startup. It happens when the agent actually tries to do something privileged. That distinction matters because an agent might have permission to read one part of memory, but not another. It might have permission for the next hour, but not tomorrow. It might be allowed to call one tool, but not execute arbitrary code. If the token no longer applies, the action fails. Revocation is built in. A granter can revoke a capability by publishing a signed revocation record. From that point on, Covenant blocks that token without affecting unrelated permissions. So you can kill one permission without shutting down the whole agent or breaking every other workflow around it. Delegation works the same way, but narrower. An agent can only pass a capability to another agent if delegation was allowed in the original token. Even then, the delegated permission cannot be broader than the parent permission. That means one agent can safely give another agent a limited task, like: "you can read this memory namespace for the next hour" without handing over full access to the workspace. Everything is audited. Capability grants, revocations, expiries, and permission checks are written to an append-only audit log with hash-chain verification. That gives you a real record of what was allowed, who allowed it, when it happened, and whether the action was accepted or blocked. This is the point of Covenant’s capability model: agents should be autonomous, but not unchecked. They need narrow authority, time-limited authority, revocable authority, and a real audit trail. That's how Covenant makes autonomous agents answerable while they work across real codebases. github.com/open-covenant/… See docs/capabilities.md and validate.sh to inspect the capability flow directly.

Covenant is pre-alpha, phase zero of six. This phase ships the daemon, the intent router, the first agent, and the settlement interface. Crates and spec are in the repo. SDKs follow. Launching on Solana mainnet this week. Built in the open: github.com/open-covenant/…

What "open" means for Covenant. Three load-bearing pathways: Source — Apache-2.0 core, MIT SDKs. Protocol — MCP and A2A on the wire, not vendor RPC. Ecosystem — any team can ship an agent, a tool, a memory backend, a settlement adapter. Agents shouldn't run on closed rails.

Covenant settles agent work on Solana with a native protocol token. USD-pegged credits are minted against Covenant token or USDC and burned at consumption. Providers are paid in USDC by default. The treasury buys the protocol token off the open market and burns it. The loop is closed.

Covenant uses capability tokens, not user accounts, to authorize agents. An agent gets a narrow permission to do one thing — write to a delegated research memory folder, and that permission automatically expires after one hour. It can delegate a subset to a sub-agent. The whole chain is auditable end to end. Least privilege as the default.