Give each tool a clear contract

A tool name is not an integration

Your assistant wants to search a menu. Give it a narrow capability such as search_menu, with a query, dietary requirement, and budget. Define what comes back: item IDs, source IDs, and bounded price information.

A tool contract describes inputs, outputs, errors, and side effects. Searching reads data. Drafting a cart changes a proposal. Submitting an order changes the world. Keep these capabilities separate so the application can enforce different permissions.

Check your understanding

Which tool design best separates risk?

Validate before and after execution

A model might supply a string where a number is expected, an unknown item ID, or an unsupported option. Validate tool arguments in code before execution. Validate results before treating them as evidence.

In the Workflow Lab, the draft contains one real fixture item ID and a quantity. Selecting an unavailable item must fail. A request to a nonexistent tool should not be guessed into a different action. Return an explicit error and let the workflow decide what to do next.

Check your understanding

Match the failure to the recovery.

Design errors as part of the interface

Distinguish invalid input, temporary unavailability, and a forbidden action. They need different recovery paths: ask for a correction, retry within a limit, or stop.

Write a small contract before introducing a framework. LangGraph’s workflow guide illustrates orchestration patterns, but the product still owns argument validation and action boundaries.

Check your understanding

Name three things a draft-cart tool contract should specify.

Key takeaways

• Define tool behavior before wiring it into a model.
• Validate both arguments and returned results.
• Separate read-only tools from consequential actions.