Are marketplace module commands callable as agent-node tools? (module action_id resolves to None in station-v0.68)

Question

Building an agent node workflow over an installed marketplace module ( marcofgv/freelancer com ), I hit this: the agent node's tools are dropped and never execute. In station v0.68 , agent tool schemas and the agent execute() in workflow engine.py both resolve a tool via R.resolve node({"action id": aid}) . That registry lists the built in providers (slack, stripe, github, gsheets, twilio, webhook, …). An installed module's action id — e.g. freelancer com.search projects — returns None , so agent tool schemas drops it ( if integ is None: continue ) and execute() returns unknown action id . Net: an agent node whose tools[] are marketplace module commands can't call any of them. But agent nodes spec.md says the opposite is intended: " tools[] entries are action id s resolvable via R.resolve node / the module registry — the same identifiers the palette already exposes." the effect row: "one integration/ module action: integ = R.resolve node(n) ". So: is driving a marketplace module from an agent node supported? If yes, what wires the module registry into resolve node — an install/register step I'm missing, or Studio side wiring not present in a headless station? If it's built in integrations only for now, that would be worth noting in the spec. Context: this is what blocks minting a dag run receipt for an agent workflow over a marketplace module — the module tools resolve at the static effect path but not at the agent path.

sami.benchaalia · Accepted Answer

Yes — a marketplace module's commands are usable as agent node tools today, and they inherit the full governance path. How it works under the hood: when a module is installed, each of its manifest commands is registered as a first class integration action ( register module integrations builds an Integration from the command — arg fields come straight from the command's input schema — and stores it in the action registry, keyed by the command's action id ). An agent node resolves its granted tools through that same registry ( resolve node(action id) → agent tool schemas ), so: 1. Add the module command's action id to the agent node's tools allowlist. The agent automatically gets a tool schema derived from the command's input schema (arg names + provider/verb + action class), so it can't drift from what the handler actually accepts. 2. Every proposed call goes through the agent's per action gate — the exact same one static effect nodes use: allowlist check → live execution policy → spend cap → team quorum/approval → signed railcall agent receipt.v1 . A module command an agent invokes is governed identically to one you place by hand. 3. It executes via the module's sandboxed handler using the client's own vault (the same credential resolution as a normal module node) — the agent never sees the secret. So the pattern is: compose the agent node in the canvas, list the module command(s) in its tool allowlist, and the agent can call them within the caps you set. One thing that is NOT shipped yet: a module packaging its own agent node — i.e. an "agent module" that ships a pre wired agent + toolset as a single installable unit. That's a planned follow on; today you wire the agent node yourself and point it at the module's commands. If that packaged form is what you're after, say so on this thread and we'll fold it into the agent modules design. (Shipped in the agent nodes work, station v0.72+.)

vectortrendstech · Answer

Thanks Sami — and confirmed end to end on station v0.78 with our own listing: after installing marcofgv/freelancer com, its commands register as first class actions and plan workflow enumerates them into an agent node's blast radius. Two practical notes for anyone wiring this today: (1) the agent's tool allowlist must use the canonical installed module action id — slug + underscore, e.g. marcofgv freelancer com place bid; the dotted module id form resolves to None silently. (2) action class derives from each command's mode (read → reversible, anything else → external send); side effects alone is not read, so declare mode per command or your money moving commands plan as reversible and the blast radius under reports. With both fixed, our workflow's plan shows place bid as irreversible and Ed25519 signs the root. And yes — the packaged form is exactly what we're after: an agent module that ships the pre wired agent + toolset as one installable, so a buyer gets scout → draft → airlocked place bid as a unit instead of wiring the agent node by hand. Count marcofgv/freelancer daily bidder in as a first candidate for the agent modules design.

Are marketplace module commands callable as agent-node tools? (module action_id resolves to None in station-v0.68)

2 replies