Before building an AI application or agent, understand how Microsoft Foundry organizes models, tools, knowledge, and development resources. These relationships form the foundation for everything that follows.
Think of the structure as:
Foundry Resource → Project → Models + Agents + Tools + Knowledge
The Foundry resource is the underlying Azure resource and infrastructure boundary. A project lives within that resource and organizes the models, agents, tools, and knowledge used by an AI solution. The resource is the foundation; the project is the development workspace.
Microsoft Foundry provides access to generative models alongside Foundry Tools for specialized AI capabilities such as Language, Speech, Translation, and Document Intelligence. These services complement models when an application needs capabilities such as speech recognition or structured information extraction.
| Need | Typical choice |
|---|---|
| Direct model/chat interaction | OpenAI SDK |
| Agents, tools and grounding | Microsoft Foundry SDK |
| Specialized AI capability | Service-specific SDK |
| Universal HTTP integration | REST API |
Key distinction: use the OpenAI SDK when targeting a model directly; move toward the Foundry SDK when working with the broader agentic platform, including tools and grounding.
For development, Visual Studio Code with the Microsoft AI Toolkit is the recommended combination presented in the course. In the Foundry portal, Discover is primarily for finding models, tools and templates, while Build is where deployed resources are configured and tested.
Fairness • Reliability & Safety • Privacy & Security • Inclusiveness • Transparency • Accountability
These are not an afterthought: they influence grounding, prompts, guardrails, UX, evaluation, and ongoing operation of the solution.
Memory model: Resource hosts → Project organizes → Model reasons → Knowledge grounds → Tools act → Responsible AI governs.
AI agents become much more powerful when they can act on external systems, not just generate answers. Custom tools let a Foundry agent use application logic, databases, APIs, calculations, and workflows.
Prompt → Agent → function_call → App executes tool → Result → Agent → Answer
A custom function tool has a name, description, and parameters. The agent uses these definitions to determine when a function is needed and what arguments to provide.
# 1. Create the agent
agent = project_client.agents.create_version(...)
# 2. Ask the agent
response = openai_client.responses.create(
conversation=conversation.id,
input="What's the weather in Zurich?",
extra_body={"agent": agent}
)
# 3. Check whether the agent wants to use a function
for item in response.output:
if item.type == "function_call":
# YOUR application executes the function
result = call_function(item.name, item.arguments)
# Return the result to the agent
send_function_result(item.call_id, result)Key concept: the LLM does not execute your local function. It returns a function_call containing the requested function and arguments. Your application dispatches and executes it, then returns the result so the agent can continue reasoning.
| Need | Use |
|---|---|
| Local application code | Custom function |
| REST API described with OpenAPI | OpenAPI tool |
| Remote/serverless compute | Azure Functions |
| Low-code workflow | Logic Apps |
Agent = decides what to call → Application = executes it → Agent = uses the result
One prompt can trigger multiple function calls, allowing an agent to combine several operations before generating its final response.
Building an AI solution goes beyond calling a model. The focus is on creating production-ready AI applications and agents with Microsoft Foundry that can use enterprise data, interact with tools, process different content types, and collaborate to complete real tasks.
| Area | What you should understand |
|---|---|
| Generative AI apps | Build conversational applications using models, APIs, and SDKs |
| Grounding | Connect models to your own data for relevant, fact-based responses |
| Agents + tools | Let agents retrieve information and take actions |
| Multi-agent systems | Orchestrate specialized agents to collaborate on workflows |
| Multimodal AI | Process text, documents, vision, and speech |
| Production | Deploy, publish, monitor, secure, and apply responsible AI safeguards |
Exam focus: Understand not just what these capabilities do, but when and why you would use them together in an Azure AI solution.
A useful mental model for AI-103 is:
User → AI App/Agent → Model → Data + Tools → Action/Response
For more complex solutions:
User → Orchestrator → Agent A + Agent B + Agent C → Tools/Data → Result
An agent therefore isn't simply a chatbot. It combines a model's reasoning capabilities with instructions, knowledge, and tools so it can perform useful work.
The course assumes working knowledge of Python, REST APIs/SDKs, Azure fundamentals, and generative AI concepts. Hands-on practice is important: build applications in Microsoft Foundry, connect models to data, add tools to agents, experiment with multimodal inputs, and create multi-agent workflows.
Key takeaway: Think beyond prompts and models. AI-103 is about assembling the components required for an end-to-end AI solution:
Models → Grounding → Tools → Agents → Orchestration → Production
Generative AI models are powerful, but their trained knowledge is limited. Tools extend models beyond text generation, allowing them to access real-time information, take actions, ground responses in facts, extend functionality, and build intelligent workflows.
| Tool | Purpose |
|---|---|
code_interpreter |
Generate and run code for calculations and data analysis |
web_search |
Find current information on the internet |
file_search |
Search files and ground responses in specific knowledge |
function |
Call custom functions implemented by your application |
Remember: current information → web_search · uploaded/private documents → file_search · calculations/code → code_interpreter · application-specific actions → function
Tools are provided through the tools collection. The model can determine which available tool is appropriate for a request.
response = client.responses.create(
model=model_name,
input="Answer the user's request using the available tools.",
tools=[
{"type": "code_interpreter", "container": {"type": "auto"}},
{"type": "web_search"},
{"type": "file_search", "vector_store_ids": [vector_store.id]}
]
)
print(response.output_text)
Core flow: User → Responses API → Model → Tool → Result → Model → Response
For file_search, documents are stored in a vector store and prepared for semantic retrieval:
Files → Chunking → Embeddings → Vector Store → Retrieval → Model
This lets the model answer using relevant document content rather than relying only on its trained knowledge. Uploaded company policies or private documents → File Search + Vector Store.
Functions are different because the application executes the function, not the model. The model identifies the required function and returns a function-call request:
User → Model → Function Call → Application → Function → Result → Model → Response
The application executes the requested code and returns its result. This process can run in a loop when multiple tool calls are needed.
Key distinction: built-in tools extend the model with predefined capabilities; function calling connects the model to your own application logic and actions.
AI safety is no longer only about what future systems might be capable of. New reports show that people are already trying to use advanced AI for potentially harmful activities.
Anthropic says it has detected and disrupted attempts to misuse its Claude models across several areas, including cyberattacks, surveillance, influence operations and potentially dangerous biological research.
AI can make such activities easier by helping users analyze information, write code, coordinate tasks and automate parts of complex workflows. More capable AI agents could increase this effect by performing multiple steps with less human involvement.
The findings do not mean AI systems are independently launching attacks. They show a different challenge: powerful general-purpose tools can amplify the capabilities of people who misuse them.
For AI providers, businesses and governments, safeguards will increasingly need to combine technical restrictions, monitoring, security testing and human oversight.
APIs and MCP are not competing technologies—they solve different parts of the integration problem.
APIs do the actual work. They let software communicate with services, databases, and other systems. With AI applications, the model itself does not call an API; it chooses an action, while software outside the model executes it.
MCP adds a standardized layer around this process. An MCP server can expose useful actions—such as reading messages or creating tickets—while handling the underlying API calls, authentication, formats, and other implementation details.
This makes integrations easier to discover and reuse across multiple AI applications instead of rebuilding them for each one.
When to use which?
Direct APIs: Simple applications, experiments, or a small number of known operations.
MCP: Multiple AI applications sharing tools and systems.
In short, MCP does not replace APIs. It provides a common, reusable way for AI applications to access the capabilities behind them.
Original video: MCP vs API Explained: Do You Really Need MCP? (en / 17:17) - KodeKloud (YouTube)
larly relevant:
When was the lawn last fertilized? Which month was the hedge trimmed? And what work was done in the garden last autumn? Small details like these are surprisingly easy to forget.
Keeping a record of garden tasks makes it much easier to look back and plan future work. The challenge is finding a structure that is simple enough for everyday use while remaining organized over several years.
A practical approach is to organize the records hierarchically in a note-taking application:
The Garden Chronicle serves as the long-term archive, while each Garden Log contains the records for a particular year.
A simple table works well for the individual entries:
| Date | Task | Notes |
|---|---|---|
| 09 Sep 2026 | Mowed the lawn | Cutting height recorded |
| 15 Sep 2026 | Fertilized the lawn | Autumn fertilizer |
| 03 Oct 2026 | Pruned shrubs | Seasonal pruning |
The Notes column is particularly useful for recording products, quantities, plant varieties, weather conditions, or observations.
With very little effort, this creates a useful garden history that can support future planning and make recurring seasonal tasks easier to track.
Have dozens of tabs open in Brave and want to save them before closing the browser? A simple bookmark export provides an easy backup without installing extensions or running scripts.
First, press Ctrl + Shift + D in Brave. This bookmarks all tabs in the current window and places them together in a folder. Give the folder a recognizable name, such as Open Tabs Backup.
Next:
Open Brave’s Bookmark Manager by entering brave://bookmarks/ in the address bar.
Select the three-dot menu in the upper-right corner.
Choose Export bookmarks.
Select a location and save the resulting .html file.
The exported HTML preserves bookmark titles and URLs, making it useful as a portable backup. It can also be opened in a browser or imported into compatible browsers later.
One limitation is worth knowing: Brave exports the complete bookmark collection, not only the temporary folder containing your open tabs.