Skip to content
Back to Magazine
automation-aiops 5 min read

Microsoft Foundry Local + Scout: When Agent Work Moves to the Edge

Does this apply to your company?

Free 30-min AI diagnostic →

Key Takeaways

  • - Microsoft 365 context
  • - actions in work applications
  • - local desktop resources
  • - models and runtimes that no longer always depend on a remote call

Decision

Separate reliable automation from fragile demo before granting it autonomy.

Room

Operations review, architecture, security or platform.

Risk

Adding speed with no observability, rollback, ownership or stop criterion.

Agent prompt: identify guardrails, control points, likely failures and autonomy criteria

Problem

For too long, the enterprise agent promise has been split in two.

On one hand, powerful cloud agents with access to models, workflows, and governance. On the other, real work that still lives in browsers, desktops, local files, and internal systems. The result is a fractured operation: the agent reasons far from where the actual work happens.

At Build 2026, Microsoft brought together two pieces that are usually analyzed separately: Foundry Local to run models and AI capabilities locally on Windows, and Scout as a persistent personal agent within Microsoft 365. The signal is not that Microsoft “also has its own AI.” The signal is that it wants to unite cloud, desktop, and local edge in a single operational surface.

Thesis

What’s relevant from Microsoft this week is not a new model. It’s an architecture shift.

Microsoft is trying to make the agent stop being a chat window and become a layer that operates between:

  • Microsoft 365 context
  • actions in work applications
  • local desktop resources
  • models and runtimes that no longer always depend on a remote call

That changes the conversation from “which model you use” to “where the work runs and under what control.”

Framework

There are four layers in Microsoft’s bet:

  • Scout: persistent agent connected to Teams, Outlook, OneDrive, and SharePoint.
  • Work IQ APIs: surface for agents to interact with Microsoft 365 data and apps.
  • Foundry Local + Windows AI APIs: local execution and on-device capabilities on Windows.
  • Agent 365 / security and governance: observability, permissions, and control of agents even when they don’t just live in the cloud.

Mini-case: an analyst receives emails, prepares a meeting, consults files, checks the calendar, and needs to cross-reference decisions with local project notes. If the agent lives only in the cloud, friction increases every time it leaves the core apps. If it lives in a mixed perimeter, it can move between enterprise knowledge and local context with less back-and-forth.

Measurable signal: percentage of agent tasks that can be resolved without taking the user out of their workflow between desktop, browser, and collaborative suite.

Posture: the real product is not the copilot. It’s the perimeter where that copilot can work securely.

Why it matters now

On June 2, 2026, Microsoft presented Scout as an always-on agent for work and reinforced the local AI stack on Windows with Foundry Local, Windows AI APIs, and more on-device capability on CPU, GPU, and NPU.

Seen together, the move points to an ambitious thesis: agents won’t just live in SaaS or just in chat. They’ll live in the full work interface.

That matters operationally for three reasons:

  • Reduces context latency: not everything requires a trip to the cloud.
  • Brings the agent closer to real work: browser, files, and local apps come back into play.
  • Raises the governance bar: if the agent touches desktop and local resources, control can’t stay just in the app.

Anti-example

“We have an agent in M365, so we’re already covered.”

No. Having an agent within a suite doesn’t by itself resolve:

  • what local resources it can use
  • which model runs where
  • what data leaves the device
  • how action is logged between cloud and desktop
  • who shuts down the flow if something goes off track

Without that design, you’re just changing interfaces. You’re not changing the operating model.

Protocol (3 steps)

  1. Map where work really happens. Suite, browser, desktop, local files, internal systems.
  2. Decide what part should run locally. Privacy, latency, cost, offline continuity, or proximity to the user.
  3. Unite execution and governance. Logs, identity, permissions, and kill switch must cross cloud and local perimeter.
LayerQuestionRisk if missing
agentwho acts and for whatautomation without owner
contextwhat data it usesdisconnected responses
local runtimewhat runs on deviceexcessive latency and dependency
governancewho observes and cuts offautonomy without control

Sources consulted

Next step

If your company wants persistent agents, stop thinking just about the suite. Map the perimeter of real work: browser, desktop, files, local context, and shared governance.


Translated from the Spanish original with AI assistance and reviewed for accuracy. Read the original in Spanish.

microsoft foundry-local scout local-ai
Cite this article

Berthelius, V. (2026). “Microsoft Foundry Local + Scout: When Agent Work Moves to the Edge”. BRTHLS Magazine. https://www.brthls.com/magazine/microsoft-foundry-local-scout-edge-computing-en

Fractional CAIO · Free diagnostic

Is your company ready to operate with AI?

30 minutes. No pitch. An honest read on where you are and what to move first.

Book free diagnostic