Context
During the vision/ folder removal (see #24-adjacent PR on branch chore/prune-vision-folder), the dead-code inventory confirmed vision/tools.py's 14 langchain_core.StructuredTool functions were never wired into the SDK's ToolRegistry after the LangChain → nullain.tools migration (agent/bridge_tools.py). That surface is now deleted.
requirements.txt's own comment (pre-dating this cleanup) flagged two other langchain_core consumers alongside vision/tools.py, using the same phrase — "camadas sem caller de produção" (layers without a production caller):
agent/sandbox_tools.py — uses langchain_core.StructuredToolagent/zuckpay_tools.py — uses langchain_core.RunnableConfig (flagged as "só anotação de tipo", i.e. type-annotation-only, likely a different case)
What needs checking
- Is
agent/sandbox_tools.py's StructuredTool usage actually wired into any live tool-registration path (mirroring the vision/tools.py/build_vision_tools investigation), or is it the same kind of orphaned LangChain-era leftover?
- Is
agent/zuckpay_tools.py's RunnableConfig usage load-bearing (real callers passing it) or just an unused type annotation?
- If both turn out dead/unnecessary, the
langchain>=1.0.0,<2.0.0 pin in requirements.txt can be dropped entirely — the remaining langchain_core transitive dependency would come from langchain-mcp-adapters instead, which is still genuinely in use (agent/bridge.py, agent/external_mcp.py).
Why a separate task
Flagged explicitly out of scope for the vision/ removal — different blast radius (sandbox_tools.py is the code-interpreter tool surface, actively used), and deserves its own focused audit rather than being bundled into a vision-specific cleanup.
Context
During the
vision/folder removal (see #24-adjacent PR on branchchore/prune-vision-folder), the dead-code inventory confirmedvision/tools.py's 14langchain_core.StructuredToolfunctions were never wired into the SDK'sToolRegistryafter the LangChain →nullain.toolsmigration (agent/bridge_tools.py). That surface is now deleted.requirements.txt's own comment (pre-dating this cleanup) flagged two otherlangchain_coreconsumers alongsidevision/tools.py, using the same phrase — "camadas sem caller de produção" (layers without a production caller):agent/sandbox_tools.py— useslangchain_core.StructuredToolagent/zuckpay_tools.py— useslangchain_core.RunnableConfig(flagged as "só anotação de tipo", i.e. type-annotation-only, likely a different case)What needs checking
agent/sandbox_tools.py'sStructuredToolusage actually wired into any live tool-registration path (mirroring thevision/tools.py/build_vision_toolsinvestigation), or is it the same kind of orphaned LangChain-era leftover?agent/zuckpay_tools.py'sRunnableConfigusage load-bearing (real callers passing it) or just an unused type annotation?langchain>=1.0.0,<2.0.0pin inrequirements.txtcan be dropped entirely — the remaininglangchain_coretransitive dependency would come fromlangchain-mcp-adaptersinstead, which is still genuinely in use (agent/bridge.py,agent/external_mcp.py).Why a separate task
Flagged explicitly out of scope for the
vision/removal — different blast radius (sandbox_tools.pyis the code-interpreter tool surface, actively used), and deserves its own focused audit rather than being bundled into a vision-specific cleanup.