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.
Working through an agent — most Hadron tasks are ones you hand to a coding agent rather than type: what that changes about where your attention goes, what to ask for, and the four kinds of task you should still do yourself.

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.
Connections and delegated access — why an agent never gets your mailbox: it gets a scoped, revocable grant on a connection you own, issued to one App install rather than to an Agent, with an operation map that fails closed.
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.

Testing a chatbot with personas — why a conversation design needs scripted users rather than manual poking, what pass actually asserts (routing, not quality), and why a failing run needs reading, not just re-running.

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.
Product specs and citations — why product rules live in a corpus of permanent citations rather than in code, tickets or a wiki; what a citation buys by never moving; and why the durable-vs-tunable split decides every change.

Teams, workers, and sessions — why a persona is dressing on an Agent and the named identity is a worker, why a team is an App, the difference between a worker session and a chat session, the chain that traces a merged PR back to its transcript, and why a worker's name is never re-minted.
Channels — the durable, ordered message streams people and agents share; your team chat is one. Who can read a Channel is decided by the memory hosting it, the register that says who takes part grants nobody anything, and unread is worked out rather than stored.

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.