Agents and plugins.

A plugin supplies a capability that another node uses, such as an LLM or a set of tools. An agent node can use capabilities and intermediate results over several steps. The workflow still needs explicit inputs, usable outputs, and execution limits.

#Give a plugin a bounded job

A plugin supplies the methods, settings and return values expected by its consumer. The agent or consuming node reads the task, calls permitted tools, inspects results, then finishes or iterates within its completion and iteration controls. Repeated calls can incur charges. User code does not widen the built-in consumer's runtime authority. Test the plugin and consumer together, and check Station compatibility separately.

The plugin socket is outside the consumer’s bounded loop. Tool inputs and results cross that interface; a completion or iteration boundary exits toward retained evidence rather than automatically starting another call.

#Connect a plugin

Find the plugin type the consuming node expects and connect its plugin output to that input. Configure the plugin's provider, model, or tool settings before running the consuming node. A wire with the right type still needs an implementation that provides the expected functions.

For a Lab Skill built from a node with plugin inputs, choose those plugins in the Skill creation dialog. Supplying a plugin's name as plain text is not the same as a connected plugin instance.

#Bound an agent's work

Set the available iteration controls and give the task a clear completion condition. Check the tools it may call and the accounts those tools affect. Repeated model or API calls can create repeated charges.

Start with a narrow task and inspect progress and intermediate results. A reactive or automatically evaluated node can run again when inputs change; choose that behavior deliberately for expensive work.

#Write a reusable plugin

Follow the public user-node runtime and plugin interface expected by the consumer. Keep configuration separate from secrets. Return structured results and actionable errors so a calling agent can distinguish a failure from an empty but valid answer.

User plugins execute under user-code restrictions even when plugged into a built-in node. Do not assume the built-in node grants your code broader access to files, credentials, or backend internals.

#Choose the right sharing surface

Test the complete consumer/plugin pair before reusing it in a template or Skill. Station publishing has additional restrictions on account-backed tools, persistent memory, and custom code. Read the Station check instead of assuming that every agent workflow can become a public visitor tool unchanged.

#Treat the connection as an interface contract

Interface: connect the plugin the consumer actually supports and configure its requirements. Loop: set completion and iteration bounds; repeated calls can still create charges. Evidence: inspect real intermediate/final values and errors before reuse. A plugin wire does not grant unrestricted runtime access or universal Station compatibility.

#Checks and next steps

A plugin wire identifies the kind of connection but does not make every plugin compatible with every consumer. Inspect the expected methods, settings, required tools and returned value shape for the actual consumer/plugin pair. Test the pair together before packaging it as a Skill or template.

Iteration bounds and completion conditions limit the loop's intended behavior, not every possible cost or side effect. Several model/tool attempts can still be billable, including before a later failure. Inspect intermediates, keep required errors visible, and use Manual evaluation during controlled tests.

Connected tools do not grant user code access to backend modules or all account credentials. Station compatibility is another check, especially for account-backed services, persistent state, and custom code.