The standard way to give an agent capabilities is to give it your credentials and an outbound network path, then hope the prompt holds. FluidGrids splits those two things apart at the architecture level: the part that reasons and the part that acts are different processes with different privileges, and only one of them can reach your systems.
A tool exists because a node says so. Almost every package in the catalog declares that it supports adapter mode, marks its adapter output type as an agent tool, and ships a supply-tool operation. Supplying a tool returns a configuration whose parameter schema is generated from that operation's real manifest input fields, alongside the actual operation name and node type. There is no second tool registry to keep in sync: the same manifest that renders the configuration form in the builder is the manifest that describes the tool to the model. Sixty-nine node packages declare themselves agent tools today.
The reasoning loop deliberately lives in the executor, not in the agent. The executor calls the agent node's stateless plan step with the message history and the tool schemas; if the model asks for tool calls, the executor runs each one through the normal credentialed node path, appends the observations, and calls plan step again — repeating until the agent returns a final answer or the iteration cap is reached. The agent node never calls a peer node. Its sandbox receives the chat-model configuration and nothing else, which is why an authored prompt cannot talk a tool into doing something the executor would not have done anyway.
What that buys you is ordinary operational visibility. Each round records which tool ran, with what arguments, and what came back, and the accumulated steps land in the node output together with the token count and the iteration count. The iteration cap defaults to ten. A use-tools switch collapses the whole loop to one plain completion when you want a single model call. The agent's sandbox lease is extended each round so a genuinely slow multi-step loop does not expire halfway through. And the composability prize is the workflow tool: another entire workflow, with its own credentials and its own run history, becomes one tool the agent may invoke.
The builder makes the wiring honest too. Adapter ports render as diamond connectors beneath a node, each typed and filtered by node kind, with a picker that only offers compatible sub-nodes — a memory package physically cannot be attached to the tool port, and sub-nodes cannot be dragged into ordinary data edges. Two things are not there yet and we will not pretend otherwise: agent steps are logged and returned in the node output rather than streamed live into the UI, and there is no MCP endpoint yet for an agent outside FluidGrids to call these same tools.
Do it yourself
Give an agent real capabilities without giving it your credentials — attach connector nodes to the tool port, run it, and read the per-step trace the executor recorded.
Add the AI agent node to the canvas and attach a chat-model sub-node to its required Chat Model port.
You should see: Typed diamond adapter ports appear beneath the agent; the chat model is the only credential the agent itself receives.
Ready to make this your story?
