Voice-enabled generative AI is essentially a two-way conversion pipeline: speech → text lets an application understand spoken input, while text → speech turns generated responses back into audio. Azure AI Foundry provides specialized models for both inference tasks.
Know which model solves which problem:
| Task | Model type | Data flow |
|---|---|---|
| Transcription | Speech-to-text | Audio → Text |
| Speech synthesis | Text-to-speech (TTS) | Text → Audio |
A transcription model such as GPT-4o-mini-transcribe accepts audio and returns text. A TTS model such as GPT-4o-mini-tts performs the reverse and can also follow instructions affecting characteristics such as tone.
The implementation pattern is straightforward: deploy the appropriate model in Foundry → create an authenticated Azure OpenAI client → call the corresponding audio API → handle text or binary audio output. Streaming is useful for TTS because audio bytes can be consumed as they arrive rather than waiting for the complete response.
# Speech → Text
with open("speech.wav", "rb") as audio:
text = client.audio.transcriptions.create(
model="gpt-4o-mini-transcribe",
file=audio
)
# Text → Speech
with client.audio.speech.with_streaming_response.create(
model="gpt-4o-mini-tts",
voice="alloy",
input="Hello from Azure AI"
) as audio:
audio.stream_to_file("speech.mp3")
Remember the direction: Transcribe = audio in, text out. TTS = text in, audio out. The audio side is binary data, so applications must correctly read input files or stream/write generated audio.
An LLM can identify entities or PII itself—but an agent can instead delegate these tasks to a specialized Azure Language tool through MCP. This separates agent reasoning from deterministic NLP processing.
Architecture: Prompt → Agent → discover/select MCP tool → Azure Language → tool result → final response
Azure Language MCP Server exposes Azure Language capabilities as tools that an agent can dynamically discover and invoke. Core capabilities include PII detection, language detection, and Named Entity Recognition (NER); additional Language capabilities are also exposed through MCP.
The important distinction is:
Agent/LLM: reasons about the request and chooses an appropriate tool.
MCP: standardizes tool discovery and invocation.
Azure Language: performs the specialized NLP operation.
Tool selection is not hard-coded. The MCP server advertises available tools and their descriptions; the agent matches the user's intent to those descriptions. Good agent instructions further guide when Azure Language should be used.
# Agent is already configured with Azure Language MCP
response = openai_client.responses.create(
input="Find and redact PII in this text...",
extra_body={"agent": {"name": "text-agent"}}
)
print(response.output_text)
Behind this simple call:
Agent
└─ discovers MCP tools
└─ selects PII tool
└─ Azure Language analyzes text
└─ result returns to Agent
Watch for approval: MCP tool calls can require user/application approval. Either handle the approval request in code or configure appropriate tools for automatic approval.
Remember: MCP exposes tools; the agent selects them; Azure Language executes the NLP task.
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.
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
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.