Explanation¶

Understanding-oriented background. Read this to deepen your mental model of Hadron, not to complete a task. Grouped by feature area.

Core concepts¶

What is Hadron — what the platform does and who it's for.
Entity architecture — entity hierarchy: organizations, agents, memories, apps, and the class/instance (Agent → App) relationship.
Surfaces: MCP, CLI, and the portal — the three ways to work with Hadron, what each is for, and which to reach for — with a capability-by-surface table.

Authorization — how Hadron decides what each person and agent is allowed to do: roles, individual grants, and the guardrails that can only ever take away — in plain language.
Subscriptions — how an organization subscribes to a memory or agent it doesn't own, and what the subscription buys.
Capability tools — why heavy capabilities like document rendering live in separate stateless sidecar tools instead of the core, with the PDF service as the first worked example.
The RAG tech stack — why Hadron's vector index uses nomic-embed-text and pgvector — the privacy posture behind the choice, and the two supported embedding-server backends (Ollama and AWS SageMaker) an operator can pick from.
Inspecting the vector index with SQL — read a memory's index state directly in Postgres: the two tables, the per-source rows and per-node markers, and aggregate queries that tell backfill-draining from complete.

Understanding memory — what memory is in Hadron, the different types, how it's stored and shared.
Structured vs. unstructured memory — Hadron is unstructured by default and structured on opt-in, over one substrate: the database analogy (nodes as rows, objectType as tables, schema as columns, where/sortProperty as WHERE/ORDER BY) and when to reach for a schema.
Memory access — how agents and apps gain access to a memory, and what the different access levels mean.
Memory ownership and lifecycle — which entity owns each memory in Hadron, and what happens when an Agent, App, or Memory is deleted.
Assets vs. References — why uploaded files and citable sources are separate primitives, and when to reach for each.

How multi-node automations work — the mental model behind multi-node headless runs: a flow is a graph the platform walks, routing lives on edges not in prompts, and extracted facts accumulate in a run envelope that conditions branch on.
Edge conditions — when to use deterministic edge conditions vs. LLM-controlled routing, and the model behind the portal's condition builder.

CLI vs. MCP for a coding agent — the two ways an agent reaches a Hadron server, compared on the axis that usually decides it: context-window tokens. Plus auth, structured output, and traversal.
Teams, personas, and sessions — why a persona is an Agent and a team is an App, where a session's LLM actually comes from, the chain that traces a merged PR back to its transcript, and why a persona name is never re-minted.

Measured findings about how Hadron behaves, with the method and the data, so you can check them or repeat them on your own corpus.

What makes a node findable — a controlled experiment on Hadron's own 271-node spec corpus: abstract length barely matters, subject drift decides everything, and a disappointing search result is usually a corpus problem rather than a node problem.