There is often a need to share and reuse logic from a thunk. The scenarios include:
A single user is building multiple thunk variants or versions to experiment with different process flows. But they want to share some common tools or content.
A single user has a complex cross-functional process that they want to break up into multiple workflow thunks. One workflow does initial processing and then sends requests to a second workflow.
A team of users wants to reuse and leverage each other's work, composing logic into a larger overall workflow project.
A central IT team wants to publish approved AI tools or content folders for use by a team of workflow designers.
To enable these scenarios, thunks need both an "export-as-library" mechanism and an "import library" mechanism.
Export tool library
Any subset of the tools defined in a thunk can be exported as a reusable tool library. Search over each content folders is also exposed as an AI search tool. The ability to submit new workflow requests is also exposed as an AI tool (so that another AI agent can choose to use this capability). The owner of the exporting thunk controls which subset of these tools should be exported.
Access control for an exported thunk follows the same rules as general access control. For example, if I am a user of thunk A, then if I build another Thunk B, I can import the library and use that AI tool without needing to know how exactly it works or even have access to the underlying data. All that matters is that the owner or admins of Thunk A chose to export it as a shareable library.
Import tool library
A user account may have access to many imported tool libraries. However, all of them are disabled by default within any particular thunk created by the user. The thunk owner/designer needs to explicitly choose which imported tool libraries to enable for each thunk. Some of this configuration may happen automatically during the planning process, if the planning AI agent detects that specific imported tool libraries are necessary for the work at hand.
How To
Once you've decided to export a thunk as a library, you'll need to configure how external callers authenticate and connect to it. Here's where to find what you need.
API Keys are now in two places (they're the same keys):
Run → Inbound Requests → API Channel → API Keys — for the workflow API
Admin → Export via MCP → MCP page — for the MCP server
Choosing which to use — the rubric:
Use Case | Method |
Call Thunk from an AI assistant (Claude, etc.) | Export MCP |
Call Thunk from traditional software/code | Inbound API (structured workflow requests only) |
Send unstructured input | Email or Webhook (uses its own auth built in) |
A couple of notes:
If you create an API key and don't see it on the other page, try refreshing — it's the same key underneath and should appear in both places.
API keys are only shown once at creation time (standard security practice), then hidden. Make sure to copy it right away!
