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

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

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.

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>.

Tell your agent to install it