Log in
Ryan welcomes Trisha Gee, a Java champion and developer productivity advocate, to explore how AI is transforming the role of IDEs and the broader developer experience; the relevance of traditional tools, muscle memory, the risks of hype; and how to adapt workflows for AI-driven development.
|
Sr. Content Developer at Microsoft, working remotely in PA, TechBash conference organizer, former Microsoft MVP, Husband, Dad and Geek.
|
Pennsylvania, USA
Pennsylvania, USA
In the documentation for best practices for implementing process and thread-related callback functions, it calls out
- Keep routines short and simple.
- Don’t make calls into a user mode service to validate the process, thread, or image.
- Don’t make registry calls.
- Don’t make blocking and/or Interprocess Communication (IPC) function calls.
- Don’t synchronize with other threads because it can lead to reentrancy deadlocks.
So far so good. It seems that these callback functions need to operate quickly and cannot block. These are callbacks that are invoked when a process starts or exits, when a thread starts or exits, when a DLL or EXE is loaded or unloaded, and various other low-level events.
The various prohibitions above suggest that these callouts are called during the process creation/termination sequence, so if you take a long time to deal with them, you are slowing down the entire system. And the rather extreme requirements, like “Don’t make registry calls,” suggest that they might even be called while the system holds internal locks.
The list of best practices continues:
- Use System Worker Threads to queue work especially work involving:
- Slow APIs or APIs that call into other process.
- Any blocking behavior that could interrupt threads in core services.
Okay, so this is providing a suggestion on how you can offload expensive work to code running outside the callback. This once again highlights that the callback itself needs to be fast with minimal blocking.
My colleagues in enterprise support often run into cases where the reason for a system hang is a driver violating the rule that these callbacks must return quickly. For example, a common anti-pattern is a driver whose callback starts by following the guidance above to queue work to a System Worker Thread, but then they block until the work item completes.
This is a case of following the rules without understanding why the rules are there.
The rule is that the callback needs to be fast and return quickly. The driver followed the letter of the law by delegating the work to a System Worker Thread, and there’s no rule that says “Don’t wait for work items”, so they must have figured that this gave them a loophole for executing synchronous long-running work.
But the rules “Don’t make blocking and/or Interprocess Communication (IPC) function calls” and “Don’t synchronize with other threads because it can lead to reentrancy deadlocks” make it clear that you shouldn’t be blocking in your callback for extended periods of time. The “Don’t”s are just calling out some common ways that your callback can block.
And it looks like the documentation was updated in 2020 to call out this specific case:
- If you use System Worker Threads, don’t wait on the work to complete. Doing so defeats the purpose of queuing the work to be completed asynchronously.
One could argue that this rule is already covered by the “Don’t synchronize with other threads” rule, but I guess the driver vendor interpreted it as “But I’m not synchronizing with another thread. I’m synchronizing on an event!” But of course, the event is set by another thread, so you are effectively synchronizing with another thread.
My colleague in enterprise support describes this as the “It wasn’t me, it was my brother” excuse. You are told by your parents not to turn on the television set, so you tell your brother to do it. Technically, you didn’t turn the television set on, but in effect, you did because your brother is acting under your instructions. (This is why contracts often contain wording like “may not disclose or cause to be disclosed,” so that you can’t say “No, I totally didn’t disclose it. I gave the information to Bob, and it was Bob who disclosed it!”)
The documentation should open with something like this:
The callback function must perform its work quickly without blocking. If you need to do complex work or synchronize with other threads or processes, do the work asynchronously, such as by using System Worker Threads.
And then it can give a list of examples of things that count as blocking.
Some examples of blocking that is not allowed from the callback function:
And then it can follow up with additional constraints.
Furthermore, the callback function may not perform any of the following operations:
The post Understanding the rationale behind a rule when trying to circumvent it appeared first on The Old New Thing.
Pennsylvania, USA
This is the first post of the 4-part series on Agentic Data Infrastructure.Every business app now ships with an AI agent. Each one is good at its own job. The problem is, none of them talk to each other. Your helpdesk agent doesn't know about overdue invoices. Your CRM agent may not know about open support escalations. Each agent sees a slice of...
Pennsylvania, USA
Microsoft's June 2026 VS Code update turns on Autopilot by default and adds background sending for agent sessions.
Pennsylvania, USA
View all my published articles
Six months ago, Microsoft’s posture toward OpenClaw read as containment. According to multiple accounts, internal security guidance treated the open-source agent runtime as untrusted code that executed with persistent credentials, and Satya Nadella reportedly compared ungoverned deployments to a virus. Hold those two lines loosely, since they trace to secondary reporting rather than anything Microsoft published. The posture they describe was real either way. The official enterprise answer to “can I run this at work” was no.
Last week at Build, Microsoft shipped Scout, its first always-on agent, and built it on OpenClaw. Then it went further. It announced that it is contributing its policy conformance system directly upstream to the open project, so any organization running OpenClaw can validate its environment against security and compliance requirements and receive an audit-ready answer. That description comes from Microsoft’s own launch post, not from analyst spin.
The runtime Microsoft could not stop, it decided to standardize. That reversal is the story, and it carries a specific message for everyone building agents in regulated industries: the largest enterprise software company on earth just told the market that the agent is a commodity and the harness is the business.
What actually shipped
Scout is the first of a category Microsoft calls Autopilots: agents that run continuously rather than per-session, hold state, and operate across Teams, Outlook, OneDrive, and SharePoint. It is rolling out through the Frontier early-access program, desktop first. Under the hood is OpenClaw, the runtime Peter Steinberger assembled in late 2025, which went from weekend project to default substrate of the agent world in roughly six months.
Microsoft is not alone in the bet. Google shipped Gemini Spark on the same foundation days earlier, and Meta is reportedly close behind with Hatch. Three platform companies converging on one open runtime inside a single quarter is not sentiment. It is a verdict on where the value is not.
Why give away the good part
The New Stack published the sharpest read of the launch, and the analogy holds: this is Android again. Google made the base operating system a free common layer, and the money moved up the stack, into managed identity, device management, and the consoles enterprises actually pay for. The agent loop itself- read context, plan, call tools, write output- is heading the same direction. OpenClaw already does it well enough that Microsoft chose not to rebuild it.
Their illustration, which I will borrow and then transpose: picture an agent that reconciles invoices overnight. The reconciliation loop is solved; the open runtime handles it today. What stands between that agent and a production ledger is everything else. The company needs an identity it can name, a boundary that keeps the agent out of every system except accounts payable, and a record an auditor can reconstruct the next morning. The runtime supplies none of that. The layers above it do, and those layers are exactly what Microsoft kept: Agent 365, execution containment, the management plane.
What “policy conformance upstream” actually means
For the harness developers reading this, the substance matters more than the strategy. The control surface Microsoft describes has four parts. Agent identity, so every action has a named actor behind it. Scoped access, so the agent reaches only the resources and destinations the organization approved. Human approval gates on consequential actions, enforced before execution rather than logged after. And inline data protection, with sensitivity labels and loss-prevention policy applied at the moment of a write or send, not in a retrospective report. Conformance is the layer that checks a live deployment against those requirements and produces evidence of its passing.
Two implications follow if harnesses are your work.
First, the build-versus-buy line just moved. The bespoke validation scripts every serious OpenClaw shop has been writing by hand, the “is this deployment configured safely” code, become redundant as the upstream conformance layer matures. The durable work shifts to policy content: the baselines, the packs, the mappings from control to evidence that the conformance layer evaluates. Write policy, not plumbing.
Second, the timing is not subtle. The same week Scout launched, researchers disclosed five critical zero-days in OpenClaw’s allowlist identity resolution across a half dozen messaging surfaces. That is not an argument against the runtime. It is the argument for conformance. When the substrate moves this fast, you need a standard, repeatable way to prove your deployment is not the vulnerable configuration, and you need it on every release, not once a year during audit season.
The healthcare transposition
Now swap the invoice for a chart.
A patient agent that assembles a visit summary or drafts an amendment request after an AI scribe writes something wrong in a clinical note is not hard at the loop level. Tula does the first in about thirty seconds. What a health system needs before any agent touches PHI is the finance list with sharper teeth: an agent identity tied to an accountable person, access scoped to the minimum necessary record set, a human gate on anything that writes toward the legal record, and an audit trail that satisfies not just a CISO but a CMS surveyor or an OCR investigator. Patients exercising their right to amend under 164.526 deserve the same chain of evidence from their side of the portal.
Generic conformance gives you the substrate. It cannot tell you what counts as a sensitive action inside a clinical workflow, which evidence artifacts an auditor will actually accept, or how an amendment request must be tracked from submission to disposition. That is domain semantics, and it is the layer I have been calling the Fourth Tier: governed, domain-specific agents that sit above the runtime, the framework, and the generic harness. Microsoft just poured concrete under the first three tiers. The fourth is still open, and in healthcare it is still mostly empty.
Disclosure, because you should know where I sit: Tula, the open-source patient agent we released in May, runs on OpenClaw under an MIT license, and RealActivity’s compliance agents are built on the same runtime. When Microsoft puts platform engineering into the governance substrate of that runtime, the work compounds downstream, all the way to a patient agent running on a Medicare beneficiary’s laptop. I am long this thesis in the most literal way available.
Three moves
If you build agents in health and life sciences, three things follow.
Track the conformance work as it lands upstream, and build against it rather than beside it. Restructure your environment checks as policy packs the conformance layer can evaluate, so your controls inherit every improvement Microsoft ships instead of competing with them.
Stop spending innovation budget on substrate. Identity plumbing, containment, base audit logging: that work is being commoditized in public by companies with more engineers than you will ever hire. Your differentiation is policy content and the evidence model behind it, the parts that require knowing how a health system actually gets audited.
Pressure-test the phrase “audit-ready.” It means different things to a CISO, a HIPAA privacy officer, and a CMS surveyor. Map the conformance layer’s output to the artifacts your compliance team files today. Wherever there is a gap, that gap is your roadmap.
The harness was the bet
I have spent the past year making one argument: the agent was never the risk; the harness was. At Build, Microsoft made that argument for me, with a shipping product, an upstream contribution, and a 2026 roadmap priced around it. The runtime is free now. The harness never will be.
Vibes are becoming verifiable. This time it is on Redmond’s calendar too.
I will be going deeper on this on July 31 at M365 Community Days NYC, presenting “From Vibes to Verifiable” at Microsoft, 11 Times Square.
Sources
Microsoft 365 Blog, Scout launch announcement (June 2, 2026): https://www.microsoft.com/en-us/microsoft-365/blog/2026/06/02/introducing-microsoft-scout-your-always-on-personal-agent/
The New Stack’s analysis of the runtime-free, control-plane strategy: https://thenewstack.io/microsoft-scout-openclaw-runtime/
Reporting on Microsoft’s reversal and the Big Tech convergence on OpenClaw:
and https://thelettertwo.com/2026/06/07/openclaw-microsoft-google-meta-ai-agents
OpenClaw Weekly on the allowlist zero-day disclosures: https://www.bighatgroup.com/blog/openclaw-weekly-2026-06-08/
Paul J. Swider is CEO and Chief AI Officer at RealActivity, a Microsoft Partner specializing in mission-critical AI for healthcare systems. He has 30+ years in healthcare technology, has trained over 3,000 engineers across GE, IDX, and Microsoft, and is the founder of BOSHUG, the Boston Healthcare Cloud & AI Community spanning 50+ countries.
Pennsylvania, USA
Next Page of Stories