After Build 2025—and the flood of announcements across Copilot, Copilot Studio, Foundry, and Fabric—I found myself stepping back and trying to make sense of what was actually happening.

What struck me was that we were moving beyond the days of picking a single tool and trying to use it for everything. Instead, we were starting to see a more mature ecosystem emerge—one where you could choose the right tool for the job, and more importantly, start connecting them together.

With emerging protocols like MCP and A2A, it felt like these previously separate parts of the Microsoft AI ecosystem were beginning to integrate into something more cohesive.

A high-level map started to form in my head.

And I managed to get down what I thought was a pretty solid representation of the Microsoft AI ecosystem.

At the time, the model made sense:

• Experiences at the top
• Agents emerging as a new application layer
• Data and integration underneath
• Platform capabilities powering everything

It reflected what we were building.

Then Ignite happened

And with it, something that I think is genuinely significant:

The introduction of the “IQ Layer”

• Work IQ
• Fabric IQ
• Foundry IQ

Microsoft is formalising something many of us have been feeling for a while:

Intelligence is becoming a first-class architectural concept.

A set of cross-cutting intelligence capabilities that span:

• Human context (Work IQ) — people, meetings, emails, conversations
• Data context (Fabric IQ) — structured, semantic, and real-time enterprise data
• Execution intelligence (Foundry IQ) — models, tools, memory, and orchestration

So now I’m rethinking the diagram

The question I’ve been wrestling with is this:

Where does the IQ layer actually sit?

Is it:

Option 1 — A layer in the stack?

Something that sits between data and agents?

This is intuitive, clean and familiar… using layers as we have done for many years.

It makes sense when calling out all the components in a smaller piece of architecture.

But… it also undersells what IQ is trying to be.

It makes intelligence look like just another capability in the stack.

Option 2 — A cross-cutting layer over the entire Microsoft Cloud?

Something that wraps the ecosystem?

This feels closer to the intent.

It positions the IQ layer as the thing that turns all the other layers into something smarter.

It reflects:

• Agents are becoming orchestrators, not the intelligence itself
• Data platforms are becoming semantic, not just storage
• Applications are becoming entry points into intelligence, not logic containers

Why this matters

How this is represented shapes how people think about how their solutions hang together.

If IQ is “just another layer”, you’ll build differently
than if IQ is “the thing that powers everything”.

My current leaning

Right now, for the workshop I’m running this week… I’m using both.

• The IQ layer at the top to introduce the concepts and focus on the new capabilities
• IQ Layer sitting over integration and knowledge when I start looking at subsets of the ecosystem as they ralate in individual projects and more directly in application architecture diagrams.

I’m keen for feedback (the reason for this post):

How are you thinking about the IQ layer?
Where would you place it in the architecture?
What have I missed that should be included ?

Let me start with a pattern I keep running into.

You’re deep into delivery — maybe building an AI system, maybe scaling one — and the team is moving well. Then, right before you’re ready to ship, the governance checkpoint arrives. A compliance review. A risk board. A stack of late-stage concerns that nobody surfaced earlier because nobody was in the room earlier.

Progress stalls. Trust between builders and gatekeepers frays. Timelines slip.

And here’s the thing: this isn’t a one-off.

The problem isn’t that governance people are difficult, and it isn’t that delivery teams don’t care about risk.

It’s that governance is still treated as a gate — something that lives outside the flow of work, applied after the fact, rather than woven into how we build and operate systems from the start.

We’ve seen this movie before

The lineage matters here, because it shows we already know how to solve this kind of problem.

DevOps emerged because dev and operations/infra teams were at war. Devs threw code over the wall; ops threw it back. The fix was continuous delivery and shared ownership of the entire lifecycle. The outcome was faster, more reliable software.

DevSecOps emerged because security kept arriving too late. Teams would build for months and then hit a penetration test or security review that blew up their timeline. The fix was shifting security left — embedding it into the pipeline, making it part of everyday delivery. The outcome was safer software without killing velocity.

In both cases, the pattern was the same:

A critical concern that was being treated as an external checkpoint got pulled into the continuous flow of delivery.

And in both cases, people worried it would slow teams down. In practice, the opposite happened. Automation and shared ownership reduced late-stage surprises — and accelerated delivery.

Now look at governance.

Same story. New decade.

Governance is still being thrown over the fence.

And with AI, that doesn’t work.

DevGovOps — what I mean by it

Here’s the crisp version:

DevGovOps is the practice of embedding governance, risk, and compliance directly into the development and operational lifecycle of AI systems.

Governance, in this framing, is:

• Not a review board
• Not a checklist
• Not a single control

It lives in the execution loop.

The fix is to embed governance into the lifecycle.
The outcome is trusted AI at scale.

Or put another way:

DevOps gave us speed.
DevSecOps gave us safety.
DevGovOps gives us trust.

Why AI makes this urgent

You might reasonably ask: governance has always existed — why does it need its own “‑Ops” moment now?

Because AI systems fail differently.

Traditional software systems are largely deterministic. You test them, you deploy them, and if the tests pass, you have reasonable confidence they’ll behave as expected.

AI systems are probabilistic.

• Behaviour evolves
• Risk emerges at runtime
• A system that “passed” pre‑deployment can drift out of acceptable bounds weeks or months later

You can’t define exact expected outcomes. You have to define acceptable ranges of behaviour — and continuously verify that the system stays within them.

A governance model built around a single pre‑deployment review is structurally inadequate for this.

If your approach is “pause everything for a big review before go‑live, then hope for the best”, you’re not governing AI — you’re ignoring risk after day one.

The implication is uncomfortable but clear:

Governance for AI systems has to be continuous, automated, and embedded into runtime — not treated as a one‑off gate.

If you don’t bring risk, governance, security, and infrastructure teams on the journey, you never get to production.

What this might look like

This is not a finished framework. It’s an early articulation, grounded in patterns I’ve seen work (and fail) in our project deliveries.

Design‑time: shift‑left governance

• Threat modelling for AI systems
• Explicitly defining acceptable behavioural ranges
• Defining agent capabilities and boundaries before code exists

Build‑time: governance as code

• Policies embedded directly into prompts, system messages, and agent schemas
• Infrastructure‑as‑code enforcing guardrails by default
• CI/CD checks that validate governance constraints — not just unit tests

Test‑time: continuous evaluation

• Automated evaluation pipelines
• Hallucination testing, safety testing, prompt‑injection scenarios
• Regression testing for prompts, agents, and workflows (because prompts are code now)

Runtime: guardrails and enforcement

• Real‑time restrictions on outputs and actions
• Human‑in‑the‑loop escalation enforced via the orchestrator — not left to the model
• Controls that assume failure is inevitable, not exceptional

Identity & permissions: agents as identities

• Agents treated like first‑class identities
• Least‑privilege by default
• Every tool added increases the attack surface and must be justified

Observability & ops: continuous governance

• Monitoring drift, quality, and risk signals
• Feeding those signals back into the system
• Cost and usage anomalies treated as governance signals, not just ops metrics

None of these ideas are radical on their own.

The argument for DevGovOps is that they only work when treated as one coherent system — enforced via architecture and automation rather than process and paperwork.

What this is (and isn’t)

A few important boundaries.

• This is early thinking, not a finished methodology.
• It’s a pattern I keep seeing, a name I’m putting on it, and a hypothesis about where delivery needs to go.
• I’m certain there are blind spots.

The trade‑off I’m most wary of is bureaucracy‑by‑another‑name. If DevGovOps turns into more forms, more YAML, and more friction, it has failed. The goal is for lightweight, automated, continuous governance to replace heavyweight, manual gates — not to add more ceremony.

And yes, governance overlaps with security — but it’s broader:

• Regulatory compliance
• Data sovereignty
• Ethical use
• Auditability
• Trust and explainability

DevSecOps brought security into the pipeline.
DevGovOps is about bringing the rest of governance in as well.

What’s next

My goal isn’t to convince everyone — it’s to see where this resonates, where it breaks down, and what I’m missing.

If this mirrors pain you’re feeling in delivery, I’d love to hear from you.
If you think this is misguided, even better — tell me why.

DevGovOps only makes sense as a conversation we start earlier.

So let’s start it.

• Adam

I’ve spent the past few years implementing AI solutions that deliver measurable business value across government agencies, educational institutions and healthcare organizations.

This session shares the reality of enterprise AI development beyond the hype - the real-world benefits you can expect, which use cases are genuinely transforming operations, the shiny paths that lead to complexity (and often failure), several well-trodden paths to success and the hard-learned lessons that only come from navigating complex organizational challenges. Leave armed with practical strategies to accelerate your own AI journey and the hard-earned wisdom that will dramatically increase your odds of AI success.

I’ve spent the past few years implementing AI solutions that deliver measurable business value across government agencies, educational institutions and healthcare organizations.

This session shares the reality of enterprise AI development beyond the hype - the real-world benefits you can expect, which use cases are genuinely transforming operations, the shiny paths that lead to complexity (and often failure), several well-trodden paths to success and the hard-learned lessons that only come from navigating complex organizational challenges. Leave armed with practical strategies to accelerate your own AI journey and the hard-earned wisdom that will dramatically increase your odds of AI success.

This is a (slightly more pollished) version of what popped into my head to explain to a group of 9 year old’s why astronomy keeps me up at night.

My mother’s mother’s mother was Mary Holt. She passed when I was young…. But I used to call her Ga-Ga.

I think about Ga-Ga a lot, and what she saw in her life. When Ga-Ga was born, the telephone had just been invented, and the Wright brothers had yet to invent the aeroplane. When she was born the world was large. To get a photo or a person from Sydney to London they had to be put on a ship and endure 45 days at sea. If I had told Ga-Ga’s parents that one-day people would fly through the sky, they would have thought I was joking. If I had told them that we would take metal tubes and put 500 people in them and that these 200 tonne vehicles would fly through the sky at 800km per hour and take people from London to Sydney in 26 hours, they would have thought I was mad. If I pointed to the moon and told Mary’s dad that his daughter would watch men walking on the moon, he would never have believed me … and, as for nearly everyone having a magic mirror in their pocket that lets them see and talk to people on the other side of the world…. he’d have thought I’d stolen that from a fairy tale.

The 747, the Apollo missions and the smart phone are all appreciated in today’s context as important scientific and technological advances, but in the context of someone looking from 1900 they are unbelievable impossibilities.

In one lifetime, GaGa saw impossibilities from science fiction and fairy tales come to life.

Astronomy is about imagination, science, exploration and discovery.

I don’t have one particular field of astronomy that I find the most fascinating. Rather it is the exploration, the innovation and the discovery that inspires me. I sat transfixed with my daughter as we watched the Curiosity Rover’s seven minutes of terror. I was overjoyed when Ingenuity successfully made its first flight. I am constantly amazed as new astronomical discoveries are published like the first isolated black hole to be discovered in interstellar space.

What I love about Astronomy is exploring the big dark holes in our current understanding of how the Universe works, and the potential impossibilities that those tunnels may lead to. Could a better understanding of relativity and the nature of the fabric of the universe enable faster than light travel? What will a better understanding of black holes and dark energy yield? Will we discover life beyond our solar system? The more I study Astronomy, the more opportunities for amazing discoveries I find.

The promise of Astronomy is tomorrow’s everyday impossibilities.

It’s a privilege to be able to participate in that journey.

In this session we will look at some of the real world solutions utilising these emerging technologies: you will get an understanding of the core use cases, learn how to get started with the tech, and find out about the pitfalls to avoid when building solutions with drones and Artificial Intelligence.

Containers - The secret to shipping cloud workloads by on Scribd

I was very happy when I got asked today to do a quick 10 minute presentation on ‘Where are we at with drones’.

Rather than just deliver it once I thought I’d capture some thoughts here.

eSmart Systems - Using drones for power line inspection

Maintenance of electrical grids is not only time consuming and costly, but it can also be very dangerous. By developing a connected drone that uses AI and cognitive services from Microsoft Azure, utility companies can reduce blackouts and inspect power lines more safely.

Microsoft FarmBeats -Uses drones, AI and IOT Edge to increase farm productivity

Microsoft FarmBeats aims to enable farmers to increase farm productivity and reduce costs by enabling data-driven farming.

A new partnership between Microsoft and leading drone maker DJI builds on the work both companies are doing with data and agriculture that could make it easier and more affordable for farmers to quickly get the information they need to make crucial decisions about soil moisture and temperature, pesticides and fertilizer. Hours and days spent walking or driving the fields to try to detect problems can be eliminated. Since 2011, farmer Sean Stratman has grown kale, cauliflower, broccoli and squash in Carnation, Washington. Then, a few years ago, he added a new crop to his bounty: knowledge, using drones and the intelligent edge to get near-real-time information about issues like soil moisture and pests. It’s the kind of information that is not only helping him, but could benefit farmers around the world. Source:

Links: More reading on FarmBeats

Project Premonition - Using drones to fight infectious diseases

Emerging infectious diseases such as Zika, Ebola, Chikungunya and MERS are dangerous and unpredictable. Public health organizations need data as early as possible to predict disease spread and plan responses. Yet early data is very difficult to obtain, because it must be proactively collected from potential disease sources in the environment. Researchers estimate between 60 and 75% of emerging infectious diseases originate from animals, which are very difficult to monitor.

Project Premonition aims to detect pathogens before they cause outbreaks — by turning mosquitoes into devices that collect data from animals in the environment.

It does this by

• Finding mosquito hotspots by drone
• Collecting mosquitos with robots
• Detecting pathogens by gene sequencing

Full Article available here More Info here

Teaching Drones to Aid Search and Rescue efforts via Cognitive Services

InDro Robotics, a drone operating outfit based in Salt Spring Island British Columbia, recently connected with Microsoft to explore how they could better enable their drones for search and rescue efforts.

Leveraging Custom Vision Cognitive Service and other Azure services, including IoT Hub, InDro Robotics developers can now successfully equip their drones to:

• Identify objects in large bodies of water, such as life vests, boats, etc. as well as determine the severity of the findings
• Recognize emergency situations and notify control stations immediately, before assigning to a rescue squad
• Establish communication between boats, rescue squads and the control stations. The infrastructure supports permanent storage and per-device authentication

Full article available here

More info

If you are interested in other use cases or info on drones I keep a scratch pad on drone tech in my FAQs collection on drones.

If you are doing something awesome with Drones, AI and Azure please reach out. I would love to chat !

Pipelines are great as the allow you to automate your builds and deployments so you spend less time with the nuts and bolts, and more time being creative.

The materials put together by the Azure DevOps team are fantastic and cover a very broad range of topics.

You can get them here https://www.azuredevopslabs.com.

Demo Scripts (In-Progress)

Here is an overview of what I covered on the day and some basic notes I use for when I demo the day (to save me looking up the complete docs).

Tip: After you have followed the step by step instructions - see if you can complete the task again just following my demo script notes.

Exercise 1a: Enabling Continuous Integration with Azure Pipelines

Source: https://www.azuredevopslabs.com/labs/azuredevops/continuousintegration/

Exercise 1b: Configuring Builds as Code with YAML in Azure Pipelines

Source: https://www.azuredevopslabs.com/labs/azuredevops/yaml/

Task 1: Setting up Azure resources

1. Disable the CI trigger for the default build definition. Edit

   Triggers

   Enabled

   Save

Task 2: Adding a YAML build definition

1. Repos | Files | New File | ‘azure-pipelines.yml’

   Azure DevOps will automatically create a definition when you add this file to root of repo.

2. Add the yaml below and commit.

    steps:
    - script: echo hello world
   

3. Go to Pipelines

   Build

   Start the build

   View the last build step.

Task 3: Crafting sophisticated YAML definitions

You can even export existing build definitions as YAML if you would prefer to manage them in code.

1. Builds

   PartsUnlimitedE2E

   Edit

   View YAML

   Copy to clipboard

2. Open our ‘azure-pipelines.yml’ and paste in contents. Commit changes

   Note: In the comment blog: The SymbolPath reference is coincidental (it’s a literal needed for the build), but the BuildPlatform and BuildConfguration variables will play a role later.

3. Pipelines | Build | Open the new build to follow its progress. It will be successful but report there were no tests - there should have been. we will work out the problem.
4. Build | Logs tab | Test Assemblies task Note that there is a warning that the test assembly pattern didn’t find any matches. Upon closer inspection, it appears that it was expecting a build variable for BuildConfiguration to be available, but since it wasn’t, the platform simply used the text as-is. This was something we probably should have expected given the warnings in the YAML.
5. Edit build | Variables | Add |

   • “BuildPlatform”

     “any cpu”

   • “BuildConfiguration”

     “release”

   • Check the ‘Settable at queue time’ option for each

6. Triggers tab

   Note that you can override the YAML settings and configure CI like web-based builds

7. Save and Queue
8. Check the tests. All good.

Exercise #2 Embracing Continuous Delivery with Azure Pipelines

Source: https://www.azuredevopslabs.com/labs/azuredevops/continuousdeployment/

Task 1 Setting up Azure Resources

1. Create a SQL Database (if you haven’t already made it)

     database name: partsunlimited
     source: blank database
     server name: <yourname>-partsunlimited
   

   2.Create a web app (if you haven’t already made it)

     app name: <yourname>-partsunlimited-qa
     resource group & subscription: same as previous
     app service plan: accept the defaults
     OS: Windows
     App Insights: Off
   

Task 2: Creating a continuous release to the QA state

• open a new browser tab for Azure DevOps https://dev.azure.com/YOURACCOUNT/Parts%20Unlimited.

• Navigate to Pipelines

  Releases

• Delete the existing PartsUnlimitedE2E release pipeline
• Create a new release pipeline

  template: Azure App Service Deployment
  default stage: QA
  pipeline name: PUL-CICD
  artifact: Build | PartsUnlimitedE2E
  QA environment task | select QA web app
  

• Turn on CI trigger
• Add a build branch trigger > “The build pipeline’s default branch”
• Save

Task 3: Configuring the Azure app services for CD

1. Open the SQL Database - get the db connection strings
2. Copy the ADO.NET string to your clipboard.
3. Update username and password in the connection string with SQL credentials
4. Open the QA app service | Application Settings | Connection Strings

   DefaultConnectionString: <paste in the connectionstring>
   

5. Click Save
6. Repeat for Prod web app

Task 4: Invoking a CD release to QA

1. Open Azure Devops Repos tab in a new browser tab
2. Edit PartsUnlimited-aspnet45/src/PartsUnlimitedWebsite/Views/Shared/_Layout.cshtml.

   //add v2.0 text after the image
   <img src="/images/unlimited_logo.png" >v2.0
   

3. Commit changes
4. Open the build that is kicked off > follow until completion
5. Open the release > follow it until completion
6. Navigate to the QA Site > .azurewebsites.net
7. Check that it now says ‘v2.0’ after the image

Task5: Creating a gated release to the production stage

We are including both automated quality gates as well as a manual approver gate. We will make it our policy that the QA deployment cannot be considered a success until all critical bugs have been resolved.

1. Open the Release pipeline. Clone the QA stage.
2. Apply post-deployment considitions on QA gate
   • Enable the Gates option
   • Change ‘Delay before evaluation’ to 0
   • Add ‘Query Work Items’ Deployment gates

   • Query > Shared Queries

     Critical Bugs

   • Evuation options > Time between re-evaluation of gates to 5.
3. Rename ‘Copy of QA’ to Prod
4. Add Pre-deployment approvals > add yourself as an Approver
5. Click the Prod job > change the app service name to be the Prod web app
6. Save the pipeline
7. Edit PartsUnlimited-aspnet45/src/PartsUnlimitedWebsite/Views/Shared/_Layout.cshtml. Change v2.0 to v3.0
8. Follow the release through to QA. It will fail. Click the View post-deployment gates button.

9. In a new tab open ‘Boards

   Queries

   Shared Queries

   Critical Bugs’ to locate the bug

10. Open the bug and mark it as Done. Click Save. (Usually we’d actually fix the bug ;-))
11. Return to release tab. After approx 5 mins Azure DevOps will check the query again. Once it does, the bugs will be cleared and the release will be approved. You can then click Approve to approve deployment to production.
12. Confirm the release and watch it, and then check the prod website

Task 6: Working with deployment slots

The most common scenario for using a deployment slot is to have a staging stage for your application to run against productions services, but without replacing the current production application. If the staging deployment passes review, it can immediately be “swapped” in as the production slot with the click of a button. As an additional benefit, the swap can be quickly reversed in the event an issue is uncovered with the new build.

1. Open the prod app service > Deployment Slots > Add Slot > ‘staging’ with ‘Config Source’ as the current deployment. Note: the ‘production’ slot is considered a ‘default’ and is not shown as a separate slot
2. Edit the Azure DevOps Prod stage pipeline > Select ‘Deploy Azure App Service’ task >
3. Select Deploy to slot > choose ‘staging’. Click Save
4. Commit a change to ‘v4.0’. Follow pipeilne through and approve release.
5. Refresh browser tab for Prod website -> Still v3.0
6. Open a new tab to the staging slot…. ‘https://-staging.azurewebsites.net
7. Return to the App Service in Azure Portal. Deployment Slots > Swap > OK (with defaults)
8. Refresh prod browser window -> v4.0

Note: Note that if your apps rely on slot-level configuration settings (such as connection strings or app settings marked “slot”), then the worker processes will be restarted. If you’re working under those circumstances and would like to warm up the app before the swap completes, you can select the Swap with preview swap type.

Exercise #3 GitHub integration with Azure Pipelines

Source: https://www.azuredevopslabs.com/labs/vstsextend/github-azurepipelines/

This is my version of the how bots work doco page, customised to explain the Enterprise Bot Template.

The reason that I have done my own version is that for me I’d rather read well commented (overly commented) code to understand how something works than reading a paragraph of text, then associating it with code.

Sources

• How bots work

Bot Class

    public class EnterpriseBotSample : IBot
    {
        private readonly BotServices _services;
        private readonly ConversationState _conversationState;
        private readonly UserState _userState;
        private readonly IBotTelemetryClient _telemetryClient;
        private DialogSet _dialogs;

• The main bot logic is defined in the EnterpriseBotSample class that derives from the IBot interface.
• IBot defines a single method OnTurnAsync.

OnTurnAsync

public async Task OnTurnAsync(ITurnContext turnContext, CancellationToken cancellationToken = default(CancellationToken)) 

OnTurnAsync: updated with my code comments. I wouldn’t usually write this many comments in code ;-)

// Turncontext provides information about the incoming activity. 
	public async Task OnTurnAsync(ITurnContext turnContext, CancellationToken cancellationToken = default(CancellationToken))
{

	//The incoming activity corresponds to the inbound HTTP request. 
	// Activities can be of various types, so we check to see if the bot has received a message. 
    if (turnContext.Activity.Type == ActivityTypes.Message)
    {
		//If it is a message, we get the conversation state from the turn context, increment the turn counter, and then persist the new turn counter value into the conversation state. 

        // Get the conversation state from the turn context.
        var oldState = await _accessors.CounterState.GetAsync(turnContext, () => new CounterState());

        // Bump the turn count for this conversation.
        var newState = new CounterState { TurnCount = oldState.TurnCount + 1 };

        // Set the property using the accessor.
        await _accessors.CounterState.SetAsync(turnContext, newState);

        // Save the new turn count into the conversation state.
        await _accessors.ConversationState.SaveChangesAsync(turnContext);


		// And then send a message back to the user using SendActivityAsync call. 
		// The outgoing activity corresponds to the outbound HTTP request.

        // Echo back to the user whatever they typed.
        var responseMessage = $"Turn {newState.TurnCount}: You sent '{turnContext.Activity.Text}'\n";
        await turnContext.SendActivityAsync(responseMessage);
    }
    else
    {
        await turnContext.SendActivityAsync($"{turnContext.Activity.Type} event detected");
    }
}

Set up services

The ConfigureServices method in the startup.cs file

• is where .NET Core configure Dependency Injection as per the docs
• it loads the connected services from .bot file,
• catches any errors that occur during a conversation turn and logs them,
• sets up your credential provider and
• creates a conversation state object to store conversation data in memory.

services.AddBot<EchoWithCounterBot>(options =>
{
    // Creates a logger for the application to use.
    ILogger logger = _loggerFactory.CreateLogger<EchoWithCounterBot>();

    var secretKey = Configuration.GetSection("botFileSecret")?.Value;
    var botFilePath = Configuration.GetSection("botFilePath")?.Value;

    // Loads .bot configuration file and adds a singleton that your Bot can access through dependency injection.
    BotConfiguration botConfig = null;
    try
    {
        botConfig = BotConfiguration.Load(botFilePath ?? @".\BotConfiguration.bot", secretKey);
    }
    catch
    {
        //...
    }

    services.AddSingleton(sp => botConfig);

    // Retrieve current endpoint.
    var environment = _isProduction ? "production" : "development";
    var service = botConfig.Services.Where(s => s.Type == "endpoint" && s.Name == environment).FirstOrDefault();
    if (!(service is EndpointService endpointService))
    {
        throw new InvalidOperationException($"The .bot file does not contain an endpoint with name '{environment}'.");
    }

    options.CredentialProvider = new SimpleCredentialProvider(endpointService.AppId, endpointService.AppPassword);

    // Catches any errors that occur during a conversation turn and logs them.
    options.OnTurnError = async (context, exception) =>
    {
        logger.LogError($"Exception caught : {exception}");
        await context.SendActivityAsync("Sorry, it looks like something went wrong.");
    };

    // The Memory Storage used here is for local bot debugging only. When the bot
    // is restarted, everything stored in memory will be gone.
    IStorage dataStore = new MemoryStorage();

    // ...

    // Create Conversation State object.
    // The Conversation State object is where we persist anything at the conversation-scope.
    var conversationState = new ConversationState(dataStore);

    options.State.Add(conversationState);
});

Startup.cs - configuring state

Note: this is different to the getting started doc. It works differently in the enterprise template - we aren’t configuring the stateaccessors in the ConfigureServices method

Understanding state

var dataStore = new CosmosDbStorage(cosmosOptions);
            var userState = new UserState(dataStore);
            var conversationState = new ConversationState(dataStore);

            services.AddSingleton(dataStore);
            services.AddSingleton(userState);
            services.AddSingleton(conversationState);
            services.AddSingleton(new BotStateSet(userState, conversationState));

startup.cs - Configure method

The Configure method finishes the configuration of your app by specifying that the app use the Bot Framework and a few other files. All bots using the Bot Framework will need that configuration call. ConfigureServices and Configure are called by the runtime when the app starts.

        public void Configure(IApplicationBuilder app, IHostingEnvironment env)
        {
            if (env.IsDevelopment())
            {
                app.UseDeveloperExceptionPage();
            }

            app.UseBotApplicationInsights()
                .UseDefaultFiles()
                .UseStaticFiles()
                .UseBotFramework();
        }

The bot file

The .bot file contains information, including the endpoint, app ID, and password, and references to services that are used by the bot. This file gets created for you when you start building a bot from a template, but you can create your own through the emulator or other tools. You can specify the .bot file to use when testing your bot with the emulator.

{
    "name": "echobot-with-counter",
    "services": [
        {
            "type": "endpoint",
            "name": "development",
            "endpoint": "http://localhost:3978/api/messages",
            "appId": "",
            "appPassword": "",
            "id": "1"
        }
    ],
    "padlock": "",
    "version": "2.0"
}

State

- User state is available in any turn that the bot is conversing with that user on that channel, regardless of the conversation
- Conversation state is available in any turn in a specific conversation, regardless of user (i.e. group conversations)
- Private conversation state is scoped to both the specific conversation and to that specific user

Source: Managing State

    public class OnboardingDialog : EnterpriseDialog
    {
        private static OnboardingResponses _responder = new OnboardingResponses();
        private IStatePropertyAccessor<OnboardingState> _accessor;
        private OnboardingState _state;

        public OnboardingDialog(BotServices botServices, IStatePropertyAccessor<OnboardingState> accessor, IBotTelemetryClient telemetryClient)
            : base(botServices, nameof(OnboardingDialog))
        {
            _accessor = accessor;
            InitialDialogId = nameof(OnboardingDialog);

            var onboarding = new WaterfallStep[]
            {
                AskForName,
                AskForEmail,
                AskForLocation,
                FinishOnboardingDialog,
            };

            // To capture built-in waterfall dialog telemetry, set the telemetry client 
            // to the new waterfall dialog and add it to the component dialog
            TelemetryClient = telemetryClient;
            AddDialog(new WaterfallDialog(InitialDialogId, onboarding) { TelemetryClient = telemetryClient });
            AddDialog(new TextPrompt(DialogIds.NamePrompt));
            AddDialog(new TextPrompt(DialogIds.EmailPrompt));
            AddDialog(new TextPrompt(DialogIds.LocationPrompt));
        }

        public async Task<DialogTurnResult> AskForName(WaterfallStepContext sc, CancellationToken cancellationToken)
        {
            _state = await _accessor.GetAsync(sc.Context, () => new OnboardingState());

            if (!string.IsNullOrEmpty(_state.Name))
            {
                return await sc.NextAsync(_state.Name);
            }
            else
            {
                return await sc.PromptAsync(DialogIds.NamePrompt, new PromptOptions()
                {
                    Prompt = await _responder.RenderTemplate(sc.Context, sc.Context.Activity.Locale, OnboardingResponses.ResponseIds.NamePrompt),
                });
            }
        }

Dialogues

See the docs

Gathering user input via Dialogues