KNOWLEDGE BASE / REFERENCE
The work,
explained properly.
The homepage names the projects. These pages explain them. Each entry covers what something is, the problem it was built to solve, how it behaves in a real system, where it stops, and which primary sources to read next.
CATEGORY / ROUTING
Agent brokers
The component that decides which agent or harness should handle a piece of work, without running the work itself.
A broker is the piece most people skip, because it does nothing visible. It runs no agent loop and executes no tools. It decides where work goes, under whose authority, with what budget, and it is the reason a system with several harnesses does not become several systems.
PROJECT / BROKERMerced AIA local-first broker that finds the agent harnesses already installed on your machine and runs portable profiles across them.
CATEGORY / EXECUTION
Agent harnesses
The software that actually runs an agent: the loop, the tools, the state, the limits, and the record of what happened.
A model produces text. A harness turns that into work. Almost everything that separates a demonstration from a system you would run against real infrastructure lives here, and almost none of it is about the model.
PROJECT / GOVERNED HARNESSLoroA Python agent harness that starts with identity, policy, approvals, and audit, and adds capability inside those constraints.
PROJECT / DEVELOPER HARNESSMagAgentA terminal-native Python agent framework built around persistent graph memory, portable agent profiles, and a broad tool surface.
CATEGORY / MEMORY
Agent memory
What an agent knows that outlasts a session, how it gets written, and why writing indiscriminately makes an agent worse.
Memory is the difference between a tool you re-explain everything to and something that gets better at working with you. It is also the component most likely to degrade quietly, because a store that accumulates everything makes every future retrieval worse.
PROJECT / MEMORYMagGraphA Rust-backed graph memory layer where knowledge lives as Markdown files in Git and edges emerge from links between them.
CATEGORY / INTEROPERABILITY
Open contracts
The specifications that let agent definitions, capability, and plans move between runtimes instead of being rebuilt.
Every agentic system defines what an agent is, what it knows how to do, what it can reach, and what shape a piece of work takes. The only question is whether those definitions belong to your organization or to whichever tool you adopted first.
SPECIFICATION / WORK SHAPEAgentic Graph SpecificationAn open format for decomposing a project into a graph of bounded agentic loops, so the plan can be reviewed, priced, and moved before it runs.
SPECIFICATION / IDENTITYOpen Agent ProfileAn open specification for persisting a named agent as a file instead of a running process, with three rules that make it safe to leave switched on.
DESIGN PRINCIPLES
Four operating principles
The commitments that shape every project here, written out with what each one costs and where it is hard.
Agents, profiles, and workflows should move without being rebuilt around a single vendor, because the definitions are the part you cannot recreate.
PRINCIPLE / 02Authority is explicitAn agent should know what it may do, what requires approval, and where its responsibility ends, enforced in code rather than requested in a prompt.
PRINCIPLE / 03State is inspectableMemory, context, and execution history should be understandable rather than trapped behind an interface you cannot see into.
PRINCIPLE / 04Claims need evidenceUseful autonomy comes from traceable decisions, observable work, and verifiable outcomes, not from an agent asserting that it finished.
SHARED VOCABULARY
Reference
Terms used consistently across this site, defined once so the rest of the pages can stay short.