28 Grow shared foundations from demonstrated needs

An ecosystem begins to make sense when several products need the same responsibility handled well. It becomes difficult to direct when every possible future use is treated as a present requirement.

Several systems may encounter recurring needs: model management, execution, agent composition, coordination, knowledge representation, and provenance. Those connections justify investigating shared infrastructure. They do not establish that the systems should become one monolith or that proposed integrations already work.

A shared foundation should have a reason that can be expressed through actual consumers.

Draw responsibilities before dependencies

A repository diagram often begins with arrows. An arrow is ambiguous. It may mean a runtime dependency, a shared concept, a planned integration, a source of research, or merely an application that might benefit later.

First describe the responsibility: managing resources, executing work, composing agents, preserving records, supplying guidance, or coordinating participants. An application may need several of these responsibilities without sharing the same purpose or information model as another application.

Then label the connection. Is there an inspected call path? A shared data contract? A proposal to adapt an idea? A dependency needed for an end-to-end release? The label prevents architectural intention from becoming a false implementation claim.

A responsibility map describes a proposed architecture. Concrete implementation claims need evidence from observed call paths, contracts, and behavior; a connection on a diagram is not that evidence.

Extract the common rule rather than the first application's schema

Suppose two applications need durable records. They may share transaction handling, identity, ordering, and retention mechanisms. They may not share the meaning of a workflow result, a research claim, or a model-loading attempt.

If the common layer encodes the first application's tables as its public domain, the second application must imitate that application's assumptions. The extraction has preserved code while missing the common responsibility.

A better investigation asks which invariants genuinely match. Can both applications use the same record identity and append semantics? Do they need the same consistency boundary? Which fields belong to the application and should remain opaque to the storage mechanism?

The result might be a small shared component rather than a broad platform. That is a legitimate foundation if it removes a demonstrated duplication without centralizing unrelated meaning.

Give a shared layer its own product contract

Infrastructure is used by people and agents. It needs discoverable capabilities, understandable failures, versioning, and a definition of supported behavior. Treating it as an internal convenience can leave callers dependent on incidental structure.

A shared layer also creates an organizational obligation. Who accepts a change that benefits one consumer but burdens another? How are incompatible requirements represented? Who owns migration? These questions matter even when one person currently maintains all the repositories, because agents can act as separate consumers with different local contexts.

An abstraction should make disagreement explicit. If one consumer needs durable retention and another needs ephemeral cleanup, do not bury the difference in a boolean whose meaning changes by caller. Establish the policy boundary and show what each choice costs.

Keep independent projects independent where it helps

A project can contribute ideas without becoming a runtime dependency. A ledger or workflow experiment may inform another system while remaining useful on its own. Knowledge-graph work may reveal needs relevant to research or memory tools without imposing one application schema everywhere.

This independence can improve learning: a concept encounters a different problem and reveals which assumptions were local. It can also produce duplicated effort. The decision should be based on the value of those different contexts, not a reflex to consolidate everything.

For an exercise, draw a map of three projects using five connection labels: implemented dependency, shared contract, planned integration, research influence, and product prerequisite. Select one shared foundation and identify two actual consumer scenarios. If their invariants do not match, narrow the proposed common layer. The map is useful when it prevents an unnecessary dependency or clarifies a real one.