Skip to content

Clarify tool-action I/O vs runtime-owned effects in docs #243

@mikehostetler

Description

@mikehostetler

Summary

jido_ai is where many developers first encounter Jido.Action modules as tools, so this package is a key place to explain the practical effect boundary.

Today the docs show tool actions being executed in ReAct loops, but they do not say plainly enough that tool actions often do I/O because the model needs the result back in the same reasoning loop.

Why this matters

Developers can read the wider ecosystem docs and come away unsure about questions like:

  • should tool actions stay pure?
  • is HTTP/LLM/database I/O in run/2 acceptable for tools?
  • when should a step be executed as a tool action versus handed off to runtime-owned effects/signals/directives?

This comes up especially in workflows like:

  • fetch context via HTTP
  • call model/tool
  • deliver or emit final result elsewhere

The first two often need inline results, while the last may be better modeled as a runtime-owned effect.

Proposed clarification

Add ecosystem-consistent wording along these lines:

In jido_ai, tool actions are allowed to be effectful. They often perform I/O because the model needs their results back immediately. The purity boundary lives in the agent strategy/runtime orchestration layer, not necessarily inside each tool action.

And add a short decision rule:

  • use an effectful tool action when the model or workflow needs the result now
  • use directives/signals/runtime integrations when the workflow has already decided on an outbound effect and wants the runtime to own delivery/execution

Suggested doc touchpoints

  • README.md
  • guides/user/tool_calling_with_actions.md
  • guides/user/first_react_agent.md
  • guides/developer/architecture_and_runtime_flow.md

Acceptance criteria

  • User-facing docs explicitly say tool actions may do I/O.
  • Tool-calling docs explain why effectful tools are normal in ReAct-style loops.
  • Developer docs explicitly connect this back to the strategy/runtime purity boundary.
  • At least one guide includes a concrete example of "tool needs data now" vs "runtime owns outbound delivery".

Related tracker:

  • tracker issue will be opened in agentjido/jido

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions