doublegate / Agent memory

Check what agents learn. Then reuse it.

A company’s agents relearn the same lessons. Keep the ones a reviewer checked.

doublegate holds what an agent writes until a person or model other than its author signs it. Other agents can then find it if they search every work area. By default an agent searches its own area and those above it.

Available today: the gate, its console, a Claude Code plugin and the offline SDK.

A worked example

See how review sorts each new claim

Each point is a claim, one thing written down for reuse. Select one to see what happened and why.

The map follows one worked example: a team's alert policy and what happened to each revision.

1×
  • New 0
  • Revised 0
  • Merged 0
  • Held 0
  • Rejected 0

Selected claim

every alert has an owner team, a runbook link and a severity; the linter rejects an alert missing any of them.

New — promoted in the payments sandbox work area, because the policy it cites requires all three fields.

Grading
Read twice by one model, for and against. Both readings promote it.
Decision
Signed by a reviewer other than its author: promoted, and marked provisional.
Readable by
Any agent on this gate that recalls across the space.
What if the source changes?

Revision 4 is held and reviewed as a claim of its own. Follow revision 4.

Claims shown so far: 0.

    The problem

    What one session learns stays in that session

    The next session pays to learn it again, in model usage and in someone's time. A six-month field experiment across 66 firms found AI tools saved individuals time. The researchers detected no shift in the amount or mix of their tasks (AER: Insights). Sharing what agents learn is a separate change, and its effect on a business is unmeasured.

    A correction waits for a reviewer
    A correction becomes a claim, held where it was learned until a person or grading model other than its author signs it. That review costs someone's time, model usage, or both.
    A rejection keeps its reasons
    A rejected claim, or a demoted one taken out of recall, keeps its content and the reasons for the decision. Nothing is deleted, so storage only grows.

    The example, opened up

    Revision 4 of the alert policy, held and rejected

    The example is one team's alert policy for its payments sandbox. Revision 3, the source of the map's selected claim, requires an owner team, a runbook link and a severity on every alert.

    Revision 4 adds a rollback test and is held. The grading model's two readings disagree, so it waits for a person, who rejects it: the test it cites is missing. Revision 3 stays promoted. A promotion never carries over to the next revision.

    Nothing is shared knowledge until a reviewer other than its author has signed it.

    The doublegate model

    Five steps from what one agent writes to what another can recall

    All five run on one gate, the doublegate service on the operator’s machine, and each has a cost.

    One claim's route through one gate.
    1. Step 1

      Write

      Written into a work area, a named place for claims, under its author's own API key or sign-in. Work areas sit in spaces: a new install has one, called main. An administrator declares any other space first. A write naming no work area or an unknown space is refused.

    2. Step 2

      Hold and scan

      Held in the quarantine, where claims wait for review, and scanned before the agent gets its answer. The scan matches known patterns of leaked secrets and planted instructions. A new kind that fools both the scan and the grading model gets through.

    3. Step 3

      Grade

      Graded by a model the operator chooses, a person or both, and never by its author. By default the two readings, for and against, come from one model.

    4. Step 4

      Sign

      Signed into the journal, the record of every decision, and promoted: other agents can now find it. It is marked provisional, because it rests on one gate's judgement. Promotion takes longer as the journal grows.

    5. Step 5

      Recall

      Recall, the gate's search, looks by default in the agent's own work area and the areas above it. It searches the whole space when the agent asks. An administrator grants an API key read or write on each space it may use. The gate refuses every other space on every transport: a promoted claim there answers as if it did not exist.

    What you can use, and what comes next

    Three sources

    Where claims come from: agent sessions, people and skills

    Claude Code

    Lessons from agent sessions

    A Claude Code session writes what it learns into its own work area. A new session finds an earlier session's promoted claims when it recalls across the space. Recall runs when the model calls it. Recall before every prompt is on the roadmap.

    The Claude Code plugin
    The console

    Corrections people make

    A person writes a claim in the gate's web console, on the gate's machine. It is reviewed like an agent's, and its author can never sign it.

    Review in the console
    Skills

    Skills, imported or written in-house

    A skill is instructions, sometimes with scripts, that change what an agent does. A skill file in a folder the operator keeps is sent for review by the skill watcher and can be promoted here. A bundle imported as an archive is inspected without running anything. It stays held on this gate, counting toward its limit of 10,000 held claims.

    Why skills are reviewed before reuse

    How to check it

    Five rules the gate enforces, and how to check each

    Rule 1

    The reviewer is never the author.

    The gate never counts a signature from the identity that wrote a claim: an agent, a person or the operator. The console shows its author Refused: the claim's author cannot sign it in place of Sign. An agent-role API key reaches 37 of 83 published methods. None of them promotes, signs, rejects, demotes or hides, and no method deletes. If an agent starts as the gate's own operating-system user, its shell can promote what its session wrote (how to prevent that). Run the agent as another operating-system user and the rule holds against it. A gate that runs under a service user of its own is on the roadmap.

    How to check it
    Rule 2

    Other agents can find a claim once it is signed.

    Recall returns promoted claims and the asker's own held ones, marked as held, never another author's held claim. By default one grading model reads each claim twice, once for it and once against, and those two readings can promote it with no person.

    How to check it
    Rule 3

    Every decision is signed and kept.

    The journal records every claim written, promoted, rejected or demoted as a signed event. Each entry links to the one before, so a later change shows. One command checks every signature. Nothing is deleted, so the record only grows.

    How to check it
    Rule 4

    Only its author and reviewers can read a held claim.

    Without the reviewer role, a caller asking for another author's held claim, by id, listing or count, is answered as if it did not exist. We publish the four things it can still learn. Three are that the quarantine is full, that it is more than 1,000 events behind, and roughly how long the journal is. The fourth takes many timed calls: whether a claim exists whose id it holds or can compute. An id is a digest of the whole write. What a caller can still learn, measured →

    How to check it
    Rule 5

    Promotion makes a claim findable and never ranks it higher.

    Promotion decides whether recall can return a claim, and adds no weight to its order. Neither does the provisional mark. By default recall matches words. Matching by meaning needs an embedding model the operator configures.

    How to check it

    Every external number links its primary source on the evidence page.

    Availability

    Available now, and what comes next

    Every agent on a gate shares what it holds, and every promotion is that gate's own, marked provisional. Next: the Solo release of today's gate, installable, backed up and restorable, with rotating signing keys and erasable content. Then Team, one gate a group shares over the network, under one review policy.

    AVAILABLEClaims held in work areas and scanned. Promoted only by a reviewer other than the author, and signed into a journal anyone holding it can verifyThe five stages →
    AVAILABLERecall in four search scopes, from the agent's own work area up to every space. Lineage, the record of who worked in which work areaWork areas →
    AVAILABLEThe console: the review queue, each claim's trail, work areas, activity, recall, status, access and settingsThe console →
    AVAILABLEThe Claude Code plugin: an agent's thirteen tools, and hooks that keep evidence at a session's start, before a compaction and at its endThe plugin →
    AVAILABLEThe SDK and the published interfaces. Programs that run beside the gate: a notifier, the skill watcher and the runner that starts a crewInterfaces →
    AVAILABLEAnother author's held claim, readable only by its author and reviewersWhat a caller still learns →
    AVAILABLERead and write granted per space, enforced on every transport and issued from the gate's API or its command lineThe interfaces →
    AVAILABLESteering, a person's direction to the agents working in a work area and the areas below it, reviewed like any claimHow recall answers →
    AVAILABLEGrading by a model that reads each claim twice. How often it is right is unmeasuredHow grading works →
    AVAILABLECrews: several agent sessions in one space, each under its own API key, working to a charter a reviewer signs, started by a runner outside the gate. How well a crew works is unmeasuredThe release sequence →
    ROADMAPThe Solo release: an installable package, backup and restore, key rotation, erasureThe release sequence →
    ROADMAPRecall before every promptWhat a group gets →
    ROADMAPTeam: one gate a group shares over the networkWhat a group gets →
    ROADMAPA second, independent gate that countersigns a promotion and lifts its provisional markSigning on one gate →