Tim Bols

Designer and ex product manager. I help founders build complex AI products, structuring ambiguous problems and carrying ideas to implementation. Interested in AI engineering and the future of HCI.

Connect with me on LinkedIn, send me an , or

Book a call ⌘K

Experience

Product DesignerFreelance2026-Now
Product Managerbunch Capital2023-2025
Entrepreneur in ResidenceAleph Therapeutics2023-2024
Founder Associate InternBounti2022-2023
Business Development InternEnpal2022
Motion DesignerFreelance2021
Audit InternPwC2020-2021

Articles I like

Building Scribe Writing & Articles
Building Scribe

Scribe is an AI-powered wiki compiler. It ingests information from a range of source types — typed notes, docs, voice, web pages, and anything pushed in through its MCP channel — and turns it into durable, navigable, interlinked knowledge. Captures

Fill out later.Reference in chat ⌘J

Why it exists

Most knowledge bases die of upkeep: every capture wants filing, linking, and a pass over everything it touches, and that work compounds as the wiki grows. Scribe hands it to a librarian agent — it files, links, and keeps the taxonomy current, and every change lands as a reviewable proposal. AI is good at exactly what people find tiring.

How it works
  1. Capture from anywhere. Typed notes, docs, voice memos, web pages — or push straight from another tool over MCP.
  2. An agent compiles. Captures are deduped, linked, and filed into structured pages behind a review gate.
  3. Retrieve everywhere. Ask in chat, search the vault, or query it from any AI agent.
Reference: 1 line highlighted tighten this
Read 3 pages
Drafted the intro from what came up most across your notes — linked back to its sources above.
Building Scribe
Ask anything about your wiki…

Scribe

Scribe is a document editor and AI agent that operates your knowledge base for you, allowing you to focus on ideas and execution instead of file maintenance.

The macOS app is currently in private alpha. If you’d be interested in joining, please !

Roles
Founder
Designer
Engineer
Stack
Claude Code
Paper
Figma
Duration
May 2026 -
Now
Voice notes AI Tools Web pages Notion

How knowledge management is changing

Knowledge systems are central, both for companies and professionals. Maintaining them, however, is resource-intensive: as a knowledge base grows in size, so does the effort needed to maintain it. More documents mean complex taxonomies, more links across the network, and more information to keep current.

With the right tools, AI agents are capable enough to manage a knowledge base. I first noticed the benefit of this when my coding agent would maintain my projects’ markdown files for me: I would ask it to add a feature to the roadmap, document key learnings in our session memory, and update the project’s “design.md” file based on feedback given during the session. In a later session, I could ask what features I proposed recently, and to implement them according to the guidelines we defined.

Andrej Karpathy’s “LLM Wiki” formalized this idea recently: a knowledge base no longer needs to be maintained by hand. It can become a system that is updated, structured, and queried by agents. In line with this, Google recently released the “Open Knowledge Format (OKF)” - a standard markdown format to make agentic knowledge bases portable between systems.

However, today’s concrete applications are early and broadly have two problems:

Verification: Reviewing the agent’s work is hard. How did a source change content across pages? Was it accurate? Did it accidentally remove something important?

Accessibility: Existing approaches are not yet packaged for everyday use. Claude Code, Codex, Obsidian-Claude workflows, or Karpathy’s LLM Wiki are either technical, conceptual, or complex, requiring significant effort from the user.

Opportunity: the modern-day memex

Design a modern-day memex: a knowledge system purpose-built for agents, that keeps their work visible, understandable, and easy to change. As new information is ingested into your knowledge system, an AI agent will read it, create or extend the taxonomy, link related concepts, and update stale information across files. Importantly, changes made by the agent become well-structured, guided PRs, making changes verifiable and transparent. As your new source of truth evolves, Scribe’s MCP lets you bring it directly into any external AI tool like ChatGPT.

Design principles

Scribe is meant to feel as consumable as Notion - legible typeface with large content type, high contrast between canvas and font colors - while feeling as agent-centric as Codex and as effortless as Linear (key shortcuts, latency). Furthermore, verifiability is a key design principle:

Git for agentic knowledge systems

Both code- and knowledge bases are living systems of interlinked information that many hands, including agents, edit continuously, and where a bad change can break key dependencies.

Software solved how to evolve these systems safely: Git. Instead of inventing a new control model, Scribe borrows what has worked for millions of code bases.

This way, agents can operate with a large scope - rewriting and merging pages, or re-linking ideas across the entire knowledge base - but never silently. Changes are handled the way a good code review system would, with guided diff reports, rebasing, automated conflict resolution, and version history. The gate itself is optional: an auto-mode structures changes as updates to skim rather than reviews to pass.

Agent collaboration as a key design principle

The agent should be immediately accessible without ever displacing the content. To serve different depths of chat interaction, users can leverage three modes: a minimal bar for immediate access, a side dock for side-by-side work, and full screen for full depth. ⌘L focuses into the chat from anywhere, while ⌘J hands the agent your current selection as context; ⌘K offers a quick access modal with hybrid search for your vault.

The other half of frictionless is that the agent arrives prepared: it has broad context and tools including version history, open PRs, and the page you're on, and reaches any page through hybrid search during its turns. This way, you don’t have to explain context to the agent.

Designing the agent

Scribe is a working product, not a concept: a local-first Tauri app with a React + TipTap editor and Claude driving the compile loop. I run my own knowledge base on it daily, which keeps every design decision accountable to real use.

The compile loopCapture to wiki · Every change verifiable
  1. Capturevoice · web · MCP

    Everything lands raw in an inbox. Capture stays cheap and lossless; nothing is filed automatically.

  2. Compilelibrarian agent

    The librarian reads the new material and decides what it means for the wiki: new pages, edits, merges, links.

  3. Curatededupe · retitle · re-link

    The loop is iterative - a change can imply a second one elsewhere. The agent keeps the taxonomy current so I never have to.

  4. Reviewdiffs · version history

    Large, destructive, or cross-cutting changes stop at the gate as guided diff reports. Auto-mode turns them into updates to skim.

  5. Retrievechat · search · MCP

    Hybrid search over plain files on disk. Any agent can pull the maintained wiki into its own context.

Every accepted change is a commit — the wiki’s history stays yours to walk.

The architecture follows one rule: give the agent tools, not scaffolding. Hybrid search is a tool the librarian calls on top of its map of the wiki - not a retrieval step that pre-decides what it gets to see. Most agent failures I hit came from over-constraining the model; given a clear purpose, good instructions, and the right tools, it rarely needed the guardrails I was tempted to build.

The review gate is the deliberate tradeoff at the core of the product. It adds friction to every agent action - and that is the point: it is what lets the agent operate at large scope, merging pages or restructuring the taxonomy, without ever acting silently. Where the friction outweighs the risk, auto-mode softens the gate into updates you skim rather than reviews you pass.

Decisions like these were made empirically rather than by intuition. I benchmarked open-source GraphRAG and a context graph against my own hybrid-search setup on the real vault; neither produced a measurable win, so the simpler system stayed. And when a compile or a retrieval regresses, the failing case becomes an eval fixture - the librarian is measured against every mistake it has already made once.

Reflection

Scribe was one of the first AI tools I built end-to-end, and many learnings came with it. For example, the design process; I barely used Figma at all. Instead, I would spin up various directions in HTML and use precise language + the right model for the job. Deciding when to be a “reviewer and editor” and when to be a “creator”. Noticing how working with AI pushes you more into the reviewer role, which might compromise some of your creativity, but also unlock so many ideas.

Or setting up a self-improvement loop based on evals: giving the coding agent various levers (the tools the librarian has available, biases in the schema, etc.) and a set of evals, and letting it run until it hits a certain score across evals.

Voice intent routing latency; how even a small failure rate drops adoption for voice in general.

An interesting learning from building a tool I personally use daily from scratch is where dogfooding helps immensely, and what its shortcomings are.

Conclusion on Scribe: Making a product a business is a big challenge, and I am currently not interested in pursuing it for Scribe. However, Scribe has entirely replaced all other note taking tools for me and some of my friends - Notion, Apple Notes, etc. - and provides value daily.

Resolutions - bunch Capital

bunch builds tools to automate VC fund administration. They recently raised a $22M Series B from Portage and Cherry Ventures.

Roles
Product Designer
Product Manager
Team
1 Senior BE Engineer
1 Full-Stack Engineer
1 Automation Engineer
Company
bunch Capital

Scaling a high-stakes governance workflow

I led discovery, product, and design for a 0->1 product that reduced resolution setup time by over 90% for large funds - from 6 hours to roughly 30 minutes - and drastically reduced operational overhead throughout the process.

Resolutions - the process by which funds obtain investor consent on important decisions - was a major governance flow still running on manual workarounds. We had recently started offering this flow to our customers, and demand was growing rapidly to around 10k resolutions annually.

As this workflow was run on fragmented tools and data, it cost countless operational hours and held a high risk of human error. Creating a resolution meant manually drafting documents, configuring DocuSign envelopes, extracting legal details and data from documents, tracking submissions manually, and handling reminders ad-hoc. In total, a single resolution required the use of at least 6 different tools and took weeks end-to-end. Since it was a governance workflow directly touching fund investors, mistakes carried consequences such as delays, rollbacks, and reputational damage.

By streamlining and centralizing resolution management into one product end-to-end, resolutions shifted from a liability in bunch’s operational model to a scalable product.

Approach and problem space

I conducted five user interviews with operators managing the resolutions process day-to-day, then ran regular design reviews and updates throughout. Engineers staffed on the project joined these early sessions directly, building a shared understanding of the problem space, the “why”, and related complexities first-hand.

With the operators, we mapped the current process end-to-end, dogfooded the current experience, and documented the complexities - legal, fractured data and tools - before jumping into a specific solution.

  1. Draft documentsGoogle Drive · doc generator

    Select and adjust the template, add the resolution questions and the DocuSign anchors that let investors vote in the tool, generate the documents, and file them into the fund’s folder.

  2. Configure DocuSign envelopesDocuSign · database

    One envelope per signer: cross-reference closed vs. non-closed investors by hand, search the database for each investor’s main signatory and additional signers, add them in the correct order, attach the documents, send. Multiple hours per resolution.

  3. Track signaturesExcel · Gmail

    Work out from the LPA’s deal terms how voting power is constituted, keep a separate spreadsheet per fund and resolution tracking every investor and question, and adjust it each time a DocuSign notification lands.

  4. Send ad-hoc remindersGmail

    Regularly re-check the spreadsheet for pending signatures, then draft and send personalised reminder emails.

  5. Finalize the resolutionPDF · data room

    Cross-check the tracker against the signed documents in DocuSign, paste each question’s answer into a summary PDF for the fund and its investors, and download everything into the data room.

Human error was possible at every step — document drafting, envelope and signatory setup, tracking, reminder sendouts, deadline tracking.

Solution and design

The early alignment paid off. Implementation constraints were surfaced early and the work remained grounded in what could ship within our timeline. Since every engineer carried context from the start, decision-making decentralised where useful - the team could move on details without funnelling everything through a central reviewer, and collaboration stayed smooth throughout.

To productize this complex workflow, we decided to introduce two new, related product surfaces: a setup wizard that would allow users to create resolutions end-to-end in a simple flow, and a tracking dashboard that centralized related data and downstream tasks.

Setup wizard

A 3-step flow covers metadata entry as well as template and signer configuration. All data required to complete the task is accessible directly in the wizard instead of having to navigate across multiple tools.

Design requirements and complexities:

  • Only investors fully accepted into the fund (“closed”) are able to participate in a resolution.
  • Signer setup of each investor should be automatically loaded from the DB, with the option to configure.
  • Configure quorum (on resolution level) and approval thresholds (on question level) to ensure tracking works downstream.
  • While resolution use-cases follow a standard distribution (a few core cases dominate), exact question setup may diverge; we needed to be able to set up questions in the flow, and upload/save custom templates per fund to cover less frequent cases.
  • Since it’s a governance flow directly touching investors of the fund, transparency into what will reach the investor is strongly preferred. A persistent live document preview ensures fund managers see exactly what LPs will receive before anything is sent.
  • Signer setup: only the main signer should be able to vote (no diverging votes between signers of the same investor).

Tracking status and responses

An efficient dashboard centralizes data and tasks, giving the user direct insight into the status of the resolution and allowing end-to-end management of all related tasks.

Design requirements:

  • Action-led, scannable design: directly serve the most important information and current tasks to the user to ensure operational efficiency. Where in the process is my assigned resolution? What do I need to do next? Status and workflow should be navigated effortlessly.
  • Perhaps counter-intuitively, the voting breakdown is not the most important aspect up to close. Priority is the management of getting signatures until quorum is met.
  • The key action here is reminding investors. Extracting specific answers is often only relevant on demand.
  • Quorum and approval thresholds are taken into account automatically.
  • All related tasks can be kicked off and managed centrally:
    • Resolution summary and audit report: generate and distribute required documents when the time comes.
    • Reminders (non-automated): remind pending investors, with transparency into when the latest reminders were sent.
    • Preview and download of signed resolution documents; signed resolutions are automatically pushed into the correct data room.

Engineering complexities

  • Responses are captured directly in the DocuSign document via anchors, so we track per-question answers instead of just signatures. This had to be considered in the DocuSign integration and webhook - making sure we extract the answers for each question from the JSON file we receive for each signed document.
  • For quorum and approval thresholds, the deal terms set in the Limited Partnership Agreement determine how voting power is calculated. How many votes does €1 of commitment equal? What’s the base - commitment or investor count? This had to be visible to the operator and considered in tracking, with the deal terms queried from the correct place.