Forum Widgets
Latest Discussions
Functor Model Transparency and Auditability
https://github.com/AutonomicAI/functor-resnet/tree/main/slm_template shows a refactoring of the model into separate files. For example, a file f.py is used for the model function, delta.py for model changes that are applied and w.py for the weights function. Every changed to the model is logged to an enterprise streaming event log and versions in a source code repository for these files can be referenced. The model.py code now references these other files as well as containing model functionality. It resembles an orchestrator or a controller in a sense. model.py => { load current functions, route inference, invoke components, invoke state/context representation functions, apply governed updates, emit provenance } With a specialized VCS tied into normal engineering workflow, a model change can become an ordinary governed change record. Then an auditor can traverse the chain in either direction answering: who changed it? what changed? why it changed? which requirement authorized it? what evidence supported it? which tests passed? which model version resulted? That is much richer than conventional model observability. So, there are really two layers: prediction audit - explain why a certain output prediction was given evolution audit - explain the current manifestation of the model Simple integration of the event log with the version control system and the project management tooling such as Microsoft Planner Functor Models may be unusually strong on the second because the change itself is a first-class artifact. The Microsoft Planner/Jira/PR integration matters because we are not asking enterprises to invent a new governance process. We are mapping model evolution into processes they already use for software change control. The specialized version control is a separate topic in as sense as we could see some significant energy savings via reuse in learning/training computation. A VCS with sophisticated semantic searching, fragmentation matching (we computed learning with a expression containing reusable piece for example) could save computation. This is preliminary research and requires further investigation of course. "Treat a learned model change with the same rigor as a production code change". For regulated environments, that is a very compelling proposition.Functor Model Architecture
We all know that AI energy usage is going to become a serious issue. Qualcomm CEO Amon's forecast of 1.27 trillion tokens per 10 seconds in 2030 is alarming. I have been trying to find better ways in software for AI where we get the same results but use less energy. Functor models are a potential avenue. Functor models learn by modifications to the function(s) not the parameters. They also learn one-shot, one unit at a time and they are auditable, governable and transparent. Every change to the model is logged. That log looks somewhat like a GitHub repository of function changes. Of course proof is in implementation and benchmarking. These are documents I have published on functor models - https://doi.org/10.5281/zenodo.21466484 The document RecoverableLearning.pdf shows a likely decrease in overall energy usage. Retraining models is costly, this offers a "repair" over retraining. The work on Functor Reasoning Models reaches into more complex areas of mathematics but seems promising. I have a Functor LLM design and code but it is very preliminary and needs work. I have deferred this to the "LOP" or LLM Offloading Pattern which is described in the LOP_v3.pdf.Does MVP application Decline Status normally include an email notification with comment or feedback?
Hi everyone, I’m a former Microsoft MVP (14 years) and was recently nominated again. I continue to run both global and local community initiatives, and I’ve also delivered sessions at Microsoft Reactor. I submitted my MVP application, and when I contacted MVP Support for assistance, they initially couldn’t locate my application under my email address. After several follow‑ups, they eventually found it and informed me that my nomination was declined. However, I have not received any decline email, and when I log in to the MVP site, my application still shows “Under Review” rather than “Declined.” I’d like to check with the community: When an MVP nomination is declined, is an official email notification normally sent? Does that email include any comments or feedback? Should the dashboard status update immediately once a decision is made? I’m simply trying to understand the normal process so I can confirm whether something might be out of sync. Thanks in advance for any insights.Interested in becoming MVP member
My name is Misheck Mutuzana. I am a Curriculum Development Specia;list and Computyer Science teacher in Zambia. I am interested in becoming an MVP member and would like to learn more about the requirements, application process, and opportunities available to MVP members. I am particularly interested in contributing to the community, sharing knowledge and experiences, supporting other educators and technology enthusiasts, and participating in relevant events and activities in Zambia and the wider Africa region. I would appreciate any guidance on how I can get started and work towards becoming an MVP member.
Why Your Copilot Studio Agent Fails in Production (And How to Fix It)
Most Copilot Studio tutorials show you how to build a chatbot. This post is about something harder: building agents that actually work in production. I architect enterprise agents at a hospitality company — handling customer email triage, HR workflows, helpdesk automation, and reporting pipelines across multiple systems. One of those agents reduced human handling time per customer email from ~12 minutes to under 2 minutes (88% reduction) by orchestrating sentiment analysis, CRM lookups, SOP research via child agents, and response drafting — all before a human agent ever opens the email. Here is what I've learned building at that scale. The Four Layers Every Enterprise Agent Needs Most teams design only the top layer and treat everything else as "we'll figure it out later." By the time the other layers become urgent — usually after an incident — they're too expensive to retrofit. Layer Component Conversation Topics · Entities · Adaptive Cards · NLU Orchestration Agent routing · Context passing · State Integration Connectors · Power Automate · Azure Functions Governance DLP · Auth · ALM · Monitoring · Logging Build the governance layer first. Design the conversation layer last. The demo will be slightly less impressive. The production deployment will be significantly more stable. The Three Mistakes I See Most Often 1. Slot-filling designed for the happy path The default Copilot Studio pattern collects parameters one by one. It breaks the moment your flow has conditional branches — which every real enterprise workflow does. Use intent-first routing instead: identify what the user wants before collecting any parameters, then branch to a sub-flow that collects only what that variant needs. 2. Multi-agent context that gets dropped When you delegate from a router agent to a capability agent, the receiving agent needs to know who the user is and what conversation state to preserve. Native session variables don't cross agent boundaries. Build an explicit context envelope — a JSON object passed at delegation time — that carries user identity, security scope, origin topic, and return context. Your agents become stateless with respect to each other. Context travels with the conversation. 3. No async pattern for slow integrations A synchronous request that works for a REST API returning in 200ms will silently fail for a legacy system query that takes 45 seconds. Design async from day one: submit to an Azure Service Bus queue, return a correlation ID, acknowledge the user, and use proactive messaging to deliver the result when it's ready. This is the single biggest gap between demos and production deployments. A Note on Authentication — Chatbots vs. Autonomous Agents This is a distinction most articles get wrong, so it's worth being explicit. Chatbots have a human on the other end of the conversation. Authentication options here include Entra ID SSO (works in Teams and SharePoint channels where the user's identity is delegated to the agent) or client ID + secret (validates against AD but without user delegation — the agent authenticates as itself, not as the user). Autonomous agents are different in a fundamental way: there is no human in the authentication loop. The agent authenticates using the identity of the account that owns and runs it. There is no SSO because there is no interactive user session. This distinction matters because the security model shifts entirely — you are no longer protecting a user session, you are protecting a service identity. This gets more interesting when your autonomous agent connects to non-Microsoft systems. There is no universal pattern here — it depends entirely on what the external system supports: - API Key / Secret — the most common pattern for SaaS integrations. The external system issues a scoped key specifically for this integration. Store it in Azure Key Vault or encrypted Power Platform environment variables, never hardcoded in a flow. The scoping question is critical: is this a full-admin key or a least-privilege key issued only for what this agent needs? - OAuth 2.0 Client Credentials (machine-to-machine) — the agent authenticates as itself using client ID + secret against the external system's auth server and receives a bearer token. No user involved, fully automated. - Basic Auth on legacy systems — still common in enterprise environments. Credentials must live in Key Vault, not in flow variables or connector configuration in plain text. - Custom connector with encrypted connection — Power Platform manages the auth at the connector level; credentials are stored encrypted and scoped to the environment. The governing principle across all of these: the identity the agent uses to call an external system should be issued specifically for that integration, scoped to only the permissions that agent needs, stored securely (Key Vault or encrypted environment variables), and auditable — meaning the external system's logs show the agent's calls as a distinct identity, not a shared admin account that 12 other things also use. Before You Go to Production — Quick Checklist [ ] Autonomous agent's owning account/service principal is scoped to least-privilege — access only to systems the agent needs, nothing broader [ ] Non-Microsoft system credentials stored in Azure Key Vault or encrypted environment variables — never hardcoded in flows [ ] Each external system integration uses a dedicated, scoped credential — not a shared admin account [ ] External system audit logs show the agent as a distinct, identifiable caller [ ] DLP policies configured per environment — production is strict, dev is permissive [ ] Dataverse schema finalized before topic design begins [ ] Error handling designed for every integration point with user-readable failure messages [ ] Async pattern in place for any integration that may take > 10 seconds [ ] ALM pipeline configured: Dev → Test → UAT → Prod with automated solution checker [ ] Application Insights connected with custom events for key agent actions [ ] Escalation rate baseline established with alert threshold configured The One Question to Ask Before Building Anything "What does success look like in six months, and what data does the agent need access to in order to achieve it?" That answer determines your Dataverse schema, your integration architecture, your authentication model, and your DLP policy — before a single topic is created. Agents designed from that question forward are maintainable and trusted by the business. Agents designed from the conversation layer down spend their first year in retrofitting mode. Happy to go deeper on any of these layers in the comments — particularly multi-agent context passing and the async pattern, which I find generate the most questions in enterprise deployments.
Still Contributing, Still Supporting the Community — But Still Questioning the MVP Decision
I still don’t understand the reason behind my rejection from the Microsoft MVP Program. For years, I have been actively contributing to the tech community in Tunisia through free events, international conferences, training sessions, mentoring, and knowledge sharing around Microsoft technologies, Data, Power BI, Microsoft Fabric, and AI. I proudly represent my country in many community initiatives and continue supporting professionals and students with passion and dedication. What makes this decision difficult to understand is the lack of clear feedback or explanation regarding the refusal. Transparency is important, especially in a global program that values community impact and leadership. I will continue contributing to the community with the same energy and commitment, because community work is bigger than any title.MVP membership
Good day, I would like to become a MVP - but I remember in the past you need to be sponsored and be active in the technical Microsoft forums ? I've got a MCSE. MSCD, MCDBA and MCT certifications under my belt. But not sure what the next step is ? I also my internship in the UK with the SRG team in Reading.... (and met the developer who designed and codes the old 'robocopy' console app :) Thanks and regards, Pieter ClaassensMVP Enthusiast
working professional more than 25 years of work exprience i do create videos on excel tutorial but never be earned pretigious award of MVP i dont know only if i post expertise on learn.microsoft.com then only my experience count as i am the expert ? my dream is dream to become MVP one just small desire have nice day all dont want to spam but just this is my feeling thanks
