Scaffolding an agent with the sd, vlm, or skills toolset produces a file that crashes the moment you run it. The generated agent calls a method that doesn't exist, so it fails at construction with an AttributeError before doing anything.
Three of the twelve available toolsets are affected. The other nine are fine.
The cause is a naming assumption in the generator: it assumes every toolset exposes register_<name>_tools(). Two of them register their tools inside an init method instead, and one uses a different name.
Found while working on #3316; kept separate because it's a naming bug in the generator, not part of that issue's host-attribute contract.
🔍 Technical details
src/gaia/agents/builder/template.py emits self.register_<KNOWN_TOOLS-key>_tools() for each selected tool. Checked against origin/main:
| Key |
Generated call |
Reality |
sd |
register_sd_tools() |
doesn't exist — SDToolsMixin registers inside init_sd() |
vlm |
register_vlm_tools() |
doesn't exist — VLMToolsMixin registers inside init_vlm() |
skills |
register_skills_tools() |
actual name is register_skill_library_tools() (skill_library_tools.py:207) |
Verified: grep -c "def register_sd_tools" src/gaia/sd/mixin.py → 0; same for register_vlm_tools in src/gaia/vlm/mixin.py.
sd/vlm need more than a rename — their init methods take configuration and couple setup to registration, so the generator has to emit an init_sd(...)/init_vlm(...) call with sensible defaults rather than a bare registrar call.
A regression test enumerating KNOWN_TOOLS and asserting every generated variant constructs would have caught this and would prevent the next one. #3316 adds exactly that test but excludes these three entries with a comment pointing here — un-excluding them is the natural acceptance check for this issue.
Scaffolding an agent with the
sd,vlm, orskillstoolset produces a file that crashes the moment you run it. The generated agent calls a method that doesn't exist, so it fails at construction with anAttributeErrorbefore doing anything.Three of the twelve available toolsets are affected. The other nine are fine.
The cause is a naming assumption in the generator: it assumes every toolset exposes
register_<name>_tools(). Two of them register their tools inside an init method instead, and one uses a different name.Found while working on #3316; kept separate because it's a naming bug in the generator, not part of that issue's host-attribute contract.
🔍 Technical details
src/gaia/agents/builder/template.pyemitsself.register_<KNOWN_TOOLS-key>_tools()for each selected tool. Checked againstorigin/main:sdregister_sd_tools()SDToolsMixinregisters insideinit_sd()vlmregister_vlm_tools()VLMToolsMixinregisters insideinit_vlm()skillsregister_skills_tools()register_skill_library_tools()(skill_library_tools.py:207)Verified:
grep -c "def register_sd_tools" src/gaia/sd/mixin.py→ 0; same forregister_vlm_toolsinsrc/gaia/vlm/mixin.py.sd/vlmneed more than a rename — their init methods take configuration and couple setup to registration, so the generator has to emit aninit_sd(...)/init_vlm(...)call with sensible defaults rather than a bare registrar call.A regression test enumerating
KNOWN_TOOLSand asserting every generated variant constructs would have caught this and would prevent the next one. #3316 adds exactly that test but excludes these three entries with a comment pointing here — un-excluding them is the natural acceptance check for this issue.