Welcome back to another episode of The Download with Christina Warren! This week, we cover all the massive developer news from Microsoft Build, including the new Surface RTX Spark Dev Box and updates to Windows 11. We also dive into the new GitHub Copilot desktop app features, like cloud and local sandboxes, and the arrival of Anthropic's Claude Fable 5 model. Plus, hear the latest on GitHub Universe 2026 and a nostalgic open source project of the week.
#GitHubCopilot #GitHub #Claude
— CHAPTERS —
00:00 Intro 00:34 Microsoft Build recap 01:53 Windows 11 developer updates 02:51 GitHub Copilot desktop app 04:08 Copilot cloud and local sandboxes 04:37 New Microsoft AI models 05:08 GitHub Universe 2026 05:38 Project spotlight: GentleOS 06:43 Anthropic releases Claude Fable 5 08:30 Play Pokémon Emerald in your browser 08:58 Outro
About GitHub It’s where over 180 million developers create, share, and ship the best code possible. It’s a place for anyone, from anywhere, to build anything—it’s where the world builds software. https://github.com
.NET 11 Preview 5 focuses on under-the-hood runtime performance gains, streamlined APIs and language features that reduce boilerplate, plus built‑in security checks and incremental ASP.NET Core and EF Core improvements aimed at everyday developer productivity.
This week Miguel Fierro, a former Microsoft principal researcher who recently founded his own company, RecoMind, joined data and AI evangelist Christina Stathopoulos to talk about the state of recommendation systems. Christina also ran through the latest AI news she’s been watching, from Anthropic’s continued rise to responsible AI, announcements from Google’s I/O 2026 conference, and (continuing the discussion from last week) the growing backlash against tokenmaxxing as a productivity metric. Here are three takeaways from the conversation.
Recommendation systems are a bigger deal than most companies realize
Miguel has spent the better part of a decade building recommendation systems for enterprise customers at Microsoft, and he thinks most companies are leaving a lot on the table by not paying closer attention to recommendations. Amazon generates roughly 35% of its revenue through recommendations. Netflix attributes 75% of content consumption to them. Best Buy credits recommendations with 24% of revenue. TikTok’s entire user experience is a recommendation engine. And yet many large retailers he worked with at Microsoft weren’t investing seriously in the area, often because they weren’t tracking the value it was generating.
The gap between the top tier and everyone else is wide and getting wider. The most advanced systems today treat user behavior as a sequence prediction problem, similar to how large language models predict the next token. Rather than just encoding clicks, they encode all user actions into embeddings, run sequences through those representations, and use huge 1.5 trillion-parameter models to predict what a user will want next. That’s not something a mid-tier retailer can replicate today, but it signals where the field is heading.
Even if you don’t work in a top well-resourced company, you should still pay attention to the convergence of search and recommendations into a single personalized retrieval layer and the early application of foundation models to recommendation problems. Netflix has built what Miquel described as the only published foundation model in this space; Meta is rumored to be developing one as well. The barrier is data, particularly for smaller organizations. Unlike text, behavioral interaction data isn’t publicly available, so building at that scale requires both proprietary datasets and serious compute.
If you want to get your hands on state-of-the-art implementations, including knowledge graph-based approaches, without starting from scratch, Miguel suggested the open source Recommenders library, originally developed at Microsoft and now housed under the Linux Foundation, as a practical entry point.
The agent hype has a recommender-shaped hole in it
Miguel drew a distinction between true sales agents and what most companies offer today, which are usually just conversational agents. A conversational agent responds to what you say. An agentic sales system understands a customer, anticipates what they want, and surfaces the right product or offer at the right moment—and that requires a recommendation system baked in.
If your “agent” is a chatbot with access to a knowledge base, it’s not doing recommendation. Recommendation systems need training data, a retrieval layer, and a personalization model, none of which you get for free from a foundation model API. A language model can answer questions about a product catalog, but it can’t offer up personalized recommendations unless it also has a model of the customer’s preferences, history, and likely next action. Most companies don’t have the infrastructure in place to make that possible. . .yet.
The responsible AI conversation has left the research community
What’s notable about the responsible AI conversation right now is the range of institutions offering their perspective. Anthropic, alongside announcing a funding round pushing its valuation toward $1 trillion, urged a global pause on AI development tied to the risk of recursive self-improvement: systems that can design and develop their own successors. The Future of Life Institute published The Better Path for AI, a framework arguing for capability development oriented toward human benefit rather than human replacement. And the pope issued a formal encyclical focused on AI and the common good.
None of these institutions is making the same argument, but the convergence of their attention matters. Responsible AI used to be a specialized conversation happening largely within research labs and a small set of policy organizations. It’s now a topic where major AI companies, religious institutions, and civil society groups are all staking out public positions in the same news cycle.
For the technical community, this creates both pressure and opportunity. “We’re thinking about safety” is no longer a sufficient posture; external scrutiny is intensifying from directions that don’t share the field’s assumptions or vocabulary. But the broader conversation creates real demand for practitioners who can translate between what responsible AI actually requires in practice and what policymakers, executives, and institutions are trying to figure out. That translation work is increasingly where the field needs people.
What’s next
Join us Monday morning for the next episode of This Week in AI, where YK Sugi and John Lindquist will break down the massive structural and financial shifts reshaping the technology industry. (They’ll also chat about the recent release of Claude Fable 5.) And on July 23, Christina will be hosting the AI Superstream on AI harnesses, a four-hour event focused on agentic AI and the frameworks practitioners need to move from models to agents. Both are free to attend. Register now to save your seat.
We’ll continue to publish our takeaways here on Radar each Friday and share full episodes on YouTube, Spotify, Apple, or wherever you get your podcasts.
Capacity is one of the hardest problems because it sits at the knotty, gnarled-up intersection of so many other hard problems.
What began as an internal hackathon project, where a small team at Infobip set out to create and launch a marketing campaign for a fictional chocolate brand using AI agents, evolved into the company’s first MCP servers running in production.
At Devoxx UK, Filip Srnec, Principal Engineer at Infobip and lead of the company’s MCP team, explained how they built the OpenAPI MCP Spring Boot Starter, a tool that turns any OpenAPI-documented API into a fully capable MCP server, without the need for rewrites or custom integration code.
Why not just build custom MCP servers?
Filip kicked off his talk by asking the audience if anyone had an HDMI adapter so he could point out a common challenge in technology:
Protocols evolve, and systems don’t necessarily upgrade in sync.
Most of the systems AI agents need to interact with today already expose REST APIs. REST APIs helped us build the world that we now today. Mobile apps, smart devices, command-line tools, and interactive user interfaces all rely on them, running on top of decades of standards, tooling, and shared knowledge. Now AI agents need a way to use that same infrastructure.
MCP, announced by Anthropic in November 2024, was positioned as “a USB-C port for AI applications.” That immediately raised the question of whether every existing API (the HDMI cable) would now need custom glue code (an adapter) to become agent-accessible.
Infobip’s answer was no.
The OpenAPI connection
The breakthrough came when the team compared the structure of an MCP tool with an OpenAPI operation. The two map directly onto each other at the field level. MCP tools define elements such as a name, title, description, input schema, and annotations, while OpenAPI operations include an operation ID, summary, description, parameters, and request body. Comparing the two side by side shows that most OpenAPI operation metadata already has a direct equivalent in MCP:
The name can be an operation ID, because operation ID uniquely identifies an operation in the specification. For a title, we can use a summary. Description is obvious. We have a way to define the input schema by combining parameters and the request body.
Infobip already had OpenAPI specifications for all of its public APIs. Since those specifications were powering the company’s API platform and SDK generation process, building a bridge to MCP made more sense than creating custom servers from scratch.
Let’s take a look at how the OpenAPI MCP Spring Boot Starter works in two phases.
How the framework works
The process begins by reading the OpenAPI specification and turning it into MCP-compatible tool definitions. Because the connection is dynamic, updates to the API are reflected on the MCP side as well.
At runtime, on every tool call, the framework validates credentials, maps tool arguments to HTTP requests, enriches and forwards those requests to the downstream API, handles errors, and returns the result to the agent.
The setup is intentionally minimalistic. It requires only the OpenAPI specification URL and the base URL of the API being exposed. As Filip explained:
You just point it at your OpenAPI specification, and your API instantly becomes an MCP server. This is something that we’ve been running in production for months now.
Building a bridge from API to MCP makes more sense than creating new MCP servers. Credit: Devoxx UK
Not every endpoint should become a tool
Filip pointed out that exposing an entire API surface to agents is a bad idea. Irrelevant operations add noise, increase costs, and can mislead the model. A larger surface also extends the potential attack surface for prompt injection.
The framework tackles this through an OpenAPI filter chain. Before tools are exposed through MCP, developers can adjust the specification. That means removing endpoints, tweaking schemas, or changing how operations are presented. The good thing is that this approach works even when the API is maintained by someone else.
One example involved OpenAPI’s discriminator feature. It is commonly used to select different schemas based on a property value, making server-side validation more flexible. The catch is that discriminators are not valid JSON Schema constructs, while MCP tool definitions require strict JSON Schema compliance. To solve the problem, the framework automatically rewrites discriminator-based schemas into oneOf structures that MCP clients can consume without issue, Filip explained.
Unfortunately, exposing the right tools solves a part of the problem. For an AI agent to use a tool correctly it needs to understand both what the tool does and when to use it.
Naming, descriptions, and making agents actually use your tools
LLMs select tools based on names and descriptions and both matter more than most developers realize.
The framework gives developersseveral ways to name tools. They can keep the original operation ID, use a simplified version with special characters removed, or generate a name from the API endpoint itself when no operation ID is available. It also includes safeguards for clients that impose strict limits on name length.
Tool descriptions require just as much attention because every description from every connected MCP server is loaded into the model’s context. These descriptions need to be concise and easy for AI agents to interpret. The framework can enrich them with summaries and examples from the OpenAPI specification, which Filip highlighted as especially useful when matching requests to input schemas.
The tools, however, still need to work with existing authentication and authorization systems.
Solving authentication without reinventing it
Authentication has been one of the more debated aspects of MCP and because of that the framework takes a pragmatic approach by relying on existing mechanisms rather than new ones. Filip explained:
Your API already knows how to perform authentication and authorization. It knows how to reject bad credentials.
Instead of introducing a separate authentication layer, the framework forwards credentials to a configurable endpoint that already handles it. As a result, any method supported by the underlying API, whether API keys, basic authentication, or JWTs, works through the MCP server as well.
For OAuth, the framework proxies OpenID configuration calls and authorization requests to a configured OAuth server, and performs automatic scope discovery from the OpenAPI security definitions:
To have full OAuth support, you need to point it at your OAuth server. And you’ll get minimal scope discovery automatically directly from the framework.
It is important to mention that building the features was, once again, only part of the story. The team was also developing the framework while the MCP ecosystem itself was still taking shape.
Best way to explain API to MCP flows is, surprisingly, with cables and adapters. Credit: Devoxx UK
Building on a moving train
Filip was candid about the challenges the team faced. As Infobip was building and shipping the framework, the MCP specification evolved, with changes affecting everything from transport mechanisms and authentication flows to client behavior:
Sometimes we need to pick between features and compatibility. We decided that we wanted to move fast. We wanted to be in that space. The spec was still being written while we were shipping production code.
Along the way, the team had to deal with a growing list of compatibility issues. Different clients imposed different limits on tool name lengths, some sent nested objects as escaped strings instead of valid JSON, and OAuth implementations often behaved differently despite following the same specification:
My point here is that sometimes you can’t wait for the ecosystem to mature. You ship and you adapt.
The demo
Filip wrapped up the session with a demonstration. Using the framework, he connected an OpenMeteo weather forecast server and Infobip’s production SMS MCP server, then showed how an AI agent could retrieve the next day’s weather forecast for London, generate a short summary, and send it as a text message. The point was how quickly an existing API could be turned into an MCP-compatible service. As Filip put it:
Your API may already be a hidden MCP server. Try to use this framework, point it at your specification, and ship it.
And now to the reason I wrote this post: including the word “navigation” in your <nav> labels. There’s no need. If we did, we’d hear something like “Navigation, Primary navigation”. Not the end of the world, but unnecessarily repetitive for screen reader users.
One of those nuances to keep in your back pocket when writing for screen readers. Reminds me, too, that there’s no need to say something like “image” when describing one in the alt text. That’s sorta implied. While I’m no screen reading native, I imagine these sorts of things are minor pet peeves that, given a little love and consideration, make navigating that much more enjoyable.
Log in
