Nodes

A node is one thing worth remembering: a person, a decision, a preference, a fact, a project, a document. Every memory your agents store is a node, connected to others by edges and hyperedges.

Fields

Field	What it holds
key	A stable identifier you choose and reuse, e.g. decision_jwt_auth. Up to 512 bytes.
description	What the memory says, in plain language. It’s what search and people read first.
data	Structured fields: dates, statuses, IDs, URLs, numbers, file paths.
node_type	One canonical type from the list below.
search_text	Optional extra keywords for keyword search.
enrichment_status	Where background enrichment is: pending after every write, then processed by HyperMemory’s workers.

Node types

Every node is filed under exactly one of these types:

Type	Use for
person	A human being referenced in memory.
organization	A company, institution, agency or formal entity.
group	An informal collection of people — team, committee, department, squad.
location	A city, country, office, venue or address.
project	A named initiative, workstream or campaign with a beginning and usually an end.
product	A commercial offering — app, device, brand or named service.
component	A software module, service, system part or architectural element.
technology	A language, framework, platform, protocol or standard.
tool	An instrument or utility you use to do work, including MCP and CLI tools.
decision	A choice, requirement, obligation, constraint or commitment, with its rationale.
preference	How someone likes things done — a working style or rule.
fact	A standalone data point, measurement, spec or configuration.
event	A meeting, incident, milestone, launch or release.
concept	An idea, principle, pattern or mental model.
skill	A capability, expertise or learned ability.
style	How an agent should communicate or look: voice, tone, vocabulary, formatting, visual language.
artifact	A deliverable, cited work, content item or work product that isn’t an uploaded file.
document	Reserved for uploaded files that HyperMemory stores. For text references to documents, use artifact.
asset	A physical or digital object — hardware, equipment, infrastructure, a named resource.
URL	A web link, bookmark or API endpoint.
user	The owner of the graph. One per graph: user_profile.

When you don’t name a type

If you omit node_type, or send one that isn’t on the list, HyperMemory works it out:

1. Aliases — tech → technology, org / organisation → organization, doc → document, pref → preference, url → URL.
2. The key’s prefix — decision_… → decision, person_… → person, and shorthands such as task_ / milestone_ / phase_ → event, metric_ / stat_ / claim_ → fact, feature_ → component, requirement_ / blocker_ / obligation_ → decision, article_ / deliverable_ / data_ → artifact.
3. Otherwise, fact.

Free-form types are never stored.

Keys

Use {type}_{name}: person_alice_chen, decision_jwt_auth, tech_redis, project_phoenix.

• Keys are API surface: other nodes, relationships, exports and agents refer to them. Treat them as stable IDs.
• Reuse a key to update a node — hm_store on an existing key changes only the fields you send.

Writing good nodes

Example

{
  "key": "decision_jwt_auth",
  "node_type": "decision",
  "description": "Chose JWT access tokens over server sessions for the public API so it can scale statelessly across regions.",
  "data": {
    "chosen": "JWT",
    "rejected": ["server sessions"],
    "rationale": "stateless horizontal scaling",
    "decided_on": "2026-10-01"
  }
}

Enrichment

After every write, HyperMemory’s background workers enrich the node: they expand thin descriptions, extract structured data, detect the people and organizations it mentions, discover relationships, merge duplicates and keep your user_profile current. You can also run the memory workers on demand.

The user_profile node

Every graph has one user_profile node of type user: you. Your preferences link to it, and enrichment keeps it up to date.

Next steps

Edges & hyperedges

How nodes are connected

hm_store

Write a node