Implement an Agentic Solution
Agent anatomy
An agent in Azure AI Foundry Agent Service is a model plus instructions, tools and optional knowledge. Runtime objects are: thread (durable conversation state, stored service-side), message (user or assistant content, files), and run (one execution of the agent against a thread). You create a thread once, append messages, start runs, and poll until the run reaches a terminal status. Persist thread and run IDs yourself - the service does not hand you a session.
Tools
- Function calling - the model returns a tool-call request; your application executes the function and submits the output back so the run can continue. The loop, not the model, does the work.
- Code interpreter - sandboxed Python with file upload/download, good for data analysis and chart generation.
- File search - grounds answers in a vector store of uploaded documents.
- Azure AI Search / Bing grounding / OpenAPI 3.0 / MCP tools connect enterprise indexes, web data and custom HTTP APIs described by a spec.
Orchestration
For complex work, use connected agents (a primary agent delegates to specialists) or deterministic code that calls several agents in sequence. Keep a human-in-the-loop approval step before any tool with side effects such as writing to a database or sending mail.
Traps and rule of thumb
Questions imply the agent executes your functions - it does not. They also conflate a thread with a chat history you must rebuild, or assume file search reaches the open web. Rule of thumb: the model plans, your code enforces - every consequential action needs validation, least-privilege credentials and trace logging.