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.

A menu search leads to a draft basket and a human review. — Keep searching, drafting, and approving as distinct steps.

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.

Build checkpoint

Open the Workflow Lab and follow the practice above. Each lab explains its inputs, its actual logic, and its limits. Save your observations below; your check-ins and reflection remain in Product Academy.

For an AI-assisted code change, download the lab bundle from the lab page. Ask your coding assistant to explain the relevant function first, change one behavior, and add one test that could fail. Compare the result with your prediction.

Save your experiment and check-in

Record your prediction, what you tried, what happened, and the evidence for your conclusion. Name one thing you can now do independently and one uncertainty to revisit.

Key takeaways

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