All resources

Founder operations

Memory for a founder’s AI Chief of Staff

A useful AI Chief of Staff should not summarize everything. It should recover the people and commitments that need attention, explain what changed and treat isolated personal scope as the design default.

Note on scope. This essay describes design guidance and Substrate's product direction for a founder's AI Chief of Staff—not current Substrate functionality. The selective briefing is a managed closed-beta evaluation, and the source coverage and scope isolation described below vary by deployment.

A founder does not need another inbox summary. They need a reliable answer to a narrower question: what do I need to understand, decide or follow up on today because of the people and commitments around me?

That is a memory problem, not merely a summarization problem. The relevant context may be distributed across calendar, conversations, documents and work systems. It changes over time. Some of it is personal, some organizational, and some should never be surfaced outside a specific relationship.

A useful AI Chief of Staff would turn that context into a selective briefing while preserving evidence and boundaries.

Design for attention, not coverage

The worst morning briefing is comprehensive. It reproduces every meeting, unread message and open task, leaving the founder to perform the prioritization.

A better briefing applies a materiality filter. Include an item when it meets at least one condition:

  • a commitment is due or at risk;
  • an upcoming interaction requires relationship context;
  • a person’s role, priority or availability materially changed;
  • two sources conflict in a way that affects a decision;
  • the founder explicitly asked to track it;
  • the cost of forgetting is high.

Exclude routine updates, repeated information and low-consequence activity. The output should earn attention.

Organize around people and obligations

Calendar is a useful index for the day, but events are not the primary object. The primary objects are people, relationships, commitments and decisions.

Before a meeting, the briefing might include:

  • who the person is and the current relationship context;
  • what changed since the last substantive interaction;
  • promises the founder made to them;
  • promises they made to the founder;
  • unresolved decisions or questions;
  • explicit preferences relevant to this interaction;
  • source links for consequential statements.

This is more useful than a summary of the meeting description and recent emails because it prepares the relationship, not just the event.

The founder solution page shows this people-and-commitments focus at a product level.

Separate personal and organizational scope

A founder operates across overlapping contexts: company leadership, investors, customers, candidates, friends and family. One person can appear in several.

Do not put all context into a single retrieval pool. Each memory should have an owner and scope. Retrieval should state which agent and purpose are requesting it.

For example, in a well-designed system:

  • a company preparation workflow would use authorized company correspondence and work systems;
  • a personal briefing would use only explicitly connected personal sources;
  • a customer-facing organizational agent should not receive personal notes merely because the same person appears in both contexts.

Canonical identity should recognize the person while memory remains scoped. Identity continuity should not erase authority boundaries. Substrate is shaping these scope controls; they are not offered as current behavior.

Capture commitments precisely

Founders create many commitments conversationally: “I’ll make the introduction,” “Send me the model and I’ll review it,” “I’ll talk to the board before Friday.” These promises often never become tasks.

A memory system should extract a proposed commitment, then preserve:

  • owner;
  • action;
  • counterparty;
  • due date or timing language;
  • source;
  • confidence that it was a real commitment;
  • status changes and completion evidence.

Ambiguous language should remain ambiguous. “We should connect you with Maya” is not necessarily a promise. The system can present it as a possible follow-up rather than silently creating a hard obligation.

The briefing should distinguish founder-owned promises, delegated promises and incoming dependencies. That makes the next action clear.

Track relationship change, not activity volume

A busy communication stream is not automatically important. The briefing should look for material change:

  • a stakeholder’s role changed;
  • a previously warm thread became blocked after a decision point;
  • a repeated concern appeared across independent conversations;
  • a meeting moved in a way that affects a deadline;
  • an expected introduction or document did not arrive;
  • a decision owner shifted.

These signals should be described conservatively. “No reply in five days after three rapid exchanges” is an observation. “They are upset” is a hypothesis. The latter may be worth considering, but it should not be presented as fact.

Make hypotheses actionable and bounded

A Chief of Staff provides judgment, not only facts. The system can offer hypotheses when they help prioritize attention, provided it includes the basis and a way to verify.

A good item might say:

Investor follow-up may need attention. The promised data room update was due Tuesday, and tomorrow’s meeting was shortened from 45 to 20 minutes. This may be scheduling noise; confirm whether the update is still expected before interpreting the change.

This is useful because it combines evidence, qualification and a concrete check. It avoids mind reading.

The memory-quality model explains the separation between known context, hypotheses and explicit direction.

Use a stable briefing structure

A calm briefing can fit into four sections.

People today. Upcoming interactions that benefit from context, ordered by consequence rather than calendar time alone.

Promises and dependencies. Commitments due, overdue, changed or blocked, grouped by owner.

Material change. New information that alters a relationship, decision or plan.

Decisions and questions. Items only the founder can resolve, plus uncertainty that should be checked.

Each item should answer “why now?” If it cannot, it probably does not belong.

Preserve a path to evidence

A founder will not inspect every source, but consequential claims need receipts. The briefing can show a compact source label—meeting, email, document, work item—and provide deeper inspection on demand.

Evidence is especially important when:

  • the item attributes a commitment;
  • the system infers a relationship change;
  • two sources conflict;
  • the item relies on sensitive context;
  • the founder may take external action based on it.

Provenance should respect the current source permissions. The briefing can state that supporting evidence exists without exposing content outside the current scope.

Corrections should improve tomorrow’s briefing

If the founder says, “That was not a promise,” “Wrong Alex,” or “This only matters for the fundraising context,” the correction should update durable state.

The system needs to:

  1. classify the correction;
  2. update or retract the affected memory;
  3. adjust identity or scope if necessary;
  4. invalidate derived briefing items;
  5. preserve the correction history;
  6. avoid repeating the same mistake.

A system that lets the user edit today’s text but regenerates the same error tomorrow has not learned.

Memory should not grant autonomy

Knowing about a commitment is different from being authorized to fulfill it. A Chief of Staff memory may prepare a draft, suggest a follow-up or surface a decision. External action should follow explicit authority and approval rules.

This boundary is essential because relationship context can make generated actions sound unusually plausible. The system should not infer permission from familiarity. The how-it-works model keeps memory retrieval and action authority separate.

Evaluate with a week, not a demo morning

A single synthetic briefing can look impressive. Real quality appears across a sequence:

  • Monday: a commitment is made with ambiguous timing;
  • Tuesday: the date is clarified;
  • Wednesday: the counterparty changes roles;
  • Thursday: a document repeats the old role;
  • Friday: the founder corrects an identity merge;
  • next Monday: the briefing should reflect the clarified commitment, current role and corrected identity without stale residue.

Evaluation should measure omission, false urgency, stale-state use, commitment accuracy, identity precision, scope leakage and correction persistence.

Also evaluate calmness. A system that surfaces twenty low-value “changes” can be less useful than one that misses a minor update.

Start with a managed boundary

A practical first version should use a narrow set of sources and a defined briefing contract. Choose:

  • which calendars and conversations are authorized;
  • which commitment types are tracked;
  • what qualifies as material change;
  • which people or contexts are excluded;
  • when the founder reviews proposed memory;
  • how corrections are submitted;
  • what the system will never do without approval.

Then observe actual use. The founder’s corrections reveal what the product should treat as durable, what feels intrusive and which uncertainty is worth surfacing.

The closed beta is designed to evaluate this managed AI Chief of Staff boundary with founders who can test the memory over time.

The central design choice is restraint. A useful Chief of Staff does not prove how much the system has read. It helps the founder keep promises, enter important relationships prepared and notice material change before it becomes an avoidable surprise.