Context:
Currently, the agent loop unpacks the JSON payload (**block.input) only to repack it (lambda **kw) in the dispatch map.
Proposal:
Since block.input is already a dictionary, passing it directly as a payload simplifies the data flow:
# Current
"read_file": lambda **kw: run_read(kw["path"], kw.get("limit"))
output = handler(**block.input)
# Proposed
"read_file": lambda d: run_read(d["path"], d.get("limit"))
output = handler(block.input)Pros:
Resilience to Hallucinations: If the LLM generates extra parameters (e.g., {"path": "a.txt", "reason": "hallucinated"}), the dict approach safely ignores them. The **kwargs approach risks throwing unexpected keyword argument errors if not carefully handled.
Simpler Data Flow: Eliminates redundant unpack/repack cycles.
Trade-offs:
Function Coupling: Ties the dispatch lambda to a dictionary object rather than clean, standard Python kwargs.
Type Validation: Makes it slightly harder to drop in Pydantic models for strict type checking (e.g., automatically converting a string "100" to an int 100).If strict type validation (like Pydantic) isn't planned for this specific layer, the payload-driven approach feels much more robust against unpredictable LLM outputs.Would love to hear the maintainers' thoughts on this architectural trade-off. I'm happy to submit a PR if this aligns with the project's direction!
Context:
Currently, the agent loop unpacks the JSON payload (**block.input) only to repack it (lambda **kw) in the dispatch map.
Proposal:
Since block.input is already a dictionary, passing it directly as a payload simplifies the data flow:
Pros:
Resilience to Hallucinations: If the LLM generates extra parameters (e.g., {"path": "a.txt", "reason": "hallucinated"}), the dict approach safely ignores them. The **kwargs approach risks throwing unexpected keyword argument errors if not carefully handled.
Simpler Data Flow: Eliminates redundant unpack/repack cycles.
Trade-offs:
Function Coupling: Ties the dispatch lambda to a dictionary object rather than clean, standard Python kwargs.
Type Validation: Makes it slightly harder to drop in Pydantic models for strict type checking (e.g., automatically converting a string "100" to an int 100).If strict type validation (like Pydantic) isn't planned for this specific layer, the payload-driven approach feels much more robust against unpredictable LLM outputs.Would love to hear the maintainers' thoughts on this architectural trade-off. I'm happy to submit a PR if this aligns with the project's direction!