AI Agents, Copilot, OpenClaw, Foundry: The Stack I’d Actually Recommend in 2026

AI Agents Mar 19, 2026

If you hang around the Microsoft / cloud / AI corner of the internet long enough, you’ll see the same pattern over and over again:

someone discovers Copilot and wants it everywhere,
someone else falls in love with agent frameworks like MCP/Foundry,
and the home‑lab crowd is busy wiring OpenClaw into everything they own.

On paper, all of this sounds amazing. In practice, you can burn a lot of time and money by throwing the wrong tool at the wrong problem.

In this post I want to write down how I currently think about an AI/automation stack in 2026 – specifically around Microsoft 365 Copilot, Foundry/MCP and OpenClaw – and where I would (and wouldn’t) use each of them.

Copilot: your “inside M365” assistant

Let’s start with the obvious one. Microsoft 365 Copilot is, by design, an assistant that lives inside your Microsoft 365 tenant:

it talks to Microsoft Graph,
it sees SharePoint/OneDrive/Teams/Exchange according to your permissions,
and it shows up where people already work (Outlook, Word, Teams, etc.).

That makes it a great fit for:

summarising and drafting based on documents, mails and chats you already have,
answering “what do we know about…” questions inside your M365 content,
helping with everyday knowledge work like minutes, recaps, next steps.

What it is not by default:

a direct front‑end to every ERP/CRM/HR system you own,
a tool to SSH into servers or run scripts,
a replacement for well‑designed applications and workflows.

My rule of thumb for Copilot:

If the problem lives mostly inside Microsoft 365 and is about understanding, structuring or communicating information, Copilot should be your first stop.

Before you reach for anything else, ask: can we solve 80% of this by cleaning up our M365 content and letting Copilot work on top of that?

Foundry + MCP: orchestrating serious backend work

Once you move beyond “help me with the stuff in my tenant” into “help me orchestrate real systems”, Copilot alone isn’t enough.

That’s where MCP (Model Context Protocol) and platforms like Foundry come in. They give you a structured way to describe tools and backends that an agent can call:

you define tools like sap_list_users, entra_list_users, create_jira_ticket,
your backend implements those tools, with proper auth and business rules,
the agent gets a clear menu of what it can do and how.

Foundry adds a home for this setup:

hosting for agents and MCP servers,
environment separation (dev/test/prod, tenants),
observability and configuration management.

Where this shines for me:

cross‑system “insights” agents (e.g. SAP HR ↔ Entra ID sync insights),
domain‑specific helpers (“explain error codes from our internal systems using our KB”),
structured automation where you want AI to plan, but your backend to execute.

My rule of thumb for MCP/Foundry:

Use it when you need a real orchestrator across multiple systems, with clear tools, where security and observability matter as much as the model itself.

If your “agent” is essentially one API call in disguise, you probably don’t need MCP or Foundry yet. If you’re juggling SAP, Entra, ticketing and internal services in a single conversation, you do.

OpenClaw: your personal automation lab (with teeth)

OpenClaw sits in a different corner of the stack. It’s a self‑hosted agent/control plane that runs wherever you install it – on a server, a VM, a Mac mini in your home office.

It can:

chat with you via your preferred channels (Telegram, Signal, Discord, …),
run scripts, call APIs, read and write files, talk to local services,
use “skills” to glue workflows together (blog publishing, backups, monitoring, etc.).

I think of OpenClaw as:

a CI/CD system with a personality – more “personal DevOps/ops assistant” than generic enterprise platform.

Where it’s strong:

personal workflows (blogging, research, small automations around your own accounts),
developer productivity (repo analysis, code scaffolding, local scripts),
home‑lab and side projects, where you’re comfortable with the blast radius.

Because it runs with your own permissions on a machine you control, you get a lot of power – and a lot of responsibility. I would not casually tell an OpenClaw agent “you can manage prod SAP” and forget about it.

How these three actually fit together

If you try to force a single tool to do everything, you end up unhappy:

pushing Copilot far outside its sweet spot,
using OpenClaw for things that need tenant‑level governance,
or building giant MCP agents where a simple app would do.

The stack that currently makes sense to me looks more like this:

Layer 1 – Copilot & M365
daily knowledge work, summarisation, drafting, “what do we know about…” inside your tenant.
Layer 2 – Foundry/MCP agents
orchestrating multiple enterprise systems, exposing carefully designed tools with proper security trimming.
Layer 3 – OpenClaw
personal and team‑level automation on infrastructure you own, where you’re willing to accept more experimental workflows.

A few examples to make that less abstract:

Writing and publishing a blog article?
Draft in Word with Copilot, refine in your Ghost editor, let OpenClaw handle the “turn this HTML into a Ghost draft + send notifications” plumbing.
Understanding identity drift between SAP and Entra?
Use a Foundry/MCP agent to compute the mismatches and produce a report. Let Copilot summarise that report for management. Maybe use OpenClaw to kick off some local checks or scripts related to your own test environment.
Helping a support engineer with internal error codes?
Use a Foundry agent that knows how to call your internal KB and systems, then surface that inside Teams (with Copilot in the mix for explanation). OpenClaw doesn’t need to be involved.

Where I would not use each piece

A quick anti‑pattern list, because that’s often more helpful than the happy path.

Copilot is the wrong tool if:

you expect it to directly manipulate infrastructure,
you want guaranteed, auditable sequences of actions (that’s what workflows and agents are for),
you treat it as a “SQL client for everything” instead of a layer on top of curated data.

Foundry/MCP is the wrong tool if:

you only need a single API call and no orchestration,
you don’t have the capacity to own and maintain the backend logic and schemas,
you’re trying to “hide” all business logic in prompts instead of proper tools.

OpenClaw is the wrong tool if:

you need centralised enterprise governance and least‑privilege by default,
you’re not comfortable giving an agent shell/API access on a box that has sensitive stuff on it,
you really just need a normal application or script, not an always‑on agent.

My take

We’re past the stage where “just add AI” is an interesting strategy. The question now is where to put which kind of intelligence – and how to keep the overall system understandable.

Right now, my answer looks like this:

Copilot for the tenant you already have,
Foundry/MCP for cross‑system orchestration with real backends,
OpenClaw for personal and experimental automation where you own the risk.

That will evolve, but the principle won’t: pick the tool that matches the blast radius and governance level of the problem. If you do that, you get the upside of all three – without turning your stack into one big, unstructured AI experiment.