Glossary

This page is the authority for Axiom terminology. Every concept has exactly one name; the docs never use a synonym ("component", "workflow", "graph") where one of these terms applies.

Node#

A node is the single unit of compute in Axiom: a user-written handler function with a typed input message and a typed output message, both defined in Protocol Buffers. Node code runs in an isolated container and interacts with the platform only through the sidecar. Nodes are declared in a package's axiom.yaml and become available to flows once the package is published. A node is either unary (one input message in, one output message out per invocation) or a pipeline node (a streaming generator that emits a sequence of output frames).

Package#

A package is the unit of publishing: a versioned bundle of node definitions and Protocol Buffers message types, described by an axiom.yaml manifest (name, version, language, nodes, imports). Running axiom push publishes a package to the marketplace, where its nodes can be placed into flows. A proto-only package contains no nodes — only message types for other packages to import.

Flow#

A flow is a directed graph of nodes composed in the canvas (or via the API). An edge from node A to node B means "A's output message is B's input message"; edge type compatibility is checked at compile time. Invoking a flow always means executing its compiled artifact, never an editable draft.

Message#

A message is a Protocol Buffers message: the only data type that crosses a node boundary. Every node input, node output, and edge payload is a message. Message types are defined in .proto files inside packages and may be imported across packages.

Execution#

An execution is a single run of a flow, from invocation to completion, identified by an execution ID that the platform assigns when the request is accepted. The execution ID is threaded through every hop — traces, debug events, results, and the HTTP API all reference it.

Entry node#

The entry node is the node where an execution starts: the flow's single node with no incoming edges. The entry node's input message defines the flow's input schema — it is what callers send when invoking the flow via the API.

Terminal node#

The terminal node is the node where an execution ends: the flow's single node with no outgoing edges. Its output message defines the flow's result schema; an execution completes when the terminal node finishes.

Compiled artifact#

A compiled artifact is the immutable, optimized representation of a flow that the platform produces at compile time and that workers execute. Compile validates edge type compatibility and resolves every node placement; once compiled, an artifact never changes — editing a flow produces a new artifact.

Sidecar#

The sidecar is the platform proxy that runs alongside every node container and is the node's only channel to the platform. All platform capabilities — logging, secrets, memory, telemetry — reach node code through the sidecar, and the sidecar enforces tenant isolation. Node code never calls platform services directly.

Tenant#

A tenant is an isolated account scope. Every execution carries the tenant identity resolved from the authenticated API key, and the platform — not node code — enforces that one tenant's data (secrets, memory, results) is never visible to another.

Pipeline mode#

Pipeline mode is the streaming execution mode of a flow: instead of one request producing one response (unary mode), frames flow continuously between nodes and results are delivered to the caller progressively as a stream. A flow runs in pipeline mode when it contains pipeline nodes.

Session#

A session is the scope of one conversation or interaction in agent memory, identified by a session ID that always comes from the caller's typed input message — the platform never infers or injects it. Episodic memory (the record of what happened) is scoped to a session.

Consolidation#

Consolidation is the background process that promotes episodic memories (session-scoped records of what happened) into durable semantic facts that persist across sessions — for example, turning repeated conversation turns into "this user prefers TypeScript."

Flow config#

A flow config is a named profile of parameter values (and secret references) attached to a flow. Callers select a config by name at invocation time; the platform resolves the profile and injects the resolved values into the execution, so the same flow runs with different settings — say, staging and production — without recompiling.

Secret#

A secret is a named, tenant-scoped credential (an API key, a token) stored in the console and read by node code through AxiomContext at runtime. Secrets never appear in package source or flow definitions; a node declares the secret names it needs in axiom.yaml (required_secrets) so users know what to register before invoking.

Client#

A client is a named, account-scoped bundle of marketplace nodes and flows, assembled in Console → Client Builder, that compiles into a typed SDK. Each bundled node or flow is a member with a unique alias that becomes its method name in the SDK. Building a client produces an immutable, numbered version — a frozen snapshot of its members — that can be compiled into any of six languages (Python, Go, TypeScript, Java, C#, Rust). See Build a client SDK.