Living
English

Development sped up.Understanding systems
has to change too.

Features ship faster and faster, yet the project as a whole gets harder to grasp.

One project, two pacesConcept sketch · not measured data
Implementation speed
A widening
understanding gap
Accumulated understanding
StartAfter many iterations

While agents keep implementing, Living brings together how the system works today, what changed and the engineering records behind it — so you can see what the project is now, why it became this way, and which questions still deserve attention.

Get started

Public Beta coming soon

Code records the implementation.But where is the reasoning?

From scattered engineering material to a project thread you can follow from a question to its answer.

BeforeMaterial scattered everywhere

  • Agent chats
  • Commit 8f2…
  • Design notes
  • Test results
  • Arch. changes
  • Requirements
  • Meeting notes
  • TODO

Record · classify ·
connect

Project threadThe full trail of one question

Why did we move to a separate search service?

  1. 01Current system

    The design and structure today

    • App service
    • Search service
    • Data store

  2. 02Key change

    What changed, and why

    1. BeforeDirect database queries
    2. AfterA separate search service

    The background can be traced

  3. 03Evidence & open items

    Discussion, verification, follow-up

    • Design discussion
    • Verification log
    • Open question

Not another document — engineering context you can find again, by question.

Concept sketch · how recorded engineering information is organized

Three engineering lenses

See the system. Recover the reasoning.
Keep the whole in view.

01Engineering map

See the system

“The agent changed a lot of files. What does the system look like now?”

Before you continue, you need to know which modules and data this round touched — without reading the code from the top.

Living helps you
Draws how requirements, implementation approaches and data resources relate, so you enter the system through its capabilities.
What to expect
A faster way into the system: its main components and relations, and where a closer look is worth it.

The map gives context for engineering judgement. It does not grade engineering maturity.

Sketch · a fictional document-search app

Files changed this round

  • web/search-page.tsx
  • api/routes/search.ts
  • api/import/worker.ts
  • jobs/queue.ts
  • search/indexer.ts
  • db/migrations/0007.sql
  • … 14 files in total
NeedsApproachData
Import docsSearch docsImport flowSearch flowJob queueIndexDatabase

02Decision trail

Recover the reasoning

“We are about to change the architecture again. Why did we choose the current design last time?”

The context and constraints are spread across sessions, experiment logs, commits and documents, so every new discussion tends to start the search over.

Living helps you
Keeps recorded engineering choices together with their history, evidence, verification results and open items.
What to expect
Understand why the current design was chosen, revisit the options that were considered, and check whether an old judgement still holds.

Developers always make the call. Living only makes the information behind it easier to find.

Sketch · the trail behind “how background jobs run”
  1. First approachSynchronous, in the requestSimple; fine for small files
  2. Why it changedLarge imports timed outAn issue record and one agent session
  3. Current choiceA separate job queueImports now run in the background
  4. Evidence
    • Design discussion
    • Load-test log
    • Open: retry policy on failure

Before changing it againDo the original constraints still hold today?

03Project overview

Keep the whole in view

“The feature list keeps growing. Have we talked about testing, recovery and operations?”

Attention naturally goes to the feature at hand. Testing, security, performance and operations are hard to keep track of from memory alone.

Living helps you
Looks at the project as a whole: which topics have records, which judgements need verifying, and where nothing clear has been found yet.
What to expect
An easier way to spot engineering topics worth discussing or verifying, and to decide what to look into next.

Beta todayShows coverage and status in one place.ExploringKeeping records and observations up to date automatically.

Sketch · coverage of engineering areas
  • Records found
  • To be verified
  • No record found
  • NeedsRecords foundRequirements and change notes
  • DesignRecords foundDesign notes and architecture changes
  • DataTo be verifiedMigration records, content not checked
  • TestingRecords foundVerification scope and results
  • SpeedTo be verifiedOne load test, conclusion pending
  • SecurityNo record foundNothing found in the material yet
  • OpsNo record foundNo material on backup and recovery

“No record found” means nothing has been found in the material yet — not that the work was never done.

  1. See the system
  2. Recover the reasoning
  3. Keep the whole in view
  4. Back in control of the project

What you get now

An easier way to understand the project, find the reasons behind decisions and notice issues that deserve attention.

What we hope for over time

Fewer gaps in knowledge and less re-learning, so engineering decisions stay connected and the project stays manageable.

This is a product hypothesis. It has not been tested experimentally.

Living does not decide for you.
It gives you the view you need to decide.

These lenses are already becoming a real workspace.

A project’s architecture
is more than its final shape.

This is a real engineering view from the current Living Beta. Starting from the system structure, you can go on to the key architectural choices, the design constraints around them and the evidence behind them.

Engineering outcomesSystem architecture

  • Architecture overview
  • Code organization & conventions
  • API & interface design

Scope Fixed casea Q&A project on the novel Water MarginCurrent runtime not verifiedLast reliable observation Candidate datanot formal Knowledge

What it is nowSystem structure

Deployment host · Docker Compose

Network with outbound access

appApp service

Internal network · no egress

searchOpenSearch
falkordbFalkorDB
toolsOn demand · setup & checks

Host data · not network services

beta.dbQuotas & feedback
DatasetFrozen dataset · offline

Parts the architectural decision refers to

Why it became this wayArchitectural decision

Related searchfalkordbDataset

Why is online knowledge no longer served straight from SQLite?

  1. Previous designThe online app read knowledge directly from SQLite
  2. Why it changedKeep the frozen dataset as an offline basis only, so the online app no longer mounts knowledge files
  3. Current choiceOnline knowledge now comes from OpenSearch and FalkorDBQuotas and feedback stay in beta.db
  • Related design notes5 design constraints and trust assumptions, e.g. the databases are reachable only on the internal network
  • Implementation and verificationExperiment environment verified (Oct 24) · GraphRAG case Beta switched (Oct 25)
  • Open itemReleasing the two stores is not yet one atomic operation

ProposedIts adoption is known only second-hand, so this decision has not been recorded as final.

Real Beta screen content · simplified redraw of a fixed caseVersion numbers, external services and some network details are left out. The view shows no live runtime status; the material is candidate data, not formal Knowledge.

Sources
Where does this material come from?See how Living works with your coding agent

How it works

It fits how you work.
It does not replace it.

Your usual coding agent still does the development. Living only lets the engineering information worth keeping build up along one clear path.

This diagram shows the local Beta using a stdio adapter. Getting Started previews remote HTTP MCP access for the public Beta, which is still in preparation.

AYour project

Living SkillsDefine which information is worth keeping, and how to turn it into records and knowledge
Public

Guide

Coding AgentClaude Code or Codex does the development as usual

1Organize and write

.living/ local engineering recordsRecords, knowledge objects and sync state stay in the project

BMCP layer

MCP Adapter
  • Get project context
  • Read Knowledge and contracts
  • Validate structured records
  • Submit an explicit sync
  • Return the sync result
Planned release

To the agent: stdio
To the backend: HTTP Agent API
Stores no data itself

CLiving coreProduct core

Living Backend
  • Data contract validation
  • Structured sync and version history
  • Linking and projecting engineering material
  • Evidence and source tracing

4Organized into engineering lenses

Living WebSystem & capabilities · Outcomes · Evolution

The engineering index is prepared and installed separately for now, not through sync.

  1. 1Following the Skills, the agent organizes engineering information and writes it to .living/ in your project.
  2. 2When you explicitly ask to sync, the agent validates through MCP first, then submits.
  3. 3The backend validates and writes the whole batch, and hands a receipt back to the project.
  4. 4Living organizes the synced material into visual, traceable engineering lenses.

Syncs only when you askDoes not collect agent sessionsMCP stores no dataLiving Web never reads or writes your project folder

Why connect through MCP

  1. Keeps your coding agent

    Living is not another agent. Any client that supports the tool interface can read Living’s engineering context and submit a sync. Adapters exist for Claude Code and Codex; other clients have not been verified.

  2. Development and knowledge stay separate

    You keep developing with the tools you know; Living stores and organizes the structured engineering information you submit. Every round of development can become part of a lasting understanding of the project.

  3. Clear interfaces and data boundaries

    The MCP Adapter never touches Living’s database; the backend does all validation and writing. What the agent does to project files does not directly change the formal data in Living.

Current version · Beta 0.3

From seeing the project
to keeping an eye on it.

Living is currently a single-user Beta running on the author’s own machine. It is not open for public installation, and there is no sign-up or trial yet.

Available nowWhat the current Beta does

  • System and capability mapHow requirements, approaches and data resources relate, and the records behind each of them.
  • Engineering outcomes and coverageWhat material exists for each engineering area, plus overviews of architecture, code organization and APIs.
  • Evolution and source tracingThe project’s phases and key changes, with every item traceable to its original record.

Open connectors,
an evolving product core.

Public
Source files of Living Skills, pinned by version. Publicly readable; no open-source license yet.
Planned
The local MCP Adapter, a command-line tool, install examples and interface contracts. License and timing not decided.
Product core
Backend, web visualization and engineering analysis. Closed source, developed independently.
Curious how connecting works? Read Get started

Let the code move forward.Keep the understanding in the project.

Living Engineering Workspace

Local single-user Beta · early exploration