Skip to content

Estate discovery

How to discover prior work. The central checkpoint: before building, determine whether an existing system already satisfies the need, should be extended, or is materially different.

Why discovery matters

Design principle: solve once, retrieve thereafter. Agents should not rediscover accepted decisions or repeat known failures. The Asset registry exists to answer: "Does this already exist?"

Skipping discovery before proposing new work risks duplicate effort and missed reuse opportunities.

When to query the estate

Query before starting any of these:

Work type When to query
New Software workstream (Frame stage) Before designing — could an existing app be extended?
New Product evaluation Before exploring — has this market been evaluated before?
New Editorial piece Before assigning — does related research or content already exist?
New Services engagement Before proposing — does a prior engagement or deliverable overlap?
Operate change Before changing — does a runbook or prior incident cover this?

Step 1: Query the Asset registry

Use the estate discovery MCP tool to discover relevant Assets:

prepare_estate_context: identity: <current agent identity> active_role: <your role> need: "<describe what you're trying to build or solve>" privacy_class: internal

The estate index returns ranked search hits with: - Asset ID, name, and purpose - Capability description - Lifecycle status (proposed, prototype, active, maintained, superseded, archived) - Estate classification (Prototype, Lab, Portfolio-org) - Related repositories, URLs, and environments - Related Initiatives and Assets - Relevance explanation (why this asset matched your query)

Step 2: Compare capabilities

Do not compare by name or technology stack alone. Compare by capability — what the asset does for its users.

Comparison dimension Question
Purpose Does it solve the same user need?
Users Does it serve the same audience?
Capabilities What does it currently do? What's missing?
Lifecycle Is it active and maintained, or superseded?
Stack Is the technical foundation compatible with your constraints?
Deployment Is it deployed where you need it?
Privacy Does its access class match your requirements?

Step 3: Get a reuse decision

After comparison, choose one of four outcomes:

reuse

The existing capability already satisfies the need. No new work needed.

Required evidence: - The compared Asset ID and its capability description - The specific need and how the Asset satisfies it - Confirmation that no material gap exists

extend

An existing Asset is the best base, and the delta is justified. Extend it.

Required evidence: - The compared Asset ID and its current capability description - The specific delta (what's being added or changed) - Why extending is better than building new - Confirmation the Asset is active (not archived/superseded)

new

No existing Asset sufficiently fits, and a new one is justified.

Required evidence: - At least 2 compared Assets with capability descriptions - Material differences for each (not just "different stack") - Why extending the closest Asset isn't viable - Confirmation this isn't "unknown duplicate" (the agent didn't know another project existed)

insufficient-context

Estate or requirement evidence is too weak to decide. Gather more context.

Required evidence: - What's missing (which comparison dimension lacks data) - What would resolve it - Explicit acknowledgment that guessing is not permitted

Step 4: Record the decision

The reuse decision should be recorded as evidence on the workstream or Initiative.

Rules

  1. new is not valid merely because the agent didn't know another project existed. The estate query must run.
  2. Capability descriptions matter more than names or stacks. Three real-estate applications may use different technologies while solving substantially the same user need.
  3. Automated extraction may prepare candidate records; it must not silently decide that two systems are equivalent or overwrite reviewed descriptions.
  4. Human review is required for Asset relationships (replaces, duplicate_of, extends, fork_of).
  5. insufficient-context is a valid and encouraged outcome. Guessing produces duplicate work. Flagging uncertainty prompts human review.
  6. Reviewed Asset records win over READMEs, index caches, and unreviewed extraction.
  7. The estate index is derived for retrieval speed, not a system of record. Search results must point back to the authoritative source (Notion Asset registry).

Golden-path example

The real-estate group discovery:

  1. Agent proposes new real-estate intelligence scraper
  2. Estate query finds 6 Assets with "real estate" in their descriptions
  3. Human review groups them: 3 are related, 3 are distinct
  4. Review determines one is the anchor; another replaced by it; third is related
  5. Decision: extend the anchor with commercial listing support
  6. Result: decisive extend, authorized repo change, idempotent Notion writeback
  • Asset registry specification: reference/state/asset-registry.md
  • System components: about/knowledge-layers.md
  • Estate evidence: evidence/estate/