How Frege works.

Frege is a hosted SaaS control plane and brain database with a thin MCP/CLI client. Humans manage organizations, roles, keys, and review queues. Agents connect over MCP and only ever receive context allowed by their org, role, and trust zone. Protected memory and context routes derive organization scope on the server.

Read the docs View the roadmap View GitHub

Overview

A Frege brain stores institutional knowledge as versioned pages with sources, links, and trust zones. Agents never read raw files or the database directly. Instead they request scoped context, and Frege resolves org, role, and source permissions before returning anything. The backend supports login and bootstrap, org management, per-user API keys, hosted brain pages, agent sessions, memory proposals, context builds, telemetry, and MCP access.

Customers do not run the Frege database themselves. They connect agents to the hosted Frege API through the local Frege CLI or the opt-in stateless hosted MCP read endpoint.

Product shape

Frege is a hosted company brain for AI agents. The primary integration surface is MCP. REST APIs remain the internal implementation boundary used by MCP, the admin UI, and tests. Two kinds of caller reach the platform: human admins, who authenticate with a session cookie, and agents, which authenticate with a bearer API key.

Control plane: the hosted app, admin UI, REST APIs, permissions, review, and provenance.
Brain database: the canonical store of governed pages, sources, sessions, and proposals.
MCP transports: the local frege stdio server for the full governed workflow, plus an opt-in stateless HTTP endpoint for authorized retry-safe reads. Both reuse REST route authorization.

Request flow

Admins drive the control plane through the protected admin surface; agents reach governed memory through versioned APIs. Both paths resolve identity and org scope on the server before any data is returned.

  Human admin                         Agent
     │                                  │
     │  /setup · /login · /admin        │  frege mcp serve
     │  session cookie                  │  bearer API key
     ▼                                  ▼
  ┌──────────────────┐            ┌──────────────────┐
  │  /api/v1/admin/* │            │   /api/v1/*      │
  └────────┬─────────┘            └────────┬─────────┘
           │                               │
           ▼                               ▼
  org · users · roles            brain · context gateway
  keys · sources · proposals     sessions · telemetry

An ornate corridor seen through open doors converges on one distant doorway. — Eight bounded systems / corridor projection 01identity → memory → context → audit

04 / system lattice

Backend subsystems

Frege is composed of focused subsystems. Each one is org-scoped and governed by the same identity and trust rules.

next / 05Identity & control plane

Identity & control plane: Users, sessions, memberships, invites, roles, and per-user API keys. Org scope is always derived from the session or key, never from client input.
Hosted brain: Institutional knowledge stored as versioned pages with sources, revisions, trust zones, tags, and extracted links. The database is canonical; markdown is the human and agent representation.
Session ledger: Durable per-task context: user and assistant messages, tool calls, tool results, context builds, client-reported model activity, memory signals, and notes. Secrets are redacted before any write.
Memory proposals: Agents do not silently rewrite canonical knowledge. Durable updates land as reviewable proposals; an accepted page proposal creates a new brain revision and refreshes links.
Context gateway: Context builds resolve org, role, sensitivity labels, and trust zones, then return allowed chunks with citations and withheld counts.
Agent execution boundary: The customer's agent supplies the model, tools, and compute. Frege supplies a scoped MCP/API memory service and does not run the agent in the current product.
Telemetry & audit: Supported context, session, proposal, and review paths record actor, action, outcome, latency, and trust zone alongside a separate audit trail.
Trust & tenancy: Green and red trust zones gate context before any packet reaches an agent or model. Denied counts can be reported, but denied titles and bodies never leak.

Identity & control plane

Human users authenticate with password login and hashed sessions. Agents authenticate with bearer API keys only, and each key is owned by a human user. All org scoping comes from the user session or API key; a client-provided org is never trusted. Roles control document access, session access, memory proposals, source management, and audit access.

Hosted brain

Brain pages are markdown-like records stored in Postgres. They include slugs, titles, trust zones, tags, frontmatter-style metadata, revision history, and extracted page links. The database is canonical. Markdown is the human and agent representation and the future export format, not the customer-facing storage system.

Session ledger

The session ledger stores durable task context for agents: user messages, assistant messages, tool calls, tool results, context builds, client-reported model activity, memory signals, and notes. This is where task context belongs, kept separate from telemetry metadata. Hard secret protection runs before every ledger write, redacting obvious API keys, passwords, authorization headers, cookies, and provider tokens.

In the Live Run Rooms private beta, the local CLI streams Codex App Server events into this ledger and polls recorded control directives. Authorized same-org teammates can watch the feed while a controller lease gates redirects, stops, exact approval resolution, and handoff. Codex still executes on the originating machine under its existing sandbox and approval settings.

Memory proposals

Agents do not directly rewrite the canonical brain. They create proposals for page creation, page updates, and source creation. Admins review proposals in the console. Accepting a page proposal creates or updates a brain page, writes a new revision, and refreshes extracted links, so agent observations stay auditable before they become trusted org memory.

Evelyn De Morgan's Phosphorus and Hesperus: two figures bearing morning and evening torches beside the sea. — Evelyn De Morgan / Phosphorus and Hesperus / 1881one governed source / two cited interfaces

09 / governed light

Context gateway

The context build endpoint returns a governed packet that combines documents, chunks, and hosted brain pages. Frege resolves the API key into organization, human key owner, role, allowed labels, trust zones, and capabilities, then filters by org, role permissions, sensitivity labels, and trust zone. It returns only allowed pages, documents, chunks, links, citations, token estimates, and denied counts. When a session is provided, the context build is linked into the session ledger.

next / 10Execution boundary

Agent execution boundary

The customer's agent supplies the model access, tools, and compute. Codex, Claude Code, or an internal agent runs in the customer's environment and calls either the local frege mcp serve bridge or the opt-in hosted read endpoint. Frege authenticates every call and returns scoped, cited data. Session events and reviewable proposals remain on the local stdio path until remote writes have a durable idempotency ledger.

The hosted app is a memory and control plane, not an inference host. Frege does not run customer agents or call their models in the MVP. Optional hosted execution can be considered later if customers need it and the policy boundary is ready.

  Customer environment
    -> Codex / Claude Code / internal agent
    -> customer's model credentials, tools, and compute
    -> local frege mcp serve process

  Frege hosted API
    -> authenticates the scoped API key
    -> returns governed, cited context
    -> records sessions and reviewable memory proposals

  Frege does not run the agent or call its model in the MVP

Model credentials stay with the customer's agent client. Frege only needs the scoped API key used to reach the organization's governed memory.

Telemetry & audit

Telemetry is the metrics and observability spine for supported product paths. It records actor, user or key, request, route action, outcome, latency, trust zone, and redacted metadata, and links to sessions, session events, context builds, proposals, and reviews. Clients may attach their own model metadata to session events. Compliance history lives in a separate audit trail, while raw task memory stays in the brain and session ledger.

Trust & tenancy

Frege uses two trust zones. Green covers normal public and internal context; red covers restricted context. Public and internal sensitivities map to green; restricted maps to red.

Every protected query filters by organization.
Agents inherit org, owner user, role, labels, and capabilities from their API key.
Humans inherit org access from their session membership.
Agents without red-zone permission cannot receive red-zone pages, documents, session events, or context chunks.
Denied counts can be reported, but denied titles and bodies do not leak.

MCP surface

MCP transports reuse Frege's authenticated REST route boundary; they never add a second database or authorization path. The local stdio server supports status, reads, context builds, durable session writes, and proposals. The modern hosted endpoint is process-stateless and read-only: it can search governed knowledge and visible task sessions, then read one by explicit session_id, but it cannot mutate knowledge, meter a context build, or invoke local Graphify.

Set up the CLI See pricing Create account