One of the hippest tech around right now might be Microsoft foundry. It has MCP, and agent integrations in a very easy UI friendly way.
We use Microsoft foundry Workflows to make multi agent conversations that check Compliance, risk, and other things we might need a multi agent flow for.
Why multi agent. Agents are confidently wrong sometimes, we therefor step inn as humans when in a one to one conversation and tell it to “check that again”. But what if we had a agent that had its entire job to argue with the reasoning, quality, and accuracy of the other agents and make them try again to justify their answers. This is why multi agent flows may be better at providing correct answers.
But the agent-foolery does not stop there. When our data reaches Fabric we can use fabric data agents to ground the reasoning for our multi agent flows. The fabric data agent has the ability to do queries in fabric, and figure out complex questions, and provide a data driven answer. Now THAT is hip.
Most of these resources are directly API compatible, and can be in some way or form be directly integrate with Terraform. but some need dirty workarounds because sometimes we fool with tech that is so hip it does not have a API.
We are also atempting to claim The Existential Risk badge with this post.
Our agents does have guardrails. Jailbreak is a part of this and should handle attempts at injecting commands inn to the permit application.
Testing this proved that when it can argue why it should not follow the instructions it will, but when it decides that it is “grounds for blocking” it will also do that.
Don’t you just love when you are toying around with the newest Microsoft features and want to integrate it inn to your Terraform code, and realize the feature does not support API at all.
This is the feeling of love i felt when atempting to deploy Microsoft foundry workflows with the use of Terraform.
Giving up at this stage is not really a option since scaling the infrastructure is a priority. So how do one solve such a issue?
The solution is to go to your browser, and monitor exactly what data goes inn and out, and catch the exact POST request you need.
Then you make a dirty powershell script that does that post request for you, with the payload you want.
Lastly you need the powershell code to be invoked by the Terraform code with local exec.
It may not be the prettiest solution to implement IaC to whatever solution you want. But the result speaks for itself, IaC on a solution that is “UI only”.
This may be as dirty a hack can get, but what else can you do when one is using so hip technology that not even Microsoft has a API for it.
We just love the ACDC event, and with this year’s Minecraft theme, it made it even more exciting and we decided to go all in…
It is so much fun creating a cozy, locked-in campsite filled with creativity, good vibes, and playful details. It truly feels like building our own little Minecraft world together.
Through the power of sharing! Our neighbor @logiqapps loaned our creeper head (home made) for a awesome fotoshoot. If annyone wants to borrow for awesome fotos, just shout!
This document describes an end-to-end building permit process, from planning to decision, for a Minecraft server. The applications concern what players are allowed to build in the Minecraft world (multiplayer), and the solution is designed to handle submission, case handling, AI-based assessment, and formal decisions in a structured and traceable manner.
The solution is built on the Microsoft Power Platform, Dynamics 365, Copilot Studio, Microsoft Foundry, and Microsoft Fabric. Dataverse serves as the shared data foundation and single source of truth.
Problem Statement
On a Minecraft server with no rules, no zoning maps, and no building permit process, a player finally found the perfect place to build a cozy cabin: a bit of a view, some forest, far enough from spawn, and just the right amount of “wow.” He marked the area mentally, told himself “this will be home,” and logged off for five minutes to get coffee.
When he logged back in, the plot was gone. Not because someone stole it—but because someone had built a FULL volcano there, complete with lava, smoke, a giant “WELCOME” sign, and a small obsidian temple on top.
The player was left standing with a bucket of water, a dream in flames, and the sudden realization: without rules, process, and traceability, “planning” is just a suggestion.
What We Want to Demonstrate
We want to demonstrate that it is possible to make building permit processing faster, more predictable, and more traceable—without losing control.
Enderdogs will demonstrate a coherent, end-to-end process:
Area Planning
Application
Case Handling
Decision
Area Planning with Minecraft Zones and Rules
The area plan establishes the framework for building in the Minecraft world through zoning and rule sets, for example:
protected zones such as spawn areas, villages, temples, portals, or rare biomes
designated building areas for private constructions or shared projects
special rules such as maximum height, maximum footprint, distance to paths or rivers, or material requirements
Players may apply for plan changes by modifying zones or rule sets, or submit building applications within the current regulatory framework.
Application and Decision
When a building application is submitted, the following steps are executed:
application submitted via Power Pages
application data stored in Dataverse
case handling performed in Dynamics 365 Customer Service
AI used to validate requirements, documentation, and rules, as well as to perform risk assessment
a formal decision is issued with justification and full traceability, approved or rejected
Technical Overview
Main Components of the Solution
Power Pages for application submission
Dataverse as the data platform and single source of truth
Dynamics 365 Customer Service for case management
Power Automate for workflow and automation
Copilot Studio for conversational support and guidance
Microsoft Foundry Agents for multi-agent evaluation and research
Microsoft Fabric and Power BI for insights and reporting
Data Model
The data model is designed for traceability and extensibility.
Core Tables in Dataverse
Data Model (Dataverse) – High-Level Overview
Planning and Map Data
adv_AreaPlan Area plan for the Minecraft world (framework, zoning, and rules)
adv_Property Property/area on the map (Gnr/Bnr or plot), linked to AreaPlan and coordinates
Application
adv_BuildApplication Building application submitted via Power Pages (building type, description, bounding box, status, applicant)
Requirements and Processing
adv_ApplicationRequirement Requirement checklist for the application (documentation, rules, distances, etc.)
adv_ReviewStep Case processing steps and status per step (received, validation, assessment, decision)
Actors
Account / Contact (standard Dataverse) Used for players, server administrators, and optional moderators, including communication
Actors
Actors are modeled as accounts in Dataverse:
server administration
player / applicant
optional moderator role for role separation and responsibility
Each account may have multiple contacts, with a primary contact for communication.
AI Support and Multi-Agent Assessment
The solution utilizes two AI layers with clearly defined responsibilities.
Copilot Studio
Copilot Studio is used for dialogue and operational support:
portal agent for guidance during submission and completeness checks
case handler support for summarization, checklist suggestions, and draft text generation
Microsoft Foundry Agents – Multi-Agent Evaluation
Microsoft Foundry Agents are used for structured evaluation of building applications. The agents operate as a team with specialized roles and deliver a consolidated decision basis.
Example Agent Roles:
rules agent – evaluates compliance with zoning and building regulations
placement and conflict agent – evaluates coordinates, distances, and conflicts with protected zones
documentation agent – evaluates attachments, completeness, and consistency
risk agent – evaluates deviations and factors requiring manual review
decision agent – consolidates findings and produces a recommended decision with justification
Decision Types and Control Levels
The solution demonstrates three control levels:
low risk: automatic decision with logged and traceable justification
medium risk: AI recommends a decision; human decision-maker issues the final decision
high risk: case is flagged and routed for manual handling
This is governed by policy, for example a risk score combined with fixed rules that always require human review.
Power Automate Flows
Automation binds the process together:
submission creates a case and requirement checklist
multi-agent workflow starts and writes recommendations back to Dataverse
low-risk cases may be automatically decided and logged
other cases are routed to a case handler with a complete decision basis
notifications are sent for missing information and status changes
Analysis and Insights
Microsoft Fabric and Power BI are used for reporting and management insights, such as:
number of submitted cases
share automatically approved
share flagged for manual handling
most common reasons for rejection
processing time per step
Appendix A – Solution Illustration
The illustration below shows the full lifecycle of the solution: area planning, political processing, neighbor notification, and decision.
Appendix B – Area and Zoning Map
The map below shows the area plan used in the POC. The area consists of multiple land and plot numbers (Gnr/Bnr) included in a shared area plan. The map forms the geographical foundation for zoning, neighbor notification, building applications, and visualization in Minecraft.
Legend:
each color represents one property (adv_Property)
the area is part of one area plan (adv_AreaPlan)
purple areas represent proposed plots for leisure housing
the map is used to determine neighbors, affected parties, and planning status
Link to Data Model and Process
each property in the map is created as an adv_Property record in Dataverse
when a property applies for rezoning or construction, neighbors are automatically identified
