Microsoft's Office 2019 apps for Mac will stop working next month, because the company isn't renewing a certificate that validates Office licenses. Owners of Office 2019 for Mac are being warned they'll have to purchase Office 2024 or a Microsoft 365 subscription if they want to continue editing documents.

Microsoft previously promised that "all your Office 2019 apps will continue to function," when it announced end of support in 2023. The company then quietly updated that support note last month to remove the mention of apps continuing to function, replacing it with "Rest assured that all your Office 2019 apps won't lose any data."

Starti …

Read the full story at The Verge.

Many organizations are already deploying agentic workflows. Some are still experimental, while others are running in production.

Once an AI agent can take action on behalf of a business, the question is no longer whether it’s useful, but what happens when something goes wrong.

It’s tempting to focus on blame: the AI vendor, the manager, the engineer, or the employee whose data informed the model. But you can’t wait until after a failure to start governing. Accountability needs to be designed into the system from the start through permissions, boundaries, monitoring, and traceability.

Enterprises are not only buying AI capability. They are buying trust and operational control. 

Think about the chain of command

Agentic systems need a defined place within an organization’s operating model. When an AI agent approves a purchase order or updates a customer record, it acts on behalf of a specific person or function, such as marketing or IT.

That ownership matters. Someone needs authority over the outcome: approving the business logic, monitoring behavior, and intervening when the system drifts. Governance does not mean watching every API call. It means clear accountability. Without it, responsibility disappears across the org chart.

Consider your boundary conditions

The flexibility of cloud LLMs makes it tempting to grant broad permissions upfront. In practice, that is where risk begins. A key governance question is not “Who is at fault if something leaks?”, but “Should this agent ever have been allowed to access this system at all?” Over-permissioning creates unnecessary exposure.

Governance at scale requires a consistent approach to guardrails, access management, and control across agents and workflows, one that scales as the number of agents, teams, and systems grows. JetBrains Central was built to address this: bringing governance into the development infrastructure itself, rather than treating it as something bolted on after AI workflows are already in production.

Treat agents like new hires. Don’t let an AI agent improvise on the refund policy or access HR systems without authorization. Instead, grant autonomy in increments. Make the agent adhere to narrow scopes and hard “never” rules until you’re sure it can handle more responsibility.

Build an audit trail that works

Traditional applications follow deterministic code paths. When something breaks, logs tell the story. LLM-based agents don’t behave that way. The same input can produce different outputs depending on context, the model, the system state, and even timing, making traceability essential.

A meaningful audit trail should capture: who initiated the action, the intent or workflow that triggered it, which systems and data were touched, what the agent returned or changed, whether policy was violated, the duration and the cost.

This is where tooling matters. At JetBrains, we treat this as a concrete product problem. An AI audit dashboard should enable inspection of behavior at the level of individual actions and workflows, without guesswork.

Keep a human in the strategic loop

For example, an agent that auto-approves invoices over $10k should surface each approval with a risk signal, the policy rule it matched, and a reviewer link, not just a timestamp in a log file. Human review matters, but some approaches are better than others. Blanket approval isn’t the way to go, nor is requiring manual sign-off for every action.

The solution is to design workflows with intentional checkpoints and risk scoring. Let the agent handle routine work autonomously, but flag high-impact actions for human review.

Organizations can gradually expand an agent’s autonomy, but only when there is clear evidence that controls are effective and the system continues to operate within policy. Thresholds should be driven by evidence, not instinct. This keeps humans involved where judgment matters, while allowing the system to scale.

Reduce blast radius and define responsibility

Two additional aspects are becoming central to enterprise trust:

• Isolation: Agents should operate within constrained environments: scoped credentials, limited blast radius, and rollback capability. If something goes wrong, the damage should be contained. This is classic fault isolation applied to autonomous systems, and it matters more, not less, when the actor is non-deterministic.

• Indemnification: The other question enterprises consistently raise is accountability when things break, especially around IP. A trusted vendor doesn’t just offer tools; it offers contractual and technical assurances that liability is scoped and risks are managed.

Governance is a product decision

Governance is not a bolt-on. It belongs in the architecture, the workflows, and the relationships a product creates. Organizations that treat governance as a core feature will move faster, resolve issues more cleanly, operate with clearer boundaries, and have the confidence to let AI agents do useful work without constant supervision.

Designing for accountability means that when something goes wrong, and eventually, something will, you already know who’s responsible, what the agent did, and how to fix it. That’s what makes agentic AI viable in the enterprise. And that’s where the real work begins.

We’re working with a select group of organizations to explore these challenges in practice. Become a JetBrains Central Design Partner here.

Introduction

As organizations move from AI-assisted applications to agentic workflows, MCP servers are becoming a critical integration layer between agents, tools, APIs, data sources, and enterprise systems. Azure API Management already helps teams bring MCP servers under enterprise governance. But as MCP adoption scales, platform teams need more than basic exposure. They need a way to package MCP servers for the right consumers, understand tool usage in detail, manage changes safely, and automate configuration across environments.

These are familiar API management challenges — and the same patterns that organizations already use for APIs can now be applied more deeply to MCP servers. We are excited to announce new generally available capabilities for MCP server management in Azure API Management:

• Add MCP servers to products to package and govern MCP capabilities for specific consumers
• MCP tool observability to trace tool usage, logs, errors, and payload context
• MCP server versioning to run multiple versions side by side and manage change safely
• Management API and Bicep support to automate MCP server configuration as part of CI/CD workflows

Together, these capabilities extend MCP server management in Azure API Management and help make MCP servers first-class managed resources — productized, observable, versionable, and automatable.

Why MCP server management matters

MCP gives agents a standard way to connect with tools and external capabilities. That standardization is powerful, but it also introduces a new operational surface for enterprises.

Without a management layer, teams can quickly run into questions such as:

• Which MCP servers are approved for use?
• Who can access each server?
• How do we expose MCP servers to different developer or agent audiences?
• How do we monitor tool calls, latency, errors, and cost?
• How do we run preview and production versions side by side?
• How do we automate MCP server configuration across environments?

These are not just developer experience questions. They are enterprise governance questions. With Azure API Management, MCP servers can now be managed using the same core patterns organizations already use for APIs: products, subscriptions, policies, observability, versioning, and automation.

What’s new

1. Add MCP servers to products

Azure API Management products are a proven way to package APIs for consumption. With this release, you can now add one or more MCP servers to APIM products as well. This makes it easier to expose MCP capabilities to specific consumers, teams, applications, or agent experiences using familiar product-based governance.

For example, a platform team can create a product for internal agents that includes approved MCP servers such as:

• Customer profile lookup
• Order status retrieval
• Knowledge base search
• Ticket creation
• Workflow automation tools

By adding MCP servers to products, teams can use familiar controls such as subscriptions, quotas, approval workflows, and access management to govern how MCP capabilities are consumed.

Why it matters: MCP servers are no longer isolated endpoints. They can be bundled, governed, and delivered as secure, consumable products.

2. MCP tool observability

As agents use MCP servers to discover and invoke tools, teams need more than basic traffic visibility. They need end-to-end trace context for each agent-to-tool interaction. With MCP observability in Azure API Management, teams can inspect key MCP-specific details, including:

• Operation context: whether the request was a tools/list or tools/call operation
• Session context: the MCP session ID through gen_ai.conversation.id
• Client context: MCP client name and version
• Protocol context: MCP protocol name and version
• Server context: MCP server name and version
• Access context: authentication type and API type
• Tool context: tool name and tool type for tool invocation traces
• Error context: error type and error message when a call fails
• Payload context: tool invocation arguments and results when payload logging is enabled

This is especially important for agentic workflows, where a single user request may trigger multiple tool calls across different systems. With APIM, MCP traffic can be traced, inspected, and monitored using the same operational practices teams already use across their API estate.

Why it matters: MCP servers are not just accessible through APIM — they are observable. Platform teams can trace tool calls, inspect errors, and understand MCP usage with the same operational discipline they expect from managed APIs.

3. Expose multiple MCP versions

Enterprise teams need safe ways to evolve MCP servers over time. With MCP server versioning in Azure API Management, you can expose multiple versions of the same MCP server side by side. This allows teams to run a stable GA version while introducing a preview or next version for early adopters.

For example:

• v1 can serve the majority of production traffic.
• v2 can be exposed to a subset of consumers for testing.
• Teams can monitor adoption, errors, latency, and behavior.
• Once the new version is validated, v2 can be promoted with confidence.

This pattern is especially useful when MCP tools evolve, schemas change, new capabilities are added, or teams want to validate agent behavior before rolling changes out broadly.

Why it matters: MCP servers can now follow a safer lifecycle model: preview, validate, route, promote, and retire.

4. Management API and Infrastructure as Code

MCP server management also needs to work at enterprise scale. With Management API and Infrastructure as Code support, teams can provision and configure MCP servers programmatically through Azure API Management APIs and automation pipelines. This allows platform teams to define MCP server resources as part of repeatable deployment workflows using tools such as Bicep, Terraform, ARM, REST APIs, and CI/CD pipelines.

Teams can automate configuration for:

• MCP server endpoints
• Runtime and transport settings
• Authentication configuration
• Metadata and ownership
• Versioning
• Product association
• Policies
• Environment promotion

This is critical for organizations that need consistent MCP governance across development, test, staging, and production environments.

Why it matters: MCP server management can now be automated, reviewed, deployed, and governed like the rest of your API platform.

How these capabilities work together

Individually, each capability solves an important operational need. Together, they create a complete management model for MCP servers in Azure API Management. A platform team can:

1. Register or expose MCP servers through Azure API Management.
2. Package them into products for specific consumers.
3. Apply access controls, subscriptions, quotas, and policies.
4. Observe tool-level usage, latency, errors, traces, and cost.
5. Run multiple versions side by side.
6. Promote changes safely.
7. Automate deployment through APIs and Infrastructure as Code.

This brings the full API management playbook to MCP. Instead of treating MCP servers as unmanaged agent extensions, organizations can operate them as governed enterprise resources.

Example scenario

Imagine a company building internal copilots for customer support, sales, and operations. Each copilot needs access to different tools:

• Customer lookup
• Order history
• Case management
• Knowledge search
• Refund workflows
• Escalation workflows

With MCP and Azure API Management, the platform team can expose these capabilities as MCP servers and organize them into products. The customer support copilot can subscribe to the support product. The sales copilot can subscribe to the sales product. Early adopters can be routed to a preview version of a tool. Operations teams can monitor usage, errors, latency, traces, and cost. Platform teams can automate the entire setup across environments. The result is a more governed and scalable way to bring MCP-based tools into enterprise agent workflows.

Getting started

To get started with MCP server management in Azure API Management:

1. Create or identify an MCP server you want to expose through Azure API Management.
2. Add the MCP server as a managed resource in APIM.
3. Add the MCP server to an APIM product.
4. Configure access, subscriptions, quotas, and approval workflows.
5. Enable observability to monitor tool-level usage and traces.
6. Use versioning to manage preview and production versions.
7. Use the Management API or Infrastructure as Code to automate configuration.

Conclusion

MCP is quickly becoming an important standard for connecting agents to tools and enterprise capabilities. But for MCP to succeed in production, organizations need more than connectivity. They need governance, lifecycle management, observability, and automation. With these new MCP server management capabilities in Azure API Management, platform teams can manage MCP servers using the same trusted patterns they already use for APIs.

MCP servers are now first-class APIM resources — productized, observable, versionable, and automatable. We are excited to see how customers use these capabilities to build the next generation of governed, enterprise-ready agentic applications.

The skills that survive every industry shakeup aren't the ones you can Google — they're softer, harder to name, and far more durable. In this episode, Jonathan explores principle-oriented thinking: the practice of stripping away the labels we attach to tools, roles, and even ourselves to see what something actually does at its core. It's the difference between handing your coding off to an agent and rethinking your entire workflow around what these new materials are truly capable of.

If you've been following along with our recent focus on durable skills, you know we've been hunting for the abilities that translate beyond this month, this year, or whatever AI does to our industry next. Today's skill doesn't have a tidy name you can search for — it's softer than that. Jonathan calls it "principle-oriented thinking": the habit of deconstructing the labels we put on things to understand their core components, properties, and capabilities. It's how NASA engineers turned a sock into a water filter on Apollo 13, and it's how forward-thinking engineers are reframing what AI can actually do rather than jamming it into a predetermined slot.

• Labels Are Useful Shortcuts — Until They Aren't: Every label, from "software engineer" to "sock," carries baggage, heuristics, and presupposition. That's not a flaw — labels are how we move through the world quickly. But when a label is the only lens you have, it quietly caps how much value you can get out of the thing you're looking at.
• The Apollo 13 Sock: When the crew needed to fix a life-threatening problem with mismatched parts, the engineers on the ground had to forget what a sock was for and ask what it actually is — a piece of cloth with tensile strength, flexibility, and filtering properties. Strip the assumption that it goes on a foot, and a whole new set of uses opens up.
• Stop Slotting AI Into Old Roles: The common move is to take one responsibility — coding, debugging, refactoring — hand it to an agent, and keep everything else the same. That works, but it's low-leverage. The more powerful approach starts by asking what the agent is fundamentally capable of, then rebuilding the workflow around those raw materials.
• See Things as Materials, Not Fixed Functions: When you deconstruct out from under a label, tools and concepts start to look like craftable raw materials. You can then combine them in new, valuable ways they haven't been combined before — alloying old methods with new capabilities to create properties neither had on its own.
• Reason From Properties, Not Personas: Ask what the actual properties of an LLM are. Non-determinism isn't a bug to apologize for — it's a property you can exploit. The existence of many different models is a property too, which is exactly what makes adversarial review possible. That's principle-oriented thinking applied to agents.
• Extend the Latticework: Charlie Munger talked about a latticework of mental models that weave together rather than sit in isolation. The durable skill isn't quarantining your concept of "AI" off to the side — it's grafting a new section onto the existing tapestry and letting it reshape everything you already understood.
• Episode Takeaway: Look at how you spend your time and ask new questions of it. What is the material here? What kind of thinking does the agent actually do? What can a human do that an LLM can't — and the other way around? That's how you avoid believing a sock is only ever good for a foot.

🙏 Today's Episode is Brought To you by: Unblocked

Your coding agents have access to your code, your repos, and probably a pile of connected MCPs filling up their context — but access isn't the same as good context, and a bloated context window can actually degrade the very reasoning you're relying on. Agents don't know your architectural decisions, your team's patterns, or why an API was shaped the way it was, so they look in the wrong place and deliver bad outputs you then spend time and tokens correcting. ● Unblocked is the smart context layer your agents are missing. ● Instead of ingesting everything and getting lost, it builds reasoning over shared context. ● It turns code, docs, tickets, and conversations into actionable context — so engineers move faster, agents make better plans and write higher-quality code, and you burn fewer tokens and fewer correction loops. If you're running Claude Code, Cursor, or any agentic workflow, it's worth a look. A free three-week trial is available at getunblocked.com/developertea.

📮 Ask a Question

If you enjoyed this episode and would like me to discuss a question that you have on the show, drop it over at: developertea.com.

📮 Join the Discord

If you want to be a part of a supportive community of engineers (non-engineers welcome!) working to improve their lives and careers, join us on the Developer Tea Discord community today!

🗞️ Subscribe to The Tea Break

We are developing a brand new newsletter called The Tea Break! You can be the first in line to receive it by entering your email directly over at developertea.com.

🧡 Leave a Review

If you're enjoying the show and want to support the content head over to iTunes and leave a review!

What can go wrong with machine learning? While at NDC in Toronto, Richard chatted with Megan Robertson about her experience with machine learning projects, often using retail datasets, and where they can go wrong. Megan talks about getting clear expectations and metrics for projects, so you know when you succeed, but then digs into the specifics of problems in machine learning, such as overfitting on test data. Your results are only as good as the data you put in, so a lot of focus goes into building good sets, carefully developing the model with those sets, and using techniques like cross-validation to ensure the model is behaving appropriately. There's a lot that can go wrong, but the results with an effective model can be very powerful - it is worth the effort!

Links

• Cross Validate Model
• Megan's Website

Recorded May 7, 2026

This week, we launched the Field Guide to Grid Lanes at gridlanes.webkit.org.

If you ever bookmarked the CSS Tricks Complete Guide to Flexbox, HTML5 Rocks, or CSS Zen Garden, a guide like this might feel familiar. It’s designed to be an easy introduction, a reference guide — and just plain fun.

The interactive playground

At the top is a live, editable Grid Lanes layout. Switch between Waterfall and Brick. Try preset layouts. Drag the slider labeled “Flow tolerance” and click “Play tab order” to understand the impact of flow-tolerance.

Resize the demo browser window to test responsive behavior without resizing your whole window. Edit the CSS directly. Copy the code you create.

The cheat sheet

Next is the Field Guide itself — a single-page reference for every property, value, and option.

It has four sections:

• Grid Lanes Basics — display: grid-lanes, plus the difference between waterfall and brick layouts
• Options for Lane Definitions — Grid track-sizing with fr units, fixed lengths, percentages, auto, min-content & max-content, fit-content(), minmax(), repeat(), and auto-fill vs auto-fit
• Options for Placement & Spacing — flow-tolerance, gap, spanning tracks, and explicit placement
• Good to Know — info about source order, progressive enhancement, and switching layouts at different breakpoints

The demos

To showcase the possibilities of Grid Lanes, we created six demos, each available in several variations:

• Photos — just images, in a variety of aspect ratios
• Recipes — components containing both flexible images and varying lengths of text
• Newspaper — longer passages of text, with a few images (and a lot of CSS puns)
• Mega Menu — lists of very short text
• Timeline — text in brick layout
• Pinboard — mixed media

Each demo opens with a floating control panel.

“Layout” offers a dropdown of variations — showing off what Grid Lanes can do, and comparing it to Flexbox, Multicolumn, and Grid. “Numbers” shows item order. “Flow tolerance” lets you experiment with its effects. The code panel displays the key layout CSS.

“Hide controls” puts the focus on the demo itself. To get the controls back, click the gear that appears in the lower-right corner.

Working with Safari’s developer tools

Web Inspector knows about Grid Lanes, too. Toggle “Order Numbers” to reveal overlays marking the DOM order of items. These numbers are extremely useful when experimenting to find the best flow-tolerance value for your content.

Learn more by reading New Safari developer tools provide insight into CSS Grid Lanes.

What about other browsers?

Grid Lanes works today in Safari 26.4+. For the latest information about other browsers, check Can I Use. For progressive enhancement guidance, read When will CSS Grid Lanes arrive? How long until we can use it?

Made by the people who shipped it

The Field Guide was built by the same team behind Grid Lanes. We hope this is a fun experience that makes Grid Lanes easy to learn. Bookmark it, share it with colleagues, and let us know what you make.

Visit the Field Guide →

Feedback

We’d love to hear from you. Find us online: Jen Simmons on Bluesky / Mastodon, Saron Yitbarek on Bluesky / Mastodon, and Jon Davis on Bluesky / Mastodon. You can follow WebKit on LinkedIn.