intern allison!
Ā·Intern @ Genspark

Builder deep-dive: Node tool/agent bindings get silently wiped on chat updates (and what's actually happening under the hood)

Spent the last few days stress-testing a 15-step Career-Workflow skill in the Builder and found something worth sharing with everyone building multi-node workflows.

*The trigger*
I manually assigned a Tool + Custom Agent to a node in the Canvas, then asked the Builder chat to update my skill files. After the update, the Canvas binding was gone. Reproduced it consistently.

*What's really going on*
The Builder chat and the Canvas state are NOT bidirectionally synced. The chat agent treats skill.md as the single source of truth and rewrites it on every update — but skill.md doesn't carry node metadata (tool/agent bindings live only in the Canvas graph). So every chat-driven file update nulls your manual node assignments.

*The bigger realization*
Digging into how the OpenCode runner actually executes the workflow: node types and agent names (e.g. "Ask Genspark", "OmniSource Researcher", "URL Metadata", "Webpage Screenshot") appear to be semantically inert at runtime. The runner reads skill.md as plain prose and does everything itself via gsk CLI calls (gsk search / gsk crawl). It never mapped my named agent nodes to dedicated execution logic.

Evidence from my test runs:
• Dedup was reported but didn't actually happen (an item flagged as "duplicate removed" still showed up in the final list)
• Counts didn't reconcile across steps (no real state between nodes)
• Screenshot fallback nodes never executed ("n/a" in both runs)
• The whole workflow effectively ran as one monolithic LLM prose pass, not typed node execution

*Practical takeaway for builders*
If you rely on per-node tool/agent binding, you currently can't steer it reliably — Canvas edits get overwritten by chat, and the runner ignores the node semantics anyway. Two options:
1. Build fully in Canvas and never touch the chat again (fragile — one accidental chat update kills it)
2. Accept the runner is essentially a gsk-driven prose executor, and write your fallback chains (render_js → screenshot) and dedup logic explicitly as prose instructions in skill.md

I've gone with option 2 and it's far more robust.

Curious whether others have hit the Canvas-wipe-on-chat-update behavior, and whether anyone has gotten genuine typed node execution (not gsk prose fallback) to work. Would love to compare notes.

1