9  Potpourri and Conclusion

In this conclusionary chapter, we’ll wrap up the book by covering a few other features of Microsoft Foundry that didn’t fit elsewhere (what I call “potpourri”) and I’ll show you some additional open-source tools from Microsoft that are related to agentic workloads. Lastly, I’ll be providing some best practices and considerations for designing an Azure cloud architecture that integrates well with Foundry Agents. Plus, I’ll leave you with some resources to continue your learning journey beyond this book.

9.1 Additional Features

As you may have noticed throughout this book, Microsoft Foundry has a ton of features, and new features are released regularly. In this section, I’ll briefly cover some of the features that didn’t necessarily fit into the previous chapters, but that are still important to be aware of as you design and build your agents.

9.1.1 Memory

Traditional LLM interactions are stateless by default. So, if I spin up a new instance of a model and ask it “What is my name?” it won’t know the answer because it has no memory of our previous interactions. However, if you’ve used public AI tools like ChatGPT or Claude, you may have noticed that it seems to learn a bit about you over time. It remembers the context of your previous conversations within a session, and it can even recall some information about you across sessions (e.g., your name, your preferences). This is because these tools have a form of memory that allows them to retain and recall information across interactions.

In Foundry, we can also give our Agents the ability to remember information about our previous chat session. Foundry IQ introduces memory as a managed capability that allows agents to retain and recall context across interactions. Memory in Foundry IQ supports:

  • Conversational continuity across sessions
  • User preference retention
  • Task and workflow state
  • Adaptive behavior based on historical interactions

This transforms agents from reactive prompt responders into persistent digital collaborators. Importantly, memory is governed: retention policies, isolation boundaries, and enterprise controls ensure that memory enhances intelligence without compromising security or compliance. See Figure 9.1 for a high-level illustration of how a memory store works in the context of an agent’s interactions with a user.

Figure 9.1: How a memory store recalls previous context

To add a memory store to your Agent, navigate to the Memory section of your Agent’s Playground. Click the Add button and then select + Create memory store, as shown in Figure 9.2. You can have multiple memory stores per agent, which can be useful for separating different types of information (e.g., user preferences vs. task state). Each memory store has its own configuration and retention policies.

Figure 9.2: Locating the memory capability on an Agent

Then, you can also edit the memory store, as shown in Figure 9.3. By default, the scope of the memory is at the {$userId} level, which provides per-user memory isolation without hard-coding identifiers yourself. If a user identity is not found, it will default to the caller’s Microsoft Entra token ({tenant-id}_{object-id}). You can also edit the update delay, which dictates how long to wait after inactivity to update memories.

Figure 9.3: Editing the memory store

Memory stores can be reused between different agents. So, you could have multiple agents that all reference the same memory store if you want them to share information about a given user. You can also choose to have separate memory stores for different agents if you want to keep their contexts isolated. Either way, memory is a really useful capability that can help your agents provide a more personalized and contextually relevant experience for users (that feels similar to what we experience when using AI tools like ChatGPT or Claude).

9.1.2 Evaluations

If you need to evaluate the quality and safety of your generative AI applications, the Evaluations feature in Microsoft Foundry allows you to use multiple industry standard metrics and other evaluators to assess the performance of your agents. You can use this to evaluate your agents during development and testing, and you can also set up ongoing evaluation in production to monitor for any issues or degradation in performance over time. Table 9.1 provides a list of some of the built-in evaluators that you can use to evaluate your agents.

Table 9.1: Built-in evaluators, categorized by type
Type Evaluator Purpose
General Purpose Coherence Measures logical consistency and flow of responses.
Fluency Measures natural language quality and readability.
Text Similarity Similarity AI-assisted textual similarity measurement.
F1 Score Harmonic mean of precision and recall in token overlaps between response and ground truth.
BLEU Bilingual Evaluation Understudy score for translation quality measures overlaps in n-grams between response and ground truth.
GLEU Google-BLEU variant for sentence-level assessment measures overlaps in n-grams between response and ground truth.
ROUGE Recall-Oriented Understudy for Gisting Evaluation measures overlaps in n-grams between response and ground truth.
METEOR Metric for Evaluation of Translation with Explicit Ordering measures overlaps in n-grams between response and ground truth.
RAG Retrieval Measures how effectively the system retrieves relevant information.
Document Retrieval Measures accuracy in retrieval results given ground truth.
Groundedness Measures how grounded the response is in the retrieved context. Returns a score from 1–5 using a model-based judgment.
Groundedness Pro (preview) Measures whether the response is grounded in the retrieved context using the Azure AI Content Safety service. Returns a binary pass/fail without requiring a model deployment.
Relevance Measures how relevant the response is with respect to the query.
Response Completeness (preview) Measures to what extent the response is complete (not missing critical information) with respect to the ground truth.
Risk and Safety Hate and Unfairness Identifies biased, discriminatory, or hateful content.
Sexual Identifies inappropriate sexual content.
Violence Detects violent content or incitement.
Self-Harm Detects content promoting or describing self-harm.
Protected Materials Detects unauthorized use of copyrighted or protected content.
Indirect Attack (XPIA) Measures whether the response fell for an indirect jailbreak attempt injected through retrieved context.
Code Vulnerability Identifies security issues in generated code.
Ungrounded Attributes Detects fabricated or hallucinated information inferred from user interactions.
Prohibited Actions (preview) Measures an AI agent’s ability to engage in behaviors that violate explicitly disallowed actions.
Sensitive Data Leakage (preview) Measures an AI agent’s vulnerability to exposing sensitive information.
Agent Task Adherence (preview) Measures whether the agent follows through on identified tasks according to system instructions.
Task Completion (preview) Measures whether the agent successfully completed the requested task end to end.
Intent Resolution (preview) Measures how accurately the agent identifies and addresses user intentions.
Task Navigation Efficiency Determines whether the agent’s sequence of steps matches an optimal or expected path to measure efficiency.
Tool Call Accuracy Measures the overall quality of tool calls including selection, parameter correctness, and efficiency.
Tool Selection Measures whether the agent selected the most appropriate and efficient tools for a task.
Tool Input Accuracy Validates that all tool call parameters are correct with strict criteria including grounding, type, format, completeness, and appropriateness.
Tool Output Utilization Measures whether the agent correctly interprets and uses tool outputs contextually in responses and subsequent calls.
Tool Call Success Evaluates whether all tool calls executed successfully without technical failures.

To test out the Evaluations feature, navigate to the Evaluations screen from the left-hand menu of the Foundry portal under Build. Click the Create button, as shown in Figure 9.4, to set up a new evaluation.

Figure 9.4: Locating the Evaluations screen

The next screen will allow you to pick whether to evaluate a model, an agent, or a dataset. Then, you can either upload a set of input test prompts or have synthetic data generated for you. Lastly, you’ll pick the criteria on which to form the evaluation. This includes a wide variety of standard evaluation metrics such as task adherence, tool call accuracy, fluency, etc. This is shown in Figure 9.5. If you were to run the evaluation, you would get a detailed report that breaks down the performance of your agent across the different metrics and test cases. This can be really helpful for identifying areas of strength and weakness in your agent’s performance, and for tracking improvements over time as you make changes to your agent’s design, the underlying model it uses, or its instructions.

Figure 9.5: Configuring the evaluation process for an agent using synthetic data

Back on the Evaluations page, under Evaluator catalog, you will see a list of built-in evaluators that you can use to evaluate your agents. These include a wide variety of purposes, from operational evaluations (e.g., “Did the agent follow the instructions and pick the right tool?”) and safety evaluations (e.g., “Is the agent generating vulnerable code?”) to functional evaluations (e.g., “How well does this agent handle customer service situations?”). You can also create your own custom evaluators if you have specific criteria that you want to assess that are not covered by the built-in options. When you click on one, as shown in Figure 9.6, you can read more about what the evaluator does.

Figure 9.6: The Evaluator catalog shows the details of a built-in evaluator

9.1.3 Red Teaming

Lastly, to automate the identification of safety and security risks, Foundry provides a Red team feature that simulates adversarial attacks on your agents to identify vulnerabilities. More specifically, it probes for novel risks (both content and security-related) by attempting to cause your AI system to misbehave. You can see your Red teams under the Build section of the Foundry portal under Evaluations > Red teams. You can create a new Red team by clicking the Create button, and then you can configure the parameters of the Red team, such as which agent to target, what types of attacks to simulate, and how often to run the tests.

This is an automated capability designed to stress-test AI systems for safety risks before and after deployment. It systematically generates adversarial prompts and evaluates whether a model or agent behaves unsafely, violates policies, leaks information, or performs prohibited actions. This feature supports three major scenarios:

  • Pre-deployment testing to identify vulnerabilities before releasing an AI application
  • Continuous post-deployment monitoring, where red teaming evaluations can be scheduled periodically
  • Agentic AI evaluations, specifically targeting AI agents that use tools and execute tasks in semi-autonomous environments

This supports multiple automated attack techniques designed to probe different failure modes. Some examples include:

  • Base64: Encodes harmful instructions to bypass filters
  • Flip: Alters prompts to manipulate model behavior (e.g., “How do I rob a bank?” → “knab a bor I od woH?”)
  • Indirect Jailbreak: Attempts to circumvent safeguards through indirect instructions

The Microsoft Foundry Python SDK provides a programmatic interface to create and manage Red teams, which can be useful for integrating red teaming into your CI/CD pipelines or for more advanced configurations. The following is an example of how to create a Red team using the Python SDK.

In this example, we create a Red team with a set of built-in safety evaluators and criteria that will automatically assess the model’s responses for prohibited actions, task adherence, and sensitive data leakage.

# pip install "azure-ai-projects>=2.0.0" 

import os
from azure.identity import DefaultAzureCredential
from azure.ai.projects import AIProjectClient

## Example: https://<account_name>.openai.azure.com
endpoint = os.environ["AZURE_AI_PROJECT_ENDPOINT"]

## Example: gpt-5.4-mini
model_name = os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"]

with DefaultAzureCredential() as credential:
    with AIProjectClient(
      endpoint=endpoint,
      credential=credential
      ) as project_client:
        client = project_client.get_openai_client()

        ## Create a red team with built-in safety evaluators
        red_team = client.evals.create(
            name="Red Team Agentic Safety Evaluation",
            data_source_config={
              "type": "azure_ai_source",
               "scenario": "red_team"
              },
            testing_criteria=[
                {
                    "type": "azure_ai_evaluator",
                    "name": "Prohibited Actions",
                    "evaluator_name": "builtin.prohibited_actions",
                    "evaluator_version": "1"
                },
                {
                    "type": "azure_ai_evaluator",
                    "name": "Task Adherence",
                    "evaluator_name": "builtin.task_adherence",
                    "evaluator_version": "1",
                    "initialization_parameters": {
                      "deployment_name": model_name
                      },
                },
                {
                    "type": "azure_ai_evaluator",
                    "name": "Sensitive Data Leakage",
                    "evaluator_name": "builtin.sensitive_data_leakage",
                    "evaluator_version": "1"
                },
            ],
        )
        print(f"Created red team: {red_team.id}")

Then, we create a taxonomy to define the attack strategies we want to use in our red teaming run.

from azure.ai.projects.models import (
    AzureAIAgentTarget,
    AgentTaxonomyInput,
    EvaluationTaxonomy,
    RiskCategory,
)

## Define the agent target for taxonomy generation
target = AzureAIAgentTarget(
    name=agent_name,
    version=agent_version.version,
)

## Create taxonomy for prohibited actions risk category
taxonomy = project_client.beta.evaluation_taxonomies.create(
    name=agent_name,
    body=EvaluationTaxonomy(
        description="Taxonomy for red teaming run",
        taxonomy_input=AgentTaxonomyInput(
            risk_categories=[RiskCategory.PROHIBITED_ACTIONS],
            target=target
        ),
    )
)
taxonomy_file_id = taxonomy.id
print(f"Created taxonomy: {taxonomy_file_id}")

Finally, we can launch a Red team run against our agent using the defined taxonomy of attack strategies.

## Create a red team run with attack strategies
eval_run = client.evals.runs.create(
    eval_id=red_team.id,
    name="Red Team Agent Safety Eval Run",
    data_source={
        "type": "azure_ai_red_team",
        "item_generation_params": {
            "type": "red_team_taxonomy",
            "attack_strategies": ["Flip", "Base64", "IndirectJailbreak"],
            "num_turns": 5,
            "source": {"type": "file_id", "id": taxonomy_file_id},
        },
        "target": target.as_dict(),
    },
)
print(f"Created run: {eval_run.id}, status: {eval_run.status}")

Once completed, evaluation results are logged within the Foundry project. This provides a report of an model or agent’s failure to adhere to safety guidelines such as prohibited actions, task adherence, or sensitive data leakage. You can use these insights to identify and remediate vulnerabilities in your AI systems before they are exploited in the real world.

The output reporting provides multiple outputs including overall attack success rates, breakdown by risk category and by attack strategy complexity, row-level attack-response pairs, full conversation transcripts for deeper investigation, and more.

As AI systems become more autonomous and integrated with external tools, automated red teaming provides a practical mechanism for identifying risks before they impact users or business operations.

To learn more about the Red team feature and how to use it, check out the Microsoft Learn documentation: https://learn.microsoft.com/en-us/azure/foundry/concepts/ai-red-teaming-agent.

9.1.4 Batch Jobs

Usually, when we’re talking about using LLMs, we think about real-time interactions, such as a user asking a question and the model generating a response. However, there are also many use cases where you might want to use LLMs in a batch processing mode asynchronously. For example, you might want to analyze a large corpus of documents, generate summaries for a set of articles, or perform data transformation on a big dataset.

The Batch Jobs feature in Microsoft Foundry allows you to run LLM workloads in a batch processing mode, which can be more efficient and cost-effective for certain types of tasks that don’t require real-time responses.

To create a batch job, navigate to the Models screen from the left-hand menu of the Foundry portal under Build and click the Batch jobs tab, as shown in Figure 9.7. Then, you can click the Create batch job button to set up a new batch job.

Figure 9.7: Locating the Batch Jobs feature under Models

Just like when we were fine-tuning a model, batch jobs also use .jsonl formatted files. Each line of the file represents a separate request to the model, and you can include any input that you would normally send to the model in a real-time interaction. The difference is that instead of sending these requests one at a time, you can send them all at once as part of a batch job. This allows you to process large volumes of data more efficiently.

{
  "custom_id": "task-0",
  "method": "POST",
  "url": "/v1/chat/completions",
  "body": {
    "model": "gpt-5.1",
    "messages": [
      {
        "role": "system",
        "content": "You are an AI assistant that helps data scientists learn about machine learning."
      },
      {
        "role": "user",
        "content": "What is a convolutional neural network?"
      }
    ]
  }
}
{
  "custom_id": "task-1",
  "method": "POST",
  "url": "/v1/chat/completions",
  "body": {
    "model": "gpt-5.1",
    "messages": [
      {
        "role": "system",
        "content": "You are an AI assistant that helps data scientists learn about machine learning."
      },
      {
        "role": "user",
        "content": "What is a transformer model?"
      }
    ]
  }
}
{
  "custom_id": "task-2",
  "method": "POST",
  "url": "/v1/chat/completions",
  "body": {
    "model": "gpt-5.1",
    "messages": [
      {
        "role": "system",
        "content": "You are an AI assistant that helps data scientists learn about machine learning."
      },
      {
        "role": "user",
        "content": "What is the difference between supervised and unsupervised learning?"
      }
    ]
  }
}

There’s not much to configure on the Create a batch job screen, as the main thing is just to upload your .jsonl file, which defines everything, and then kick off the job. Once the job is running, you can monitor its progress and view the results once it’s complete. See Figure 9.8 for an example of what the batch job creation screen looks like when the sample .jsonl file from the accompanying GitHub repo under data/ch09/tiny_batch_data.jsonl is uploaded.

Figure 9.8: Uploading .jsonl data to create a batch job

9.1.5 AI Services

For the majority of this book, we’ve been focused on LLMs, but there are certainly many other AI models that can be deployed and used within Microsoft Foundry. In addition to LLMs, Foundry also supports a variety of other AI services, such as text-to-speech, translation, language detection, personally identifiable information (PII) detection, content understanding, and more. These services can be used in conjunction with your agents to provide additional capabilities and enhance the overall user experience.

As shown in Figure 9.9, you can find the AI Services options under the Models section of the Foundry portal. From there, you can explore the different services that are available and how to use them. Clicking on any of these services will open up a Playground for you to test out the service and see how it works.

Tip

If you click the circle beside the service name, it will show you the Target URI and Key to call the service programmatically.

For example, let’s click on one of the newer AI Services: Azure Speech - Voice Live.

Figure 9.9: Locating the AI Services options under Models

In the Playground for the Azure Speech - Voice Live service, shown in Figure 9.10, you can scroll through a few sample configurations such as customer service, language learning, or casual chat. Then, after clicking the Start button, you can have a live conversation with the model using your microphone, and it will respond to you in real-time using text-to-speech. Try tweaking the response instructions, temperature, or even the voice that’s being used. You can get some pretty comical (or weird) voice agents this way.

This is a really fun way to experience the capabilities of these AI services and to see how they can be used in different scenarios. You could even integrate this service into your agents (by clicking the Add to agent button) to enable voice interactions for users, which could be especially useful for accessibility or for use cases where typing is not ideal, like in a mobile app.

Figure 9.10: Testing out the Voice Live AI service in a Playground

Try out a few of the AI Services to get a feel for what other AI capabilities exist outside the realm of LLMs. You might find some that are really useful for your agents or for other applications you’ll need for future projects.

9.3 Best Practices in Azure

As we’ve traversed through the various chapters of this book, we’ve touched on different technical considerations for building agents with Microsoft Foundry. However, I wanted to take a moment here at the end to summarize some of the best practices for cloud architecture that you can use as a starting point when designing your own Azure architecture for Foundry agents.

9.3.1 Infrastructure and Configuration Management

When designing an Azure-based architecture for your AI use cases, treat your infrastructure as software from day one. Use Azure Resource Manager (ARM) templates, Bicep, or Terraform to define your infrastructure as code. This allows you to version control your infrastructure, easily replicate it across environments, and avoid the painful “works in dev, broken in prod” problem that plagues manually provisioned systems. For Foundry-specific resources (model deployments, agent configurations, and knowledge base connections) consider keeping these definitions alongside your application code in source control so that infrastructure changes go through the same review process as code changes. An example Bicep snippet for deploying a Foundry resource and related components is shown here.

// Base Foundry resource
resource aiFoundry 'Microsoft.CognitiveServices/accounts@2025-06-01' = {
  name: aiFoundryName
  location: location
  kind: 'AIServices'
  ...
}

// Deploy a Project
resource aiProject 'Microsoft.CognitiveServices/accounts/projects@2025-06-01' = {
  name: aiProjectName
  parent: aiFoundry
  location: location
  ...
}

// Deploy a Model to the Project
resource modelDeployment 'Microsoft.CognitiveServices/accounts/deployments@2025-06-01'= {
  parent: aiFoundry
  name: 'gpt-4.1-mini'
  ...
}

Microsoft provides multiple Bicep and Terraform templates on its GitHub repo: https://github.com/microsoft-foundry/foundry-samples/tree/main/infrastructure/infrastructure-setup-bicep.

9.3.2 Security and Identity

AI agents can be surprisingly powerful actors in your organization, and with that power comes great responsibility (and risk). Thus, controlling what they can access and do is paramount. My recommendation is to leverage Azure’s native security and identity services such as Microsoft Entra ID for authentication and Azure Key Vault for secrets management. When connecting an Agent to downstream services, always use managed identities to avoid storing credentials. In other words, as a general rule, never embed API keys or connection strings directly in your agent’s instructions or tool definitions. These will inevitably end up in logs, conversation histories, and screenshots. When you use managed identities, your agents can authenticate to downstream services without any credentials ever being stored.

Also, role-based access controls (RBAC) can be applied on each resource to ensure that only authorized users can perform specific actions. For example, as shown in Figure 9.16, you can set up RBAC for your Foundry resources separately from the RBAC for your Azure resources (e.g., the Subscription and Resource Group). This allows you to have fine-grained control over who can access and manage your Foundry agents and projects, which is especially important in larger organizations with multiple teams and stakeholders involved in AI initiatives.

Figure 9.16: Role-based access controls for Foundry resources
Tip

Follow the principle of least privilege rigorously. That is, an agent that only needs to read from a database should never be granted write access, even if it’s “more convenient.”

If you’re using the Microsoft Agent Governance Toolkit discussed earlier in this chapter, the privilege ring model provides a concrete framework for operationalizing this principle across your agent fleet.

9.3.3 Observability

You can’t improve what you can’t see. Use Azure Monitor and Application Insights to set up end-to-end observability for your agents. At a minimum, you should be tracking latency per tool call, token consumption per session, error rates by agent and by model, and the ratio of successful task completions to abandoned sessions. From the Foundry portal, you can see an Agent’s telemetry in the Monitor tab, as shown in Figure 9.17. This provides a high-level overview of the agent’s performance and can help you identify any issues or bottlenecks in your agent’s interactions.

Figure 9.17: Viewing the Monitor tab of an Agent

Then, if you click on the Open in Azure Monitor button, it will redirect you to the Application Insights service, where you can access the detailed monitoring information for the Foundry Project. Foundry’s native tracing integrates with Application Insights automatically, so you can correlate a user-facing error all the way back to the specific tool call or model response that caused it. See Figure 9.18 for what the Application Insights screen looks like for a Foundry Project. This level of observability is crucial for maintaining the reliability and performance of your agents, especially as they grow in complexity and scale.

Figure 9.18: Viewing the Application Insights service for the Foundry Project

Spend some time clicking around the Application Insights pages to see the different types of telemetry that are available and how to use them to analyze your agent’s behavior. Beyond standard telemetry, consider instrumenting your agents with semantic logging, capturing not just that a tool was called, but what the agent was trying to accomplish when it called it. This makes post-incident analysis and prompt tuning significantly easier.

9.3.4 Scalability and Cost Management

Design for scalability by leaning on Azure’s managed services. These include Azure Kubernetes Service (AKS) for containerized workloads, Azure App Service for web-facing components, and Azure Service Bus or Event Grid for decoupling high-throughput agent pipelines. However, resist the urge to over-engineer up front. Start with simpler, fully managed services and migrate to more complex orchestration only when you have real workload data justifying the operational overhead.

Cost management is often an afterthought with AI workloads, but it shouldn’t be. Token costs compound quickly at full scale. Set up Azure Cost Management budgets and alerts scoped to your Foundry resources from the very beginning. Tag all Foundry-related resources consistently (e.g., workload: foundry-agents, env: prod) so you can slice cost reports by agent, by team, or by environment without guesswork.

As shown in Figure 9.19, you can view the Cost Management screen in the Azure portal for your Foundry-related resources. This view allows you to monitor and analyze your spending patterns. This will help you identify any unexpected cost spikes and optimize your agent’s performance and cost-efficiency over time.

Figure 9.19: Viewing the Cost Management screen for the Foundry-related resources

9.3.5 Reference Architectures

Lastly, I’d like to show a couple of reference architectures of varying complexity that illustrate how you might integrate Foundry agents into an Azure-based cloud estate. These are not prescriptive templates, but rather examples to spark ideas for how you can design your own architecture based on your specific use case and constraints.

Remember that one main benefit of Microsoft Foundry is that you get a simple model or agent endpoint that you can easily integrate into your apps. So, in many cases, your architecture might be as simple as a web app that calls out to Foundry for AI capabilities. However, as your needs grow, you might find it beneficial to introduce additional Azure services for orchestration, integration, or security.

Figure 9.20 shows a basic architecture where the ingestion and processing of enterprise data is orchestrated by Azure Data Factory and lands in an Azure Storage Account (data lake). Then, that data is indexed using Azure AI Search and stored in a Cosmos DB vector store. Then, an Agent deployed in Foundry can communicate with the data via a knowledge base (for a RAG-based approach). Then, the Foundry agent is integrated into a web application that users will access. While simple, this is a pretty common architecture pattern for an enterprise AI application, and it leverages a number of standard Azure data services in conjunction with Foundry to provide a robust and scalable solution.

Figure 9.20: A basic, mostly serverless architecture for AI

Next, let’s get a bit more technical with networking and security. In Figure 9.21, we have a similar architecture to the previous one, but this time it’s deployed within a Virtual Network (VNet) with private endpoints for all services. The Foundry agent is deployed in a private subnet with no outbound internet access, and it communicates with the data services over private endpoints. This architecture provides an additional layer of security by isolating all resources within a VNet and eliminating any public internet exposure. You’ll likely see this type of architecture in more security-conscious organizations or for use cases that involve sensitive data. It does add some complexity in terms of setup and maintenance, but it can be worth it for the enhanced security posture.

Figure 9.21: A more sophisticated architecture with private networking

These examples are just two of many possible architectures for integrating Foundry agents into an Azure-based cloud environment. For more reference architectures related to Microsoft Foundry, check out the Azure Architecture Center: https://learn.microsoft.com/en-us/azure/architecture/browse/?products=microsoft-foundry.

9.4 Final Thoughts

I suppose all good things must come to an end, but the party has just begun! As we conclude this journey through Microsoft Foundry, remember that AI is not just about technology. It’s about empowering people to accomplish more. The patterns, practices, and architectures presented in this book provide a foundation, but your creativity and domain expertise will ultimately determine success. I encourage you to experiment, iterate, and share your learnings with the community. The future of enterprise AI is being formed now.

Key takeaways:

  1. Start Simple: Begin with a focused use case and expand gradually
  2. Security First: Build security and compliance in from the start
  3. Measure Everything: Use observability to understand and improve
  4. Iterate Rapidly: Collect feedback and continuously refine
  5. Scale Thoughtfully: Plan for growth but don’t over-engineer initially
  6. Stay Current: AI technology evolves rapidly; keep learning

As AI continues to evolve, Microsoft Foundry will evolve with it, providing new capabilities, models, and tools. The fundamentals of good engineering will remain: clear requirements, solid architecture, comprehensive testing, and continuous improvement.

I encourage you to experiment, build, and share your learnings with the community. Be sure to show off what you’ve built online.

Next Steps:

Thank you for reading and, as always, stay curious…