Let the outside answer

Our review workflow needs an amount from a service. Flow can multiply numbers, but the service's answer is an outside observation. We describe that boundary with a Tool.

use "./service"

pub flow main() -> Result<Int, ToolProblem<Text>> = service.lookup()

@tool pub flow lookup() -> Result<Int, Text>

Two files, two responsibilities

Open service.flow. Its declaration says that lookup takes no arguments and returns either an Int or a Text failure. It has no body: the application supplies the implementation behind it.

Open main.flow. The import use "./service" binds the module name service. The call service.lookup() reaches its public declaration.

Notice the two result types. The declaration names Result<Int, Text>. Calling it produces Result<Int, ToolProblem<Text>>, because the run must also account for a reply it cannot interpret or an invocation whose outcome is unknown. We will unpack those cases in the failure chapter. For now, returning the result intact keeps every outcome visible.

Choose an answer

Run with Reply Ok(42). The result is {"Ok":42}. Change the fixture to Declared failure and run again. You have changed what answers the call; you have not changed the program's type.

The fixture selector belongs to this browser application. A Tool declaration itself provides no credentials or permission to contact a service. The application that runs Flow owns that connection.

Predict before running

What happens with Wait for a reply? The run waits. No amount is available yet, so it cannot finish this expression. Reset the lesson and use the successful fixture for the next chapter.

Exact rules: Tools.