WIP

A Knowledge Community bootstraps its own tools to accomplish its knowledge goals faster.

Modular Tools

The idea is that humans, agents, and developers need access to some sort of reusable "function", or "tool". Some tools are low-level and built-in, like PublishBlobs . Other tools will build upon existing tools. For example MoveDocument tool is going to utilize PublishBlobs under the hood. Eventually, many tools will be provided by extension. Every extension will define what tools (or other info) it requires to run. If the user approves, the extension will be able to call those tools. And, a plug-in may provide tools to the user, agents, and to other extensions. A tool has the following attributes: With these features, even something as essential as "Move Document" could be implemented as a plug-in. Even though this feature is going to be built-in always, it demonstrates the power of the plugin system design

Sharing Tools

WIP A Knowledge Community bootstraps its own tools to accomplish its knowledge goals faster. Inspirations

Bootstrap

Activity: A Knowledge Community Bootstraps and Hacks Its Own System

Inspirations

Notion Tools

What does “Tool” mean? Notion seems to use Tool in two related senses: a broad product sense and a more technical, agent-centric sense. 1. Tool as an application or service In user-facing language, Notion calls products like Slack, Gmail, GitHub, Figma, Linear, Google Drive, Dropbox, ChatGPT, and Claude tools. In this sense: For example, GitHub is a tool, Slack is a tool, and Gmail is a tool. This is probably the more natural meaning for a top-level product concept. 2. Tool as an agent capability Notion also seems to use Tool in a fairly agent-centric, technical sense: That matches how Notion describes MCP connections: a connection exposes available tools to an agent, and those tools are things like search, fetch, list, view, create, update, delete, send, or post. They also distinguish between read tools and write tools. So at the MCP level, we could model it roughly as: Agent → Connection → Tools → Actions/results For example: The terminology problem This means Notion is effectively using Tool at two abstraction levels: Product level GitHub = Tool Technical/agent level create_issue = Tool That is not necessarily a problem, because the audience and context make the meaning clear. But for Seed, we may want a more explicit conceptual model. One possibility: Tool → Connection → Capabilities / Actions Where: Then an agent could use those capabilities: Agent → Tool → Connection → Capabilities → Results For example: GitHub → connected as Gabo → search repositories → read issue → create issue I think this gives us the simplicity of Notion's user-facing vocabulary without conflating GitHub the tool with create_issue the callable operation.