Sooner or later the catalog does not have the thing you need. The honest cost of that moment is not writing an API client; it is learning an authoring contract. A FluidGrids node is a small Python GraphQL service with a manifest that declares every operation and its typed fields, a schema where every operation has the identical signature, resolvers that must never raise, an Adaptive-Card form per operation, and a credential-adapter binding so the executor can inject secrets at run time. It is all learnable and none of it is interesting.
That is the second mode in the same floating widget. It is a distinct agent with its own rulebook and its own reference material on disk: one real credentialed OAuth integration to copy the credential and adapter pattern from, and one minimal three-operation node with no credentials that is the cleanest source of the copy-verbatim boilerplate. It reads the closest reference before it writes anything, which is why the output looks like the rest of the catalog instead of like generated code.
The split between what is copied and what is authored is explicit. The infrastructure files — the server, the router, the config, the container files, and the agent-tool adapter helper that is byte-identical across every node — are copied unchanged with only the name and port swapped. The real work is authored per node: the manifest as the contract, the schema, the resolvers that bind every field, the action handlers that hold the actual API logic, the client class, and the registration mutation. Crucially the scaffold includes the AI-agent adapter, so a connector produced this way is agent-callable from the moment it exists.
It also runs completely headless, and that constraint shapes the behaviour. There is nobody on the other end of the session, so a clarifying question would hang forever and you would get nothing. Instead it makes the most sensible assumption for anything you left unspecified — which operations, field names, which credential provider, defaults — proceeds, and states those assumptions in its summary so you can adjust them. A built node with reasonable guesses beats a question that never returns.
Be clear about what you are handed: a scaffold, not a deployed connector. Installing it runs the existing custom-node path — structure and manifest validation, automated tests, approval, then install into the workspace catalog — and the node-deployment backend is being re-platformed onto the per-node sandbox architecture, so treat deployment as in progress rather than done. There is also a separate server-side node-generation mutation in the workflow service that produces a manifest and code as a stored artifact; it has no UI yet, and the assistant mode is the path that actually works end to end today.
Do it yourself
Switch the assistant to Build a node, describe the integration you are missing, and take the scaffolded node package through the existing validation, review, and install path into your workspace catalog.
Search the node palette for the integration you need before building anything new.
You should see: You know whether this is a missing connector or an operation on a node you already have.
Ready to make this your story?



