LaplacianAI/openarity

An open-source agent platform where agents, tools, skills and learnings are a
knowledge graph, not a list.
laplacianai.github.io/openarity —
the argument for a graph, the harness around a run, and the docs.
> Early. There is no release and no stable API yet. The brain runs agents,
> a hub that delegates through a team's graph, and a dashboard; what it does
> not do yet is listed below. The design is still moving — open an issue before
> building anything substantial on top of it.
## The idea
Most agent frameworks pick tools by ranking a flat list. Openarity picks by
traversing relationships.
The flat list is measurably failing. RAG-MCP
watched tool-selection accuracy fall to 13.62% as the pool grew; retrieving
tools by embedding first lifted it to 43.13% and halved prompt tokens. That
is the fix the field has settled on, and the same paper reports its precision
degrading as the registry scales into the thousands — because what separates two
similar tools is not in their descriptions. It is what they connect to: the
skills that use them, the learnings derived from them, the agents that hold
them, the team whose credential they spend.
So agents, tools, skills and past learnings are a graph, and selection is a
walk. This is graph engineering rather than GraphRAG: a knowledge graph
models what a system knows, and this one models what it is — with edges of
authority and provenance, so asking what a run may do and what it can do is
the same traversal.
Around the run sits the harness an organisation needs to allow it near anything
real: identity, roles that are rows rather than constants, spend counted where
the calls happen, and deletion that destroys a team's key before its bytes. The
boundaries are structural — the agent loop is a separate Go module, so it
cannot import the brain's internals, and a CI check fails if it links a
provider SDK at all.
A planner turns a request into a workflow with branches, loops and retries.
Channels — Slack, Discord, Telegram, webhooks — are pluggable and all normalise
into one message format, so every channel works with every part of the system
without special cases.
The graph is what makes more than one surface worth building on it: Code, Work,
Knowledge, Design and a mobile client are views onto the same nodes, so a
learning earned in one is capability in every other with nothing to integrate.
None of that is built — see what is, below.
## What works today
Three things run: the brain service, oa, the CLI that talks to it, and
sdk/agent, the reasoning patterns a run happens inside.
Beside running agents (below), the brain is production-shaped:
Two HTTP listeners, one for the API and one for webhooks, with full timeouts
and graceful shutdown on SIGINT/SIGTERM
Liveness (/healthz) and readiness (/readyz) probes — readiness checks
Postgres and returns 503 when it cannot reach it
Structured logging, text with source in development and JSON elsewhere
Environment-only configuration, validated at startup, with credentials
redacted whenever config is printed
A Postgres connection pool and versioned migrations behind an advisory lock,
applied with brain migrate up
Type-safe queries generated from SQL by sqlc, and a transaction helper that