Signet AI
Own your agent's context.
97.6% average LongMemEval answer accuracy Local-first context · source-backed recall · repairable memory · portable across agents
Quick start · Why Signet · Benchmarks · Docs · Discord
Models change. Providers change. Agent shells change. Your context should not.
Your agents are starting to remember projects, users, decisions, documents, conversations, preferences, mistakes, routines, and private working context.
That memory is no longer a feature. It is infrastructure — and custody matters.
Signet is a local-first context layer for AI agents: memory, identity, transcripts, source records, provenance, agent instructions, secrets, and repair tools in infrastructure you control.
Hosted memory APIs are fastest until memory becomes part of your product contract: deletion, provenance, repair, portability, and custody of private context. Signet is for that moment.
Not a hosted memory API. Not a harness-specific plugin. Signet is the durable layer underneath your agents.
Why Signet
Claim Why it matters
Local-first custody SQLite, readable workspace files, transcripts, source records, memories, and identity files live where you control them
Source-backed recall Every useful memory can point back to where it came from
Repairable memory Inspect, edit, supersede, delete, reclassify, and scope bad context
Portable across agents One layer works across Claude Code, Codex, OpenCode, OpenClaw, Gemini CLI, Hermes Agent, MCP, SDKs, and apps
Team deployment primitives Signet includes scoped agents, visibility, auth policy, retention controls, secrets storage, and audit-friendly APIs
Proven recall LongMemEval-tracked recall without giving up governance
You know you need Signet when agent memory is no longer just recall quality. You need to know where context lives, where it came from, who can see it, how it can be corrected, what gets deleted, and whether it can move when your tools change.
Quick start (about 5 minutes)
curl -fsSL https://signetai.sh/install.sh | bash
signet setup # interactive setup wizard
signet status # confirm daemon + pipeline health
signet dashboard # open memory + retrieval inspector
If you already use Claude Code, OpenCode, OpenClaw, Codex, Gemini CLI, Pi, Oh My Pi, or Hermes Agent, keep your existing harness. Signet installs under it.
Proof in one repair loop
Run this once:
signet remember "Project Atlas deploys only after QA signs off" \
--tags project-atlas --who user
signet recall "Project Atlas deploy policy" --tags project-atlas --json
Then open the dashboard:
signet dashboard
This is the smallest proof, but it shows the product shape: the memory is local, queryable, tagged, visible in the dashboard, and repairable instead of being trapped behind a hosted recall response.
If recall returns a stale deployment policy, you can edit or delete the memory, run the same recall again, and verify the agent is seeing corrected context before it acts.
In the dashboard, the record is not a black-box snippet:
Memory: Project Atlas deploys only after QA signs off
Tags: project-atlas
Dashboard actions: edit · delete · mark pinned · similar
Daemon lifecycle: modify · forget · recover
How Signet is different
Alternative Good for Where Signet is different
Hosted memory APIs Fast prototypes and managed memory Signet keeps storage, provenance, ranking policy, repair, deletion, and self-hosting under your control
Harness-specific plugins Improving memory inside one agent shell Signet runs underneath many harnesses, so context survives tool churn
Vector/RAG memory Searching notes and documents Signet keeps transcripts, identity, source records, repair history, and scoped recall
Lightweight local stores Simple private persistence Signet adds provenance, dashboard inspection, team policy, connectors, MCP, SDKs, and daemon APIs
Stay hosted if... Switch to Signet when...
You need the fastest managed API path Memory has to live in infrastructure you control
Recall quality is the only contract Deletion, repair, provenance, and auditability are also part of the contract
One app owns the memory surface Multiple agents, harnesses, SDKs, MCP clients, or internal apps need the same context
Vendor-managed ranking is acceptable You need to inspect and tune recall policy around your own sources
You cannot run a daemon or own backups yet You need an exportable workspace you can inspect, back up, and move
Operating tradeoff
Signet is infrastructure, not a hosted shortcut. You run a local or self-hosted
daemon, choose an embedding provider, back up $SIGNET_WORKSPACE/, and connect
your harnesses through hooks, MCP, connectors, or SDKs.
The trade is deliberate: you operate the memory layer, and in return you can inspect, repair, scope, self-host, back up, and move the context your agents depend on.
For a single-developer install, day two is usually signet status, a workspace
backup, and rerunning setup when you add or replace an agent harness.
Is Signet right for you?
Use Signet if you want:
-
agents that remember across sessions without prompt bootstrapping
-
memory your team can inspect, repair, scope, and self-host
-
source-backed recall across private docs, repos, conversations, and artifacts
-
one memory layer across agent harnesses, MCP clients, SDKs, and custom apps
Signet may be overkill if you only need short-lived chat memory inside a single hosted assistant or a simple vector search endpoint.
Harness support
Signet is not trying to win by being another agent shell. It runs underneath the tools people already use and gives them one owned memory layer.
Harness Integration path Notes
Claude Code
Hooks + MCP
Direct /remember and /recall skills
OpenCode Plugin + hooks Runtime plugin with lifecycle support
OpenClaw Runtime plugin Flagship path; hooks available for legacy setups
Codex MCP + compatibility hooks MCP-first integration; plugin bundle when available
Hermes Agent
Memory provider plugin
memory_*, recall, and remember tools
Pi Extension + hooks Memory commands and agent-callable tools
Oh My Pi Managed extension Lifecycle recall injection through the managed extension
Gemini CLI MCP + GEMINI.md sync On-demand tools plus identity sync
Don't see your favorite harness? file an issue and request that it be added!
Memory that holds up
Signet's latest tracked MemoryBench run averages 97.6% LongMemEval answer
accuracy under the rules profile.
The benchmark matters because local custody should not mean weak recall. Signet is designed to retrieve the right facts across long-running, multi-session conversations while keeping memory inspectable and repairable.
That profile keeps the benchmark contract strict: memories are ingested through
/api/memory/remember, recalled through /api/memory/recall, and answered
from bounded daemon recall results. Search does not call an LLM.
See Benchmarks for the methodology, scoring note, and run workflow.
Install (detailed)
curl -fsSL https://signetai.sh/install.sh | bash
npm install -g signetai
bun add -g signetai
signet setup # interactive setup wizard
curl, npm, and Bun all install the same compiled Signet binary. The npm and
Bun package-manager paths install the signetai wrapper plus a platform
native package tarball from the same GitHub release. Install scripts only link
the native binary into place; if scripts are disabled, the wrapper resolves the
native package directly. They do not install Bun, rebuild Signet, or install
daemon dependencies.
Published native binaries currently cover Linux x64, Linux arm64, macOS x64,
macOS arm64, and Windows x64. Windows direct installs should use
npm install -g signetai; the old PowerShell install.ps1 path has been
removed until a native Windows direct installer ships.
The wizard initializes $SIGNET_WORKSPACE/, configures your harnesses, sets up
an embedding provider, creates the database, and starts the daemon.
Path note: $SIGNET_WORKSPACE means your active Signet workspace path.
Default is ~/.agents, configurable via signet workspace set <path>.