A travel-planning assistant built with Foundry Agent Service needs to book a flight by calling the company's internal reservation system in real time and returning a confirmation number to the traveler. The team wants the agent to reliably invoke that API with the correct structured parameters rather than guessing from free text. What should they configure?

The correct approach is a defined function (tool) the agent can call with structured parameters, invoked by the agent service at runtime. This gives the agent a validated schema for the reservation API, lets the service execute the call when needed, and returns the real response—such as a genuine confirmation number—into the conversation. It is the mechanism built for connecting an agent to a live external system.

The option that pastes the reservation API's documentation into a longer system message is wrong because it only gives the model text to reason about; it cannot make the model actually call the endpoint, and any confirmation number it produces would be fabricated rather than real. The option that uses a fine-tuned model trained on past booking conversation transcripts is wrong because fine-tuning changes the model's conversational style and phrasing based on past transcripts, but it does not grant runtime access to call an external system. The option that increases the context window so the model can hold more conversation history is wrong because retaining more history has no bearing on whether the model can execute a real API call and return an authentic result.