Watch it work

AdvancedLabCustom toolsCapabilitiesIntegrationsWire your AI Workforce to act · Step 3 of 8

Estimated time · about 11 minutes|Required · The WeatherCheck capability and GetForecast tool saved on your AI Employee

Outcomes

✓Test a custom tool in the place it will actually run

✓Read the Explanation view to tell a mistimed trigger from a wrong value

✓Isolate a failing call outside the platform and re-import the fix

✓Prove the whole flow end to end before a client sees it

Where a capability becomes reliable

Custom tools are tested in the place they work, which is a live conversation. A tool that behaves on a settings screen has proven nothing; what matters is whether it fires at the right moment, with the right values, in front of someone who is trying to book a job.

You are here: Business App, inside your test account.

Two directions need proving, and only testing both tells you anything. A tool that fires on everything looks identical to a tool that works, right up until it interrupts an indoor booking to talk about rain.

Labtest both directions

Go to your employee's Chat, in a fresh incognito session.

1. 1.Book an outdoor job: "Can someone clean my gutters Thursday?" The forecast should be checked before the booking is confirmed.
2. 2.Book an indoor job next. The weather tool should stay quiet.
3. 3.Ask for an outdoor job with no day named. The employee should ask for the date rather than guessing one.

Outdoor bookings get a forecast check, indoor bookings do not, and a missing date is asked for rather than invented.

Read what it actually did

When an answer surprises you, look at what happened rather than what was said. Open the message in Conversations and select Explanation: it shows which capability ran, which tool it called, and what came back.

That view separates the two failures that look the same from the outside:

• The tool never fired. The trigger is the fix. Tighten the when-to-use lines in the prompt, including what the capability should not be used for, and test the indoor booking again.
• The tool fired and sent the wrong thing. The parameter description is the fix. Say where the value comes from and what format it takes.

There is a third case worth naming, because it belongs to neither. If the values look right in the conversation and the API is still rejecting the call, the call itself is what needs work.

Isolate a failing call

Take the same method, URL, headers, and parameter values the tool would send, and run that exact call again on its own, outside the platform. The result tells you which side to fix:

• It succeeds outside. The tool sent something different from what you just ran. Compare the two and the difference is your answer.
• It fails the same way outside. The API is rejecting a correct-looking call, so the fix is in the call: a parameter it requires, a header it expects, or an account setting on their side.

Adjust it until it works outside, then import the corrected cURL again. That is the one moment a tool like Postman earns its place in this work: isolating a broken call, never starting the build.

Run the whole thing

Labone conversation, start to finish

Go to Chat, in one more fresh session.

1. 1.Ask for an outdoor job, give your details, and take the offered time.
2. 2.Confirm the forecast was consulted, in Explanation.
3. 3.Confirm the booking is on the calendar.
4. 4.Confirm the contact is in the CRM.
5. 5.Read the conversation once more as a customer would experience it.

Three results from one conversation, and the weather check reads as good service rather than machinery: mentioned only when it changes the plan.

Try it now

Time that final run. A checked forecast, a booked job, and a clean CRM record in under a minute, with nobody involved, is the story this build tells a client.

Knowledge Check

Three quick questions on testing both directions, reading Explanation, and isolating a failing call.

Congratulations, you completed this step!

Wire your AI Workforce to act · Step 3 of 8

Keep learning›