PLATFORM
KNOWLEDGE BASE / REFERENCE
Every part of the stack,
explained in plain language.
The homepage names the components. These pages explain them. Each entry covers what a technology actually is, the problem it was built to solve, how it behaves inside an agentic system, where it stops, and which primary sources to read next. Nothing here is a ranking or an endorsement.
01 / FOUNDATION
Data and semantics
The layer that decides what an agent can know: how records are laid out, stored, versioned, governed, and given meaning.
The bottom layer of an open agentic platform decides what an agent is able to know. It covers how records are arranged in memory, how they are stored on disk, how tables behave as they change, who is allowed to read them, and what the fields actually mean.
DATA AND SEMANTICS / FORMATApache ArrowA standard way to lay out tabular data in memory so different processes and languages can share it without converting it first.
DATA AND SEMANTICS / FORMATApache ParquetThe columnar file format that most analytical data sits in, designed to be small on disk and cheap to scan selectively.
DATA AND SEMANTICS / TABLE FORMATApache IcebergThe table format that turns a collection of files in object storage into something that behaves like a database table, with atomic commits, schema evolution, and history.
DATA AND SEMANTICS / CATALOGApache PolarisAn open catalog for Iceberg tables that resolves names, enforces access, and hands out scoped credentials, which makes it the natural control point for agent data access.
DATA AND SEMANTICS / SEMANTIC METADATAApache OssieAn incubating Apache project defining a vendor-neutral, declarative standard for semantic metadata, so metrics and dimensions are defined once and used consistently everywhere.
02 / INTELLIGENCE
Models and routing
The layer where capability enters the system, and where the choice of model stays a choice rather than a dependency.
This layer supplies reasoning and generation. Its architectural job is not to pick the best model, because there is no single best model. Its job is to keep the choice open, so that task, cost, latency, policy, and deployment constraints can each be answered separately.
MODELS AND ROUTING / MODEL ARTIFACTSOpen-weight modelsModels whose trained parameters you can download and run yourself, which changes what is possible rather than only what is cheaper.
MODELS AND ROUTING / ROUTING SERVICEOpenRouterA service that puts many model providers behind one API, so switching models is a parameter change rather than an integration.
MODELS AND ROUTING / PLATFORMNous PortalA single account from Nous Research covering model access, agent tooling, and hosted agent deployment, billed against one credit balance.
MODELS AND ROUTING / DEPLOYMENTLocal model endpointsRunning inference on hardware you control, which is the only arrangement where you can promise that content never leaves a boundary.
MODELS AND ROUTING / HOSTED ACCESSProvider APIsFrontier model capability reached over a vendor API, which is the right choice for the hardest reasoning as long as the rest of the architecture does not assume it.
03 / EXECUTION
Harnesses and brokers
The layer that turns model output into actual work, holds state, enforces authority, and decides which agent handles what.
A model produces text. Something else has to read that text, call a tool, check whether the call was allowed, keep track of what happened, and decide what to do next. That something is the harness, and when several harnesses are involved, a broker decides which one gets the work.
HARNESSES AND BROKERS / CODING HARNESSOpenCodeAn open source coding agent that runs in the terminal, an IDE, or a desktop app, and works against a very wide range of model providers.
HARNESSES AND BROKERS / MINIMAL HARNESSPiA compact agent toolkit and coding harness built to be adapted rather than configured, with a deliberately small core you can read.
HARNESSES AND BROKERS / DEVELOPER HARNESSMagAgentA terminal-native Python agent framework built around persistent graph memory, portable agent profiles, and a broad tool surface.
HARNESSES AND BROKERS / GOVERNED HARNESSLoroA Python agent harness organized around explicit authority, identity-bound approvals, policy decisions, and durable audit records.
HARNESSES AND BROKERS / BROKERMerced AIA local-first broker that discovers the agent harnesses already installed on a machine and runs portable agent profiles across them.
HARNESSES AND BROKERS / PERSONAL AGENTHermes AgentAn open source, model-agnostic personal agent from Nous Research that runs across a terminal, a desktop app, and messaging platforms, and learns across sessions.
HARNESSES AND BROKERS / LONG-RUNNING AGENTPrime AgentAn open source coding and research agent for long-running autonomous work, built around a persistent Python environment and a harness state that refines itself over time.
04 / INTEROPERABILITY
Open standards
The layer that lets skills, tool connections, agent identity, and workflow definitions move between runtimes instead of being rewritten.
Every harness needs to know what an agent is, what it can do, what it may connect to, and how a piece of work is shaped. Standards decide whether those definitions belong to your organization or to whichever tool you happened to adopt first.
OPEN STANDARDS / CAPABILITYAgent SkillsAn open format for packaging procedural knowledge as folders an agent loads on demand, supported across a wide range of agent products.
OPEN STANDARDS / CONNECTIONModel Context ProtocolA protocol for connecting agents to tools, data, and prompts, so an integration is written once as a server rather than once per harness.
OPEN STANDARDS / IDENTITYOpen Agent ProfileA specification for persisting a named agent as a file: its role, model, tools, permissions, and what previous sessions learned.
OPEN STANDARDS / WORK SHAPEAgentic Graph SpecificationA format for writing down how a project decomposes into bounded agentic loops, so the plan can be reviewed, priced, and moved before it runs.
THE OPENNESS TEST
Six properties to check
Open licenses do not guarantee an open architecture. These six pages describe what to look for and how each property fails in practice.
Whether one component can be swapped without rebuilding the system, which is the property most claimed and least tested.
OPENNESS TEST / 02InspectableWhether a builder can understand what runs and why, without adding instrumentation first or guessing from behavior.
OPENNESS TEST / 03PortableWhether identity, skills, context, and work can move between environments, tools, and organizations without being rebuilt.
OPENNESS TEST / 04BoundedWhether authority and approval requirements are explicit and enforced outside the model, rather than requested in a prompt.
OPENNESS TEST / 05GroundedWhether agents share durable data and semantic meaning, rather than recalling facts from training or inferring them from column names.
OPENNESS TEST / 06AuditableWhether people can reconstruct decisions and outcomes after the fact, months later, from records rather than from memory.
SHARED VOCABULARY
Reference
Terms used consistently across this site, defined once so the rest of the pages can stay short.