Skills and memories

Every workspace ships with two native objects, skill and memory. The agent reads skills to know how to do a task and memory to know what it learned about your people, your rules and your data. Skills are ordinary records you write yourself. Memory is written by the workspace: you and your agents read it like any record, and only the workspace's background memory pass and people editing a souvenir write it. This cookbook creates a skill from the SDK, has the agent learn something about one of your records, and reads it back.

What you will buildCopy Anchor Link

A skill named invoice-followup that the agent follows the next time someone asks it to chase a payment, and a memory page on one of your companies records, written from a conversation, that the agent reads whenever that company comes up. You verify both from the SDK, the CLI, the search endpoint and the app.

Both are reached through the agent's tool grants. Skills are part of core, which is always on: every agent can read a skill even without a sandbox (the skill's files then stay out of reach). Memory is the memory group, on by default for a new agent; an agent whose toolGroups omits it neither reads nor saves memories.

What a skill isCopy Anchor Link

A skill is a folder in the Agent Skills format, the one Claude Code and other agent tools read: a SKILL.md file and the files it uses. In Standards the folder is a skill record. The record's attributes are the frontmatter of SKILL.md, its content is the body, and its drive holds every other file.

The name is stricter than the standard, which also allows accented and non-Latin lowercase letters: Standards keeps to a-z, 0-9 and hyphens, because Claude Code and the command-line tools expect that. A skill never takes a built-in name (ui, skill-creator, agent-browser, agent-desktop and the names of the skills Standards ships).

New skills start from a template with the sections ## Overview, ## When to use, ## Instructions, ## Examples and ## What to avoid.

FilesCopy Anchor Link

The files of a skill sit in its drive at their paths: scripts in scripts/, documents the agent reads in references/, templates and data in assets/. A skill holds at most 500 files, in folders at most five deep. The record already is the skill's SKILL.md, so a file named SKILL.md (in any case) at the root of the drive is read as SKILL-2.md (skill.md as skill-2.md), and an import refuses a folder that holds one beside its body. A file whose path holds a control character is skipped when the skill is read, and an import refuses it.

Sub-skillsCopy Anchor Link

A skill can have sub-skills. A sub-skill is a full skill with its own name, description, body and files, filed under its parent in the app and given the parent's access. On disk and in an export every skill is its own folder: a sub-skill names its parent in metadata.standards-parent instead of living inside it. The parent's body names its sub-skills so the agent knows when to read them.

How the agent loads a skillCopy Anchor Link

1. Catalog. The agent's prompt lists each skill's name and description.
2. Activation. The agent reads skill:<name>. The answer holds the body, the skill directory and the list of the skill's files by path. It never holds a file's content.
3. Resources. The folder is written to /workspace/skills/<name>/ in a sandbox, or to $HOME/.standards/skills/<name>/ on a harness, and the agent opens or runs the files the body names. The folder is read-only and written again whole on each activation: change a skill by writing its record. A file that is not on disk is fetched with skill:<name>/<path>.

A skill whose extraFrontmatter sets disable-model-invocation: true is left out of the prompt catalog, of search and of recall, so the agent is not offered it, and it is still readable by name.

Move skills in and outCopy Anchor Link

Because a skill is a standard folder, you can take one from Claude Code or share one from Standards. standards skills pull writes your skills to disk and standards skills push imports folders; see Skills. Over HTTP the same two operations are POST /skills/export and POST /skills/import. The import checks every folder before it writes anything, and one invalid folder refuses the whole import.

The folders Standards accepts are the folders the Agent Skills reference validator, skills-ref, accepts, with three narrowings: a non-ASCII name, a metadata value that is not text, and the file path rule: a path that leaves the folder or holds a control character, a second SKILL.md (in any case) at the folder root, or two files at one place on disk (the same path twice, two paths differing only by case, a file named like another file's folder). Standards never accepts a folder the reference validator refuses. The suite that checks this runs with pnpm skills-ref:setup && pnpm test:skills-ref against the validator at a pinned commit.

Add a skill from the catalogueCopy Anchor Link

On the skills list, Browse opens the catalogue. The field searches Standards' own skills as you type, and your text stays on our server. Search skills.sh sends it to the community directory, once per click. A text of several words also sends up to three of its words alone, those that could name a skill (xlsx, not "find" or "the"), and a skill named exactly one of them comes first, the most installed first. When skills.sh does not answer and nothing came back, the search says it is unavailable rather than that no skill matched. A result opens a preview: its SKILL.md, shown as plain text, its files, its source and who will see it. Add installs exactly the commit you previewed.

A skill from Standards is visible to the whole workspace. A community skill comes from a third party, is not reviewed by Standards, and stays private to the person who added it. A result whose name a skill already holds says so and cannot be added. Adding needs the right to create and update skills.

A skill from the catalogue shows its source in its header, with Update available when a newer version is offered and Source not found when its source has gone. Opening the catalogue checks your private skills for updates. If the skill was changed in your workspace, Update available first warns that those changes will be lost and asks you to confirm.

The agent reaches the catalogue through the catalog reference kind: search with kinds: ["catalog"] finds skills, read catalog:<source> shows the SKILL.md and copy from catalog:<source> installs it. The installing copy asks for your approval, in the chat or in Décisions, with a card stating the source pinned to the commit, who will see the skill, how many files land and whether any is a script. A search of skills.sh asks first too, and its card shows the exact text that would leave Standards. The catalogue is the agent's only online search for a skill: it does not search the web for one, and a skill found elsewhere lands only through that copy, never written by hand. Asked to install a skill, the agent installs it in Standards, and copies it into its sandbox only when you ask for that too. Before the install it tells you who will see the skill, which its source decides: it never asks you to choose.

If skills.sh does not answer, our results stay and the dialog says the community search is unavailable. If the catalogue itself cannot be reached, the dialog says so and Search skills.sh still works.

What memory isCopy Anchor Link

Memory keeps what was said and is stored in no record: what a person said in a mail, a meeting or a conversation. It is a small set of pages, one memory record each, of two kinds:

Nothing a record already stores enters memory: no field value, no status, no note text, no edit history. A topic worth remembering that has no record becomes a record (a competitor is a competitor record) or a skill (a procedure). A page with neither profileOf nor subjectId cannot exist.

A page has a name (100 characters), a one-line description (160 characters) and a content of souvenirs, at most 4,000 characters. A souvenir is one line:

- Le DAF décide seul → record:… — Claire, 2026-10-02 [décision]

It says what was said, where it comes from (→ source: a meeting or record, a mail, or the owner of a private conversation or proposal), who said it and when (— Claire, 2026-10-02), and its type, one of five:

A souvenir with a natural end carries the day it stops holding, (jusqu'au YYYY-MM-DD). A contexte carries a review date, (revoir YYYY-MM-DD), six months after its day, set by memory and never by the model. A line written or corrected by a person ends with ✍ and carries no source. Uniqueness is enforced: a workspace holds one live profile per actor, and one live page per record. Deleted pages stay in record history and can be restored; the memory themes that existed before this change were moved to the trash and stay restorable from history.

Agents propose, the workspace writes. An agent never writes memory. When it notices something worth keeping, it calls propose_memory, with the record it is about when there is one. A background pass, the Dreamer, reads that proposal together with the other evidence, then rewrites the pages concerned. Every item it reads gets a verdict, written, refreshed or refused, and most are refused: a pass that writes nothing is a good pass. It refuses what a record stores, a log of what was done, a task to do, a one-off request, what will not matter in six months, an inference nobody stated, anything sensitive coming from a private source toward a shared page (health, pay, private life, beliefs), and anything about no record and no profile. When an item confirms a souvenir already there, memory moves that line's date to the item's day instead of writing it again (and a contexte's review date to six months after). The Dreamer runs the workspace's utility model at a low reasoning level. On the workspace profile, a section headed ## Mission mémoire says what this workspace wants remembered: the Dreamer reads it before every rule and never rewrites it. The section ends at the first blank line or the next ## heading.

What memory readsCopy Anchor Link

Five sources, nothing else:

• Conversations with at least two of your messages, or one that asks to remember or to correct something ("remember", "from now on", "always", "never", "retiens", "désormais"…). A conversation whose agent read another conversation teaches memory nothing, nor do its runs, subagents and proposals.
• Mails, learned from your connected mailboxes (see below).
• Meeting transcripts, for the records the meeting is linked to.
• Proposals from propose_memory.
• Routine and agent runs, only a run that was retried, that failed before, or that a person answered after its mission message.

Record activity is not read: there is no activity or audit feed, no weekly digest of what people did, and no practices learned from it.

For each actor, the Dreamer waits about an hour to group what came in, a few minutes when you ask it to remember or an agent proposes a memory, and not at all once 20 items are waiting.

Where a souvenir goesCopy Anchor Link

Memory uses the links each source already has; it never guesses a record from a name.

The Dreamer routes each souvenir by who or what it is about, choosing only among the item's records and preferring the most specific (a deal before its contact, a contact before its company):

• About one of those records: that record's page, created on its first souvenir.
• About the speaker (an instruction, a preference): the speaker's profile.
• About how an agent or routine should work: that agent's or routine's profile.
• A rule for the whole team ("chez nous…"): the workspace profile.
• About no linked record and no profile: nothing is written.

Memory pages belong to the records your team talks about again. An object is a satellite when it points to another object through a single relation and no single relation points to it: in a CRM, notes and tasks. The framework's own documents (meetings, drives, artifacts, skills) carry no page either. A souvenir about a satellite goes to the record it belongs to, the most specific first (a deal before its contact, a contact before its company). A satellite with no record to point to refuses the souvenir. A page written on a satellite before this rule stays readable, but is no longer written to, consolidated or loaded into an agent's record cards: by hand you can only delete its lines, and an edit that adds or rewords one is refused with 400.

Shared automaticallyCopy Anchor Link

A record's page is read by everyone who sees the record, while your mailbox, your private conversations, your proposals (yours, or an agent's on your behalf) and the meetings you own are private to you. What memory learns from such a private source about a workspace record goes to the record's page with no one asked, when all of these hold:

• its type is relation, contexte or décision. A consigne or a préférence stays in your profile;
• it is not sensitive (health, pay, private life, beliefs). A sensitive souvenir is refused and never leaves your private scope;
• you have not turned off memory.shareWithTeam, a per-person preference, on by default: PUT /users/me/preferences/memory.shareWithTeam with { "value": false }, or the switch under Settings → Preferences. It applies to what arrives after you change it, and a preference that cannot be read means "do not share".

On the shared page, a colleague who cannot open the source sees no link and no id: only its kind, its owner and its day, such as "mail from Bob, 2026-10-23". With the preference off, or for a consigne or a préférence, the souvenir stays on your own profile, with a reference to the record: only you see it, on your profile's page under Memories, and in the cards your agents read, never in the profile snapshot. A reference to a record is kept only on a member's own profile: an agent's or the workspace's profile never holds one.

CleanupCopy Anchor Link

• Consolidation has its own prompt. It tidies one audience at a time (a person's private pages, or the workspace's): it retypes every souvenir, deletes what fits no type or is not durable, replaces narrow lines with the principle that explains them and turns a log into one line. It creates no page. It runs once about 4,000 characters were written to that audience's pages since the last one (at most every six hours), a week after the last one when anything was written since, and once for each audience whose pages were never consolidated under the current rules. Each pass rereads up to 200 pages, those written since or due for review first.
• Caps. A profile holds at most 15 souvenirs, and 20 per record it mentions; a record's page holds at most 20. ✍ lines are not counted, and a page full of them still accepts a souvenir from an agent. Past a cap, only a rewrite or a delete is accepted.
• Human lines. A line written by a person (✍) is never removed by memory. A rewrite that drops one is applied with the line put back. A person corrects their line by hand.
• Contradictions. A souvenir is replaced only when new evidence makes it false, and only by evidence from its day or later: an older mail imported after it never replaces it, a correction the same day does. A newer date or another meeting on the same record is not a contradiction. For a changing fact (a deadline, an intention) the newest event wins. For a fixed fact with two incompatible versions, memory keeps the one a person stated, and changes nothing when in doubt.
• Weekly removal. Every Monday, code alone (no model call) removes, from every audience that holds pages, the souvenirs whose end date has passed, the contexte souvenirs whose review date has passed with nothing confirming them since, and those whose source is gone (a deleted mail or meeting, a deleted member). On your profile, a souvenir also goes once you can no longer open its source; on a record's page, a souvenir shared from someone's private source stays while that source exists. A page left empty is deleted. A record in the trash keeps its souvenirs: it can be restored. When memory cannot check a source, the line is kept.

Learning from mail. Once an hour, memory looks at each connected mailbox for exchanges worth reading. An exchange opens only on a received mail that this mailbox's classifier filed as Direct and flagged important (see Email categories): a newsletter, a notification, a marketing or transactional mail, a mail in a custom category, an uncategorized mail, a Direct mail not flagged important, or a reply you sent never opens one. The exchange is read once it has been quiet for 2 hours, from the message just before the important mail through the last message of the thread in that mailbox, so the Dreamer reads the mail, what it answers and every reply after it, never the older part of the thread. A later important mail in the same thread opens a new exchange from that point. Only mail classified in the last 30 days is read, a mail deleted from the mailbox is left out, and the subject, the text without its quoted history and the attachment names are read, never the attachments themselves.

Each mailbox is read with its own verdict and in its own scope. A shared mailbox feeds workspace memory. Your own mailbox is private to you: what memory learns from it reaches a page your colleagues read only through the sharing rule above, never the mail itself. A mail held by your mailbox and a colleague's is read once in each, each in its owner's scope. A mail is your own words only when your mailbox's provider filed it as sent from your own address; any other mail, whatever its sender line says, is an outsider's. Learning from your mailbox is a per-person preference, on by default: PUT /users/me/preferences/memory.learnFromEmail with { "value": false } turns it off, and your mailbox is then skipped; shared mailboxes are still read. Mail you receive while it is off is never read, even after you turn it back on: memory reads your mailbox only from the moment you last turned it on. A workspace reads at most 50 new exchanges an hour and 300 a day, the longest quiet first; the rest wait for the next hour. Mail never delays the rest: the Dreamer reads a conversation, a run or a meeting before any mail waiting for the same page owner.

What memory may spend. Memory draws on the workspace's AI credits, and each person's share is capped per calendar month (UTC). Every pass is charged to someone: a pass over your conversations, proposals or mail, and a tidy-up of your private pages, to you; a pass over an agent's or a routine's runs, to the person who owns it. A pass charged to no one (workspace meetings, an agent or routine nobody owns, the workspace tidy-up) counts against the workspace's own allowance. Unless your workspace sets other amounts, a person may spend $1.00 a month and the workspace $5.00. A pass starts only while what it is charged to spent less than its allowance this month, so the pass that crosses it still finishes. Once your allowance is reached, memory keeps everything that comes in but reads none of it, and tidies none of your pages, until the next month: it reads what waited on the first day of that month, or as soon as something new comes in after your allowance was raised. A learning an agent proposes for you is still read within minutes. Once the workspace's allowance is reached, what it pays for waits the same way. The workspace's AI credits still apply on top: without credits, nothing runs.

A person with the settings update permission sets both allowances, in USD, for everyone in the workspace: PATCH /tenant/settings with

{ "memoryPersonMonthlyLimitUsd": "3.00", "memoryTenantMonthlyLimitUsd": "8.00" }

Each amount is a decimal string with at most six decimals ("3", "3.00", "0.50"); anything else, such as "abc", a negative amount or a number, answers 400 SCHEMA_VALIDATION_FAILED and changes nothing. null returns to the default, "0" stops every pass but proposals, and GET /tenant/settings reads both back (null while the default applies). The allowance is the same for every person: nobody raises their own.

Who may shape a shared page follows the permissions you already hold:

Otherwise the learning is refused: nothing is written, and nothing waits for anyone to review. Your own words can reach a page your colleagues read when you may edit what it is about: a record you can update, or an agent you can edit. A learning from a private conversation that rests on someone else's words, or on an agent's, is never widened beyond what its source could read. Memory decides alone. To get a rule onto a page you cannot write, ask someone who can to say it.

Every memory record is a page: the object has no review attributes (reviewState, reviewReason), and the API never accepts or rejects anything.

What agents seeCopy Anchor Link

• Profiles. At the start of every conversation an agent reads the workspace profile, the profile of the person it works for and its own. They are kept until the conversation ends or is compacted, so a page the Dreamer rewrites mid-conversation reaches the next conversation. The souvenirs of your profile that are about a record are not part of this snapshot.
• Record cards. For each record a turn is about, the agent receives a card: the record's label and object, up to eight principal values (each cut to 120 characters), up to five related records, its last change (who, when, which fields) and its souvenirs, with the souvenirs of your own profile about it. A turn is about a record when its message mentions it with @, when the message is sent from that record's page or peek (attachedRecordId on POST /agents/sessions/:id/messages), or when your profile holds souvenirs about it (three records at most). Cards are read as the person the turn acts for, through the same object permissions as the agent's own record reads: a record that person cannot read yields no card. An agent that may read records gets the cards even without memory access; only their souvenirs need it. The cards share a budget of 4,000 characters, the last signal dropped first, and a card is stored with its message and replayed as written. A souvenir whose source the reader cannot open shows without a link.

A souvenir's → source is where the detail lives: the agent reads the source before relying on it.

PrerequisitesCopy Anchor Link

• A workspace, an API key whose role reads and writes skill and your own objects and reads memory, and @standards/client installed.
• One record of your own for the agent to learn about. The steps use a companies record named Acme; any object works.

standards schema inspect skill
standards schema inspect memory

import { getStandards } from "./client";

const skills = getStandards().from("skill");

await skills.create({
  name: "invoice-followup",
  description: "Drafts a polite reminder for an overdue invoice. Use when asked to chase a payment.",
  content: [
    "## Overview",
    "Write a short, courteous reminder for an invoice that is past its due date.",
    "",
    "## When to use",
    "- When asked to chase, follow up on or remind about a payment.",
    "",
    "## Instructions",
    "1. Read the invoice record: number, amount, due date, contact.",
    "2. Write three sentences: the invoice, the amount and date, one clear ask.",
    "3. Sign with the sender's first name only.",
    "",
    "## What to avoid",
    "- Never threaten fees or legal action.",
  ].join("\n"),
});

Remember: @Acme wants every message in French, addressed to Claire Morel.

const companies = getStandards().from("companies");
const memories = getStandards().from("memory");

const acme = await companies.eq("name", "Acme").single();
if (!acme) throw new Error("create the Acme company first");

await memories.create({ name: "Acme", description: "Acme's preferences." });
// rejects with 403 SCHEMA_SYSTEM_ENTITY_IMMUTABLE

const page = await memories.eq("subjectId", acme.id).single();
page?.name; // "Acme"

standards records search memory --query french --format table

curl "https://api.standards.new/v1/search?q=french&objects=memory,skill" \
  -H "Authorization: Bearer $STANDARDS_API_KEY"

# Delete the souvenir named by its page and its opaque key (both from the "Memory updated" line)
curl -X PATCH "https://api.standards.new/v1/records/companies/$ACME_ID/memory" \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{ "pageId": "<pageId>", "key": "<key>" }'

What you cannot doCopy Anchor Link

• Change or delete the native objects' attributes, or name your own object after one of them.
• Exceed 64 characters on a skill's name or 1,024 on its description, or name a skill ui, skill-creator, agent-browser or agent-desktop; the API answers SCHEMA_VALIDATION_FAILED.
• Create or delete a memory record, or update anything but a page's content, through the records API, the SDK, the CLI or the MCP record tools: they answer SCHEMA_SYSTEM_ENTITY_IMMUTABLE. Agents, API keys and MCP clients cannot update content either: only the person's own session can. Propose with propose_memory, or edit a page's content from its record under Memories.
• Share a private memory page with someone: memory records are never shared, and a person granted access to a private record does not see its page.
• Raise your own memory allowance: the monthly allowances are workspace settings, the same for everyone.
• Propose more than 30 learnings an hour: the next propose_memory call is refused with SCHEMA_MEMORY_PROPOSAL_RATE_LIMITED.

Next stepsCopy Anchor Link

• Records: every filter used above.
• Objects and records: visibility, workspace versus private.
• Tools: the memory kind of search and read, and propose_memory, over MCP.
• Agent workflow: the same objects from Claude Code.
• Book a demo