An anonymous reader shares a report: Microsoft Azure CTO Mark Russinovich and VP of Developer Community Scott Hanselman have written a paper arguing that senior software engineers must mentor junior developers to prevent AI coding agents from hollowing out the profession's future skills base. The paper, Redefining the Engineering Profession for AI, is based on several assumptions, the first of which is that agentic coding assistants "give senior engineers an AI boost... while imposing an AI drag on early-in-career (EiC) developers to steer, verify and integrate AI output." In an earlier podcast on the subject, Russinovich said this basic premise -- that AI is increasing productivity only for senior developers while reducing it for juniors -- is a "hot topic in all our customer engagements... they all say they see it at their companies." [...] The logical outcome is that "if organizations focus only on short-term efficiency -- hiring those who can already direct AI -- they risk hollowing out the next generation of technical leaders," Russinovich and Hanselman state in the paper.

Read more of this story at Slashdot.

Claude Code is a developer tool for developers. And yet, over the last year and especially the last few months, the team at Anthropic has seen a huge number of people, across industries and disciplines, figure out how to access their terminal so that they could build new stuff too. Few AI products have found true product-market fit the way Claude Code has. But how did that happen? And are we ever going to get out of the terminal?

On this episode of The Vergecast, Anthropic's Bo …

Read the full story at The Verge.

If you’ve built a multi-agent workflow, you’ve probably seen it fail in a way that’s hard to explain.

The system completes, and agents take actions. But somewhere along the way, something subtle goes wrong. You might see an agent close an issue that another agent just opened, or ship a change that fails a downstream check it didn’t know existed.

That’s because the moment agents begin handling related tasks—triaging issues, proposing changes, running checks, and opening pull requests—they start making implicit assumptions about state, ordering, and validation. Without providing explicit instructions, data formats, and interfaces, things won’t go the way you planned. 

Through our work on agentic experiences at GitHub across GitHub Copilot, internal automations, and emerging multi-agent orchestration patterns, we’ve seen multi-agent systems behave much less like chat interfaces and much more like distributed systems.

This post is for engineers building multi-agent systems. We’ll walk through the most common reasons they fail and the engineering patterns that make them more reliable.

1. Natural language is messy. Typed schemas make it reliable.

Multi-agent workflows often fail early because agents exchange messy language or inconsistent JSON. Field names change, data types don’t match, formatting shifts, and nothing enforces consistency.

Just like establishing contracts early in development helps teams collaborate without stepping on each other, typed interfaces and strict schemas add structure at every boundary. Agents pass machine-checkable data, invalid messages fail fast, and downstream steps don’t have to guess what a payload means.

Most teams start by defining the data shape they expect agents to return:

type UserProfile = {
  id: number;
  email: string;
  plan: "free" | "pro" | "enterprise";
};

This changes debugging from “inspect logs and guess” to “this payload violated schema X.” Treat schema violations like contract failures: retry, repair, or escalate before bad state propagates.

The bottom line: Typed schemas are table stakes in multi-agent workflows. Without them, nothing else works. See how GitHub Models enable structured, repeatable AI workflows in real projects. 👉

2. Vague intent breaks agents. Action schemas make it clear.

Even with typed data, multi-agent workflows still fail because LLMs don’t follow implied intent, only explicit instructions.

“Analyze this issue and help the team take action” sounds clear. But different agents may close, assign, escalate, or do nothing—each reasonable, none automatable.

Action schemas fix this by defining the exact set of allowed actions and their structure. Not every step needs structure, but the outcome must always resolve to a small, explicit set of actions.

Here’s what an action schema might look like:

const ActionSchema = z.discriminatedUnion("type", [
  { type: "request-more-info", missing: string[] },
  { type: "assign", assignee: string },
  { type: "close-as-duplicate", duplicateOf: number },
  { type: "no-action" }
]);

With this in place, agents must return exactly one valid action. Anything else fails validation and is retried or escalated.

The bottom line: Most agent failures are action failures. For reducing ambiguity even earlier in the workflow—at the instruction level—this guide to writing effective custom instructions is helpful. 👉

3. Loose interfaces create errors. MCP adds the structure agents need.

Typed schemas, constrained actions, and structured reasoning only work if they’re consistently enforced. Without enforcement, they’re conventions, not guarantees.

Model Context Protocol (MCP) is the enforcement layer that turns these patterns into contracts.

MCP defines explicit input and output schemas for every tool and resource, validating calls before execution.

{
  "name": "create_issue",
  "input_schema": { ... },
  "output_schema": { ... }
}

With MCP, agents can’t invent fields, omit required inputs, or drift across interfaces. Validation happens before execution, which prevents bad state from ever reaching production systems.

The bottom line: Schemas define structure whereas action schemas define intent. MCP enforces both. Learn more about how MCP works and why it matters. 👉

Moving forward together

Multi-agent systems work when structure is explicit. When you add typed schemas, constrained actions, and structured interfaces enforced by MCP, agents start behaving like reliable system components.

The shift is simple but powerful: treat agents like code, not chat interfaces.

Learn how MCP enables structured, deterministic agent-tool interactions. 👉

The post Multi-agent workflows often fail. Here’s how to engineer ones that don’t. appeared first on The GitHub Blog.

I was skeptical when I first ran OpenClaw, it looked like just another AI tool riding the hype. Turns out, it’s not.

After experimenting with it and extending its messaging, I also found out that much of its core power (its AI agent architecture and human-in-the-loop interactions) can be recreated with off-the-shelf tools like the Agents SDK and Messages API.

In this post, I’ll share what I learned from using OpenClaw, explain why messaging is what makes autonomous agents truly work, and show how developers can leverage existing tools to build something similar without starting from scratch.

The agent that broke the internet 

In just three months, it’s taken off on GitHub, earning 200k stars in 84 days and thousands of forks. By mid-February, SecurityScorecard was tracking over 240k instances running in the wild.

With LLM token costs of $5-50 per instance, the project is already accounting for millions in inference spending, and it’s even causing Mac mini shortages as people rush to self-host OpenClaw. (You can actually run it on much cheaper hardware, which makes the story even crazier.)

The hype around the project is undeniable, even with a steep barrier to entry (users must install and run the server software themselves) and despite ongoing security concerns and reported vulnerabilities. 

Why I think the hype is justified

OpenClaw’s AHA moment is hard to ignore. It shows there’s real demand for autonomous AI agents, ones that free users from being stuck in a chat window on sites like chatgpt.com.

I’ve always felt that calling those website chatbots “agents” was a stretch – they’re more like conversation buddies than AI doing real work for you.

True agents, in my view, should run in the background, acting and reacting on their own without forcing users to stay glued to a single site. That’s exactly the experience OpenClaw delivers.

The “hold my beer” moment

As a developer, I was curious. Running OpenClaw was impressive, but I wanted to know: how does it actually work? And even more, what would it take to recreate its wow factor myself? Let’s break it down.

The first key ingredient is an AI agent, and I mean this in a very specific sense.

As Anthropic puts it, agents are systems where the LLM controls the program’s flow, instead of classic code deciding when to call the LLM. At a high level, agent apps are basically a while loop that calls the LLM and hooks in all the tools the AI might need. With the rise of MCP, connecting these tools has become easier and more standardized.

On the surface this seemed simple, but I quickly got bogged down in a bunch of edge cases and details to implement. Luckly, we don’t need to reinvent the wheel here. There are ready to use SDKs wrapping all the agent logic, recently renamed Agents SDK being a prime example. That got the AI agent part covered. But there was still one secret ingredient missing.

Users still need to approve important actions

Let’s go back to the OpenClaw user experience. Even when freed from a chat website, agents still need a way to stay in touch with their users. 

The human-in-the-loop approach remains essential for responsible AI: no one should discover their agent’s spending spree on a month-end bank statement. Critical actions still need user approval, and important results still need to be communicated. 

That’s why messaging channels are the very first feature highlighted in OpenClaw’s documentation. 

Messaging is what makes autonomous AI agents actually work for you. It lets them check in, keep you in the loop, and get your approval for important actions, without forcing you to refresh a page or babysit a chat window. It’s what gives you peace of mind, convenience, and, most importantly, control.

Cheat codes for messaging

Back to coding.

Connecting to mobile operators or chat services might sound intimidating at first, but I had a secret weapon: I work at Infobip. Luckily, you don’t need that advantage, anyone can pick up the unified Messages API and start sending and receiving messages on users’ phones.

With connectivity sorted, all I had to do was figure out how to hook the agent up to it.

There are few flows:

• First up is passing new messages from users to the agent as prompts; basically, launching new tasks.
• Secondly, the agent needs a way to send out reports. MCP servers work best here, as they are easy to integrate and trigger by LLMs. 
• Finally, sending the agent’s output to the phone and getting the user’s feedback or confirmation. This is the all-important human-in-the-loop part! Historically interpreting free form input from users might have been hard, but these days we can easily pass it to an LLM and ask it to summarize the intent: does the user approve of the suggested action or not? Easy. 

And with that my experiment was over. 

Do a few off-the-shelf components (like the Agents SDK and Messages API) replicate the full OpenClaw experience? Not entirely. But they can help you kickstart a new project, up to the point where you can focus on your core features. And that’s the part that really matters.

It’s time to pay attention to autonomous agents

If you’re already working in AI (or thinking about it) autonomous agents are where things are moving. OpenClaw shows the demand is real, and the tools to build agents that can reason, act, and communicate are already here. Messaging isn’t just nice to have; it’s how your agent stays useful without you having to babysit it. With unified messaging APIs and MCP, sending updates and notifications is easy, so you can focus on shaping how your agent thinks and acts.

The post I Tried Recreating OpenClaw – And The Hype Is Real appeared first on ShiftMag.

Ahead of Mobile World Congress, where global leaders, governments, and industry convene at the world’s largest connectivity event, Microsoft is marking a major milestone in our efforts to expand digital access worldwide. In 2022, we made a bold commitment to expand internet access to 250 million people by the end of 2025. Today, we are proud to share that we have met and exceeded that goal, extending connectivity coverage to over 299 million people worldwide, including more than 124 million across Africa.

This milestone represents more than a number. It reflects more than a decade of sustained collaboration with governments, nonprofits, local connectivity providers, and development partners around the world. Together, we have worked to reach communities where access has historically been limited, building pathways to education, healthcare, economic opportunity, and digital participation.

Reaching this milestone is also a moment of reflection and renewal. Building on years of progress, Microsoft is evolving its approach to digital access to focus not only on coverage, but on adoption, enablement, and long-term participation in the AI economy.

As part of this next chapter, we are announcing a new collaboration with Starlink. This collaboration expands the set of tools available to help deliver digital access in rural, agricultural, and hard-to-reach communities. Combined with local delivery partners and community institutions, it strengthens the foundation for AI-ready communities around the world.

Why digital access matters in the AI era

Despite continued progress, 2.2 billion people globally remain offline, and many more face barriers related to affordability, reliability, or access to relevant digital services. These gaps already limit opportunity and risk widening as AI becomes more central to how economies grow and societies function.

At Mobile World Congress 2024, Microsoft Vice Chair and President Brad Smith shared our AI Access Principles, underscoring that electricity and connectivity are essential foundations for an inclusive AI economy. Since then, the pace of change has only accelerated. In fact, Microsoft’s 2025 AI Diffusion Report shows that AI is being adopted faster than any general-purpose technology in history, yet adoption remains uneven. As the data illustrates, adoption in the Global North is accelerating faster than in the Global South. Differences in infrastructure, access to tools, and digital readiness all contribute to a growing divide between higher-income and lower-income economies.

This graphic from the 2025 AI Diffusion Report reinforces a clear insight: access to AI alone is not enough. For communities to participate meaningfully in the digital and AI era, connectivity must be paired with reliable energy, affordable devices, digital skills, and technologies designed for real-world use. Where these conditions exist, adoption follows. In Zambia, for example, country-wide generative AI adoption is 12 percent, but among those with internet access, it rises to 34 percent.

Deepening Microsoft’s approach to digital access

Building on what we have learned, Microsoft is advancing a more holistic digital access model that recognizes connectivity as only one part of a broader system. In practice, this means collaboration to deliver not only internet access but also more reliable energy infrastructure, access to water where relevant, devices, digital skills, and cloud and AI tools, all designed and deployed for the communities they serve. By working across organizations and governments to address these foundational needs in parallel, this approach helps ensure that digital access is usable, durable, and capable of supporting real-world outcomes.

A central focus of this work is community-based access models that are financially sustainable, scalable, and aligned with national development priorities. These models bring together local institutions such as schools, health facilities, cooperatives, and community hubs and are implemented in partnership with governments, businesses, nonprofits, and development finance organizations. By integrating infrastructure, enablement, and financing from the outset, these holistic programs can help unlock long-term investment, support responsible growth, and enable communities to fully participate in the digital and AI economy.

Digital access directly complements Microsoft’s Community First AI Infrastructure approach by providing the foundation that enables AI to be adopted, used, and trusted by communities everywhere.

Partnering to deliver impact at scale

Progress at this scale is only possible through strong partnerships rooted in local delivery, community trust, and long-term sustainability. Microsoft’s work to extend connectivity to more than 299 million people has been built alongside partners who understand the realities of last-mile deployment and digital adoption.

In Africa, Microsoft works with partners such as Cassava Technologies to expand regional digital infrastructure and drive high-quality internet access across South Africa, Malawi, Kenya, and Zambia. Collaborations with local providers like Tizeti deliver affordable, reliable connectivity through solar-powered Wi-Fi networks across Nigeria and Ghana.

In Latin America, Microsoft’s partnership with Anditel focuses on expanding internet and energy access for rural and agrarian communities in Colombia through locally led models aligned with national priorities. In India, Microsoft works with AirJaldi to pair affordable connectivity with digital skills training and practical pathways for use, helping communities move beyond basic access toward meaningful adoption.

These partnerships made reaching the 250 million milestone possible. They also reflect a principle that continues to guide our work. Lasting digital access is built with communities, not for them.

Expanding the portfolio: Collaboration with Starlink

Building on this foundation, Microsoft continues to expand and diversify its portfolio to reach communities where traditional infrastructure alone cannot meet demand.

Through our collaboration with Starlink, Microsoft is combining low-Earth orbit satellite connectivity with community-based deployment models and local ecosystem partnerships. This is intended to expand the set of tools available to deliver digital access while remaining firmly embedded in a holistic, partnership-driven approach.

Kenya offers an early example of this model in practice. Working with Starlink and local internet service provider Mawingu Networks, Microsoft is supporting connectivity for 450 community hubs across rural and underserved regions, including farmer cooperatives, aggregation centers, and digital hubs. These deployments combine satellite connectivity with digital skills, tools, and ecosystem coordination to support agricultural productivity, access to markets, and adoption of digital and AI-enabled services.

Beyond 250 million: Building AI-ready communities

Surpassing the 250 million connectivity milestone is a moment to celebrate. It is also a starting point for what comes next.

The next chapter of Microsoft’s digital access work is planned to focus on ensuring that access translates into adoption, use, and long-term opportunity. By continuing to partner with governments, development finance institutions, nonprofits, and private-sector partners, and by expanding into energy access, financing mechanisms, and community-first AI solutions, Microsoft is working to ensure that everyone, everywhere, can participate in the digital and AI economy.

 

The post Celebrating 250 million: Empowering communities to enable the global AI economy appeared first on Microsoft On the Issues.

Many vendors, or even some IT infrastructure landscapes, may want the EXE installer icon changed. This is done for many reasons, including branding and marketing purposes, but it may also give users confidence that the downloaded installer is from the vendor. [...]