Building AI agents on Claude and Microsoft Foundry: field notes from e-commerce delivery

Most writing about AI agents comes from two places: the developers who build the frameworks, and the vendors who sell them. I sit somewhere else. I run digital commerce delivery at Alpha Solutions Norge, and I put agents into the same projects where I ship storefronts and integrations. The projects I run look like the omnichannel platform we launched for Møbelringen in 2024 — Norway's largest furniture chain, seventy stores, Adobe Commerce with a Next.js front end on Vercel. Real systems, real users, real consequences when something misbehaves.

From that seat, the choice between Claude and Microsoft Foundry is not a framework debate. It is a delivery decision, made under the same constraints as everything else: a client, a budget, a date, and someone who has to operate the thing after I leave. I use both. On one project the right answer is an agent built on Anthropic's Claude; on the next it is Microsoft's Agent Framework running on Foundry. What follows are field notes on where each one earns its place, and on the mistake I see teams make most often.

Where Claude's model earns its place

Claude's strength, for delivery work, is composability. The agent is a loop: the model reasons, calls a tool, reads the result, decides what to do next. Tools are just functions with a schema. That sounds small. In practice it means I can take a system we already integrate against — a PIM, an order service, a commerce API — expose exactly the operations an agent needs and nothing more, and reason about the blast radius the same way I reason about any integration.

The piece that changed how I scope this is the Model Context Protocol. MCP is a single contract between an agent and a system, and because it is a standard, one server works across agents and tools instead of being wired once into one bespoke app. This site runs a real one: it serves an MCP endpoint at tomborvan.com/api/mcp with profile resources and a tool that reads live site data.

# MCP endpoint — https://www.tomborvan.com/api/mcp
resources:
  profile://brief   # short bio
  profile://full    # full profile
tools:
  get_profile       # live data from the running site

It took an afternoon, and that is the point. MCP turns "give the agent access to our data" from a bespoke integration into a reusable one — which is exactly the line item clients underestimate. The Claude Agent SDK matters for the same reason: it packages the loop, the tool handling and the context management, so a team is assembling components rather than rebuilding the plumbing. And Claude Code has become my daily driver inside the delivery loop itself — reading a codebase, drafting the integration, writing the tests. The agent I ship and the tool I build it with share a lineage, and that shortens the distance between prototype and production more than any single feature does.

Where Foundry fits

Foundry — Microsoft's platform, formerly Azure AI Foundry — wins on a different axis, and it is rarely the model itself. Most of my enterprise clients already live inside Microsoft 365 and Azure. Their identity, their data governance, their compliance posture, their procurement — all of it is there already. When the agent runs on Foundry, it inherits that. I am not asking a security team to approve a new vendor and a new data path; I am extending an environment they already trust. On a large account, that difference can be the whole timeline.

The Microsoft Agent Framework is built for the case Claude's single-loop model handles less naturally: several agents, orchestrated. A planner that hands work to specialists, a supervisor that checks them, long-running processes that carry state. When a workflow genuinely needs several roles rather than one capable agent with good tools, that structure is worth having off the shelf instead of hand-rolled.

Two more parts of that stack do quiet, real work. Copilot Studio lets business users build their own automations — the finance lead who wants an assistant over their own documents does not need me for that, and should not. And Power BI is where the agents get measured. An agent whose cost and effect nobody can see is a liability; putting its runs, its spend and its outcomes next to the rest of the business's numbers is how it survives past the pilot.

What project managers get wrong

Here is the mistake, and I have made it. We scope agent projects like software and forget to operate them like operations.

Software has a comforting property: the same input returns the same output. You write acceptance criteria, you test against them, you sign off, you move on. An agent does not behave that way. The same request can take a different path twice. The model improves, or a provider updates it, and behaviour shifts underneath you. Cost is per run, not per licence. "Done" is not a state an agent reaches and then holds.

So I still scope the build like software — clear boundaries, defined tools, explicit acceptance criteria — but I plan to verify it like a running operation. Concretely, that changes the questions I ask during delivery:

• How do we sample and review real outputs after launch, not only before it?
• What is the human-in-the-loop path for the cases the agent should not decide alone?
• What does a single run cost, and who watches that number as volume grows?
• When the model changes, how do we notice before the client does?

None of that fits a fixed-scope, sign-off-and-leave contract cleanly, which is precisely why it gets skipped. The teams that succeed budget for the operating discipline up front — evaluation, monitoring, a review loop, a named owner — and treat it as part of the deliverable, not an afterthought the client discovers three months in.

Which is why I have stopped framing this as Claude versus Foundry. I reach for Claude when the job is composable and integration-shaped, and for Foundry when the client's centre of gravity is already Microsoft and the work needs orchestration and governance. But that choice is the easy part. The hard part is identical in both stacks, and it is not a model problem at all: can this organisation actually run the agent after I hand it over? The teams that can answer yes are the ones who scoped the operating, not just the building.

The model is a component. The discipline to operate it is the product.