Build a Tool-Using Weather Assistant

# Build a Tool-Using Weather Assistant Design an API-driven language-model workflow that answers a current-weather question for a city. The model may plan or select a tool, but live weather must come from an authorized data source and the final answer must remain grounded in that result. ### Constraints & Assumptions - Do not ask the language model to invent current weather from pretrained knowledge. - API credentials stay server-side and are never placed in prompts or logs. - The system should expose uncertainty and source time rather than hidden internal reasoning. ### Clarifying Questions to Ask - Which weather provider and fields are authorized? - How is a city disambiguated? - What should happen when the tool or model is unavailable? ```hint Use structured tool calls Let the model request a typed weather operation; validate the arguments and execute it outside the model. ``` ### What a Strong Answer Covers - Tool schema, argument validation, city resolution, and authorization. - Separation of model planning, deterministic execution, and grounded response synthesis. - Timeouts, retries, caching, provenance, and prompt-injection boundaries. - Evaluation, observability, user-visible failure, and privacy. ### Follow-up Questions 1. How would you answer a forecast question rather than current conditions? 2. How would you prevent tool output from injecting new instructions?