Connect a Local FastAPI Service to an AI Agent Platform to Save and Read Back Issues

You are given a small Python codebase built on FastAPI that runs on your own machine. The interviewing company's product is a hosted platform for building conversational AI agents that talk with end users. Connect the two so that, during a conversation, the agent can: - **save an issue** that the user reports, and - **read the user's past issues back** to them when they ask. This is a live coding exercise. First get a working round trip from the hosted agent to your local service and back for both operations, then harden it. ```hint Who can reach whom The platform runs in the cloud and your service listens on `localhost`. Work out what has to be true before the first tool call can reach your code at all, and what that implies about who else can call the same URL. ``` ```hint Design for the model, not for a form The model decides when to call a tool and fills in the arguments from what the user said. Sort the values you need into those the model can reliably supply and those your server should establish on its own. ``` ### Constraints and Clarifications - Assume the platform lets you register custom tools (functions) that the agent's language model can call mid-conversation. Each tool has a name, a natural-language description, a schema for its arguments, and a URL that the platform calls over HTTPS with the arguments it extracted. The tool's response goes back to the model, which then answers the user. - Assume the conversation can be spoken (for example, a phone call), so anything the agent reads back has to be short enough to say aloud. - If the codebase has no storage for issues yet, a simple local store (in memory or SQLite) is acceptable. - The platform's exact request and response formats are not given here. Keep your code's dependence on them in one place. ### Clarifying Questions - What does the provided codebase already contain: an issue model, a storage layer, existing routes, tests? What has to be written from scratch? - What exactly does the platform send to a tool URL (arguments only, or also call metadata such as a call identifier or the caller's number), and what response format does it expect back? - How is "the user" identified, so that past issues are read back to the right person and to nobody else? - What makes up an issue: a free-text description only, or also fields such as category or priority? - Does the platform retry a tool call after a timeout or an error, and how long does it wait for a response? ### What a Strong Answer Covers - A working path from the hosted platform to the local service, and a demonstrated round trip for both saving and reading back - Tool names, descriptions and argument schemas that lead the model to call the right tool with the right arguments, plus agent instructions for when to call each one - FastAPI endpoints with validated inputs, persistence for issues, and a single adapter for the platform's request format - Server-side identification of the user, with no way for one user to hear another user's issues - Read-back responses shaped for speech: ordered, bounded in count, with a sensible empty case - Failure handling: authenticating requests, duplicate saves caused by retries, slow or failing endpoints, and what the agent says when a tool fails - Testing the endpoints locally before wiring them to the platform ### Follow-up Questions - How would you move from a tunnel on your laptop to a deployment the agent can depend on in production? - How would you let the user update or close an existing issue during the conversation, and make sure the agent acts on the right one? - If the issue store is slow or unavailable mid-conversation, what should the tool return and what should the agent say? - What would you log or measure to tell whether the agent calls the tools at the right moments?