Building thunks from reusable parts
A thunk doesn't have to be one large, hand-built workflow. Most of what an AI agent does happens through tools, and tools are parts you can build on their own, test on their own, and reuse — inside one thunk, across many thunks, and by AI agents outside Thunk.AI altogether. This article describes those parts and how they fit together, so a team can divide the work and share what it builds.
The unit: a tool
A custom-built tool is the smallest part you can build and trust on its own. Each one has its own page in the thunk's Custom-built tools pane, with everything you need to work on it in isolation:
Definition and Implementation — what the tool is for, its inputs and outputs, and how it does the work.
Try It — run the tool by hand with test inputs.
Tests — saved test cases that check the tool still behaves after every change. See Automated tests for custom tools.
Call history — every real call to the tool, and for AI tools what each call cost and how long it took. See Tool call history and performance.
Because a tool has a fixed name, inputs, and outputs, the steps that use it don't need to know how it works. You can improve a tool's implementation without touching the workflow, and your tests tell you whether the improvement broke anything.
For the kinds of tools you can build and how to choose between them, see AI Tools and Custom Tools.
Composing tools within a thunk
Tools can be built out of other tools:
A Custom AI Tool runs its own AI agent, with its own instructions and its own set of tools. It is the way to package a multi-step piece of AI work — "research this supplier and summarize the risks" — as a single tool that several steps reuse.
A Custom Code Tool can call other tools from its code, in a fixed order, with no AI judgment in between. See How custom code tools work.
A Tool Wrapper narrows an existing tool to one job by fixing some of its arguments. See How to build a Tool Wrapper.
A tool is never able to call itself, so composing tools can't loop back into the same tool.
Sharing tools across thunks
A thunk can export a chosen set of its tools as a library. Other thunks import that library and enable it in their Connections pane, and their AI agents call the tools as if they were built in. The importing thunk doesn't need to know how the tools work, or have access to the data behind them — the exporting thunk's owner decides what to share. This is how a central team can publish approved tools for many workflow designers. See Modular reuse of tools.
Agreeing on an interface
When several thunks need the same kind of capability but from different systems — "look up a customer", whichever CRM holds them — describe it once as an interface. A thunk can declare that it needs an interface, and whoever uses the thunk plugs in a plug-in connection that implements it. A tool built to match an interface keeps the interface's name, description, and inputs fixed, so every implementation is interchangeable. See Reuse thunk interfaces and plug-in connections.
Offering tools to AI agents outside Thunk.AI
A thunk can also publish its tools as an MCP server, so external AI assistants and agents can call them. See Publish your thunk as an MCP server for AI agents and Promote _meta arguments on MCP tools.
Working as a team
Split the work by part. One person owns a tool or library and its tests; others build the workflows that use it. A tool's tests are its contract with everyone who depends on it.
Share through libraries, not copies. Copying a tool into another thunk makes two tools to maintain. Exporting it once and importing it everywhere keeps one version.
Control who can change what. Thunk owners and admins edit a thunk and its tools; participants use it. See Users and Access Controls.
Keep an eye on shared tools in production. A shared tool's call history shows how every caller is using it, and its cost and time views show whether a change made it slower or more expensive.