Founder notes
How we built an AI company brain at Weeve
Stefan Weiss
The most important source is conversation. Customer calls explain why onboarding is confusing. Product discussions expose weak assumptions. Investor meetings contain commitments that can affect the plan months later.
I record those conversations with Weeve. The recording, transcript and summary are processed locally on my Mac. Afterward, I deliberately ingest the relevant output into the private, local source layer of the company brain. The mechanics of that step are boring on purpose: we have written up the Claude Code and Claude Cowork versions of it separately.
Weeve does not silently send meeting content into a shared cloud database. Confidential transcripts stay local. Only reviewed summaries, safe metrics and source pointers can move into the remote-safe part of the system.
That creates a useful loop:
Step | What happens |
|---|---|
Conversation | A customer, partner, investor or team discussion takes place. |
Capture | Weeve records and summarises it locally. |
Evidence | The transcript enters our immutable local source layer. |
Review | Agents compare it with product data, execution and existing company knowledge. |
Decision | I approve, change, defer or reject proposed updates. |
Action | Approved knowledge updates the wiki and the skills that use it. |
The product we are building is one of the sensors for the company building it.
Our weekly review is an editorial process
Once a week, a small group of agents reviews what changed. Research extracts customer evidence first. Five domain reviewers inspect the same week, then a CEO reviewer combines their proposals into one short packet.
I receive one batched decision instead of a stream of interruptions. Nothing updates the wiki or skills until my decision is recorded.
The human gate lets the brain change its mind without quietly rewriting its past. Every approved change records the files involved and their hashes before and after the edit, so we can verify the scope of one decision independently.
What we learned from YC Software’s QM project
I recently reviewed QM, YC Software’s open-source multiplayer agent harness. It gives people and shared rooms scoped memory, files, permissions and durable workspaces.
We do not need that full runtime yet. Its implementation still exposed several weaknesses in our simpler setup.
QM pattern | The weakness it exposed | What we adopted |
|---|---|---|
Scratch memory that later promotes durable facts | A possible insight could enter the wiki too early or disappear entirely | A candidate inbox with a 14-day review window |
Explicit memory consolidation | “Update the wiki” was too vague | Every proposal is now |
Memory benchmarks | Counting pages does not prove that information can be found | Retrieval tests for critical facts and stale claims |
Skill synchronization | Repository skills can drift from the copies agents actually run | An approved runtime manifest with deterministic hash checks |
Provenance-aware security | Transcripts and web pages can contain instruction-shaped text | External content is labelled evidence and can never override system rules |
The most useful lesson was simple: memory quality needs tests.
Our benchmark now asks questions such as “What is the current revenue evidence?”, “Can this pilot be named publicly?” and “What is our position on bookkeeping partnerships?” It checks whether the right page appears and whether outdated claims have returned.
For now, a catalogue and local full-text search are enough. We will add a heavier search layer when the number of pages makes it necessary.
What surprised me
The difficult part was deciding what earned the right to become company knowledge. Early reviews found optimistic statements that had outlived their evidence. Product analytics showed what people did; conversations were still needed to understand why.
The system became more useful when we added friction in the right places:
New evidence can enter automatically.
Durable knowledge requires review.
Production changes require approval.
Important answers must survive a retrieval test.
How I would start today
You do not need a multi-agent platform on day one. Start with five pages: current status, product, customers, positioning and strategy. Preserve their sources. Connect one conversation source, one product-data source and one execution tracker.
Then run one weekly cycle:
What changed?
Which existing belief does it support or contradict?
What should be added, updated, deleted, split or left alone?
Which changes do you approve?
Can the system still retrieve the right answer afterward?
For us, Weeve makes the first step easier. Meeting context can enter a private evidence system and, after review, improve how the company operates.
That is how we work at Weeve today. The company brain is still small, deliberately. But every week it knows a little more about what is true, what remains uncertain and what we should do next.
The recording half of this is Weeve's free Starter plan: 10 meetings a month on a Mac, transcribed and summarised on the device, which is what feeds the local source layer described above. It needs Apple Silicon and macOS 14 or later. On any other machine the browser transcriber will produce a transcript from a recording you already have.
