A deal memo is a decision record. The agent can draft it, but the partner has to own the approval. Dock holds the memo as a typed row with attribution columns and pointers back to the deck in Notion, the relationship in Affinity, and the comps query in PitchBook. The agent drafts, the associate edits, the partner approves on a named version. When the fund revisits the deal, the row shows which human signed off and what the agent saw. See Dock for investors for the broader surface set.
Notion, Affinity, and PitchBook stay the system of record for the raw data. Dock is the system of record for what the AGENT INTERPRETS. Each Dock row carries a pointer back to the platform record, agent identity, decision, reviewer, and timestamp. The agent re-fetches platform data via fresh API reads when it needs current state.
The Deal Memos surface
| deal | stage | memo_draft_by | edited_by | approved_by | status | notion_url |
|---|---|---|---|---|---|---|
| Lumen Robotics | Seed | agent:scout-ic-v3 | sarah@fund.vc | partner:govind@fund.vc | approved-2026-05-22 | notion://p/lumen-deck |
| Harbor Health | Series A | agent:scout-ic-v3 | dustin@fund.vc | pending | in-review | notion://p/harbor-deck |
| Quill AI | Pre-seed | agent:scout-ic-v3 | sarah@fund.vc | partner:govind@fund.vc | passed-2026-05-19 | notion://p/quill-deck |
The memo_draft_by column carries an agent identity, not a service account. See agent identity on why this matters. Affinity org IDs and PitchBook IDs live in columns elided here.
The workflow
- A new deck lands in Notion. The agent reads it, pulls the founder's prior raises from Affinity, and queries PitchBook for three comps by sector and stage.
- The agent drafts the memo into a new Dock row at status
draft-by-agent. Every claim cites a source pointer back to the original Notion block, Affinity field, or PitchBook record. - An associate opens the row, edits the thesis, corrects any misread metrics, and flips status to
in-review. Edits are stored as a diff against the agent draft, not a silent overwrite. - A partner reads the version-locked memo, asks the agent two follow-up questions in the row thread, and approves. Status flips to
approved. The version freezes under the partner's name in the audit and compliance log. - Six months later, the fund revisits the deal. The frozen memo is the contemporaneous record. The agent re-fetches PitchBook for current revenue and notes the delta in a fresh row, leaving the original approval intact.
Why it matters
Investment committees fail when the memo and the decision drift apart. If an associate rewrites the draft and the partner approves without seeing the diff, nobody can later say what the partner agreed to. Dock keeps the draft, the edit, and the approval as three attributed acts on one row. The agent never gets approval authority. The associate's edits are visible, not invisible.
This is the pattern we use for founder operations and for deep research: the platform holds the source, Dock holds the interpretation, the human signs by name. Andreessen Horowitz states its evaluation philosophy on its About page; Tomasz Tunguz's founder's guide to venture capital covers the fundraising side. Neither describes the attribution problem.
Clone the Memos surface from the investor research surface template.
FAQ
Can the agent approve a memo on its own?
No. Approval requires a partner-level human identity on the row. The agent can draft and answer follow-ups, but the approved_by column rejects agent identities by schema.
What happens to the memo if PitchBook data changes later? The frozen memo keeps the values the partner approved against. A new row records the delta with a fresh timestamp. The original approval is not retroactively altered.
How does the agent know which Affinity contact maps to which Notion deck?
The intake step writes a notion_url and affinity_org pair on the row at draft time. The agent does not infer the link later. If the pair is missing, the row stays in draft-blocked until an associate resolves it.
Can two partners co-approve?
Yes. The approved_by column accepts multiple partner identities, each with its own timestamp. The version is frozen on the first approval and additional partners sign the same version.
