Build on a durable work spine

Briefs is a durable work substrate for applications where assistants, people, and automations need to create, update, and review the same body of work.

Get started Briefs Daily

Why Briefs exists

Assistants are good at turning conversations into action, but that work should not disappear when the conversation ends. Briefs gives developers a durable system of record for work that can be shared across assistants, applications, and people.

Instead of rebuilding persistence, identity, activity history, schemas, and MCP integration for every product, developers can build on one work contract and choose the clients that fit their users.

How it works

A natural-language request becomes a structured item through MCP. The System API stores the item and its activity history, and Daily or a custom client gives people a place to review what changed.

conversation → MCP write → item + activity → API → Daily or custom client

What developers build

Assistant workflows

Turn requests like “follow up with the design team” into structured, reviewable work instead of ephemeral chat output.

Agent operations

Let services create and update work with actor attribution and an append-only history of every change.

Custom clients

Build a CRM, research queue, content pipeline, or operations console on the same shared contracts.

Core model

Briefs keeps the work object, the responsible actor, and the history of change together. These three primitives are the shared contract behind the API, MCP tools, Daily, and custom clients.

Items

Durable entities — tasks, notes, ingest — with stable identity and workflow fields.

Actors

People and services that act. Every write records who performed it.

Activities

Append-only log per item — creates, updates, and structured change deltas.

Monorepo layout

Briefs follows a schema-first split: contracts in @briefs/shared, the write path in @briefs/system, and web clients in client/web/*.

Repository

shared/              @briefs/shared — Zod schemas
system/              @briefs/system — REST API + Postgres
client/web/
  shared/            @briefs/web-shared — UI + theme
  docs/              @briefs/docs — SDK documentation
  daily/             @briefs/daily — reference web client
client/plugin/       Cursor/Codex skills

Packages

Package	Role
@briefs/shared	Item, Actor, Activity Zod schemas and types
@briefs/system	Express API, stores, domain services
@briefs/web-shared	Shared Next.js UI primitives and theme
@briefs/docs	SDK documentation site
@briefs/daily	Default daily-driver web client

Write path

Item projection updates and activity records happen together. On create, activities carry a compact result.created payload. On update, result.changes holds field-level before/after deltas.

Clients should treat the API as the system of record — validate inputs with shared schemas, send writes through the REST surface, and read activity logs for audit and UI history.

Next steps

Quickstart — install, run locally, first requests
Developer walkthrough — request to durable work
API reference — endpoints, auth, curl examples
Schemas — imports from @briefs/shared
Protocols — MCP, OAuth, and schema boundaries
Build a client — web client on @briefs/web-shared
Briefs Daily — reference web client and local setup

Assistant integration lives in client/plugin/ — skills and MCP manifests for Cursor and Codex.