Skip to main content

Microsoft Foundry Tackles the AI Agent Tool Problem Nobody Talks About

AIOps, applications, Tabnine AIOps
AIOps, applications, Tabnine AIOps

Building AI agents sounds straightforward until you actually do it. You need an agent to onboard a new employee. It has to create an Entra ID account, provision GitHub access, spin up cloud resources, create tasks in Azure DevOps, and send a welcome message in Teams. Five tools. Five different authentication models. Five different teams are managing those tools.

Now multiply that across every agent your organization is building.

That’s the problem Microsoft is addressing with Toolboxes in Foundry, now available in public preview.

What Toolboxes Actually Do

A Toolbox is a named, reusable bundle of tools managed in Microsoft Foundry. You define your tools once, configure authentication centrally, and expose everything through a single MCP-compatible endpoint. Any agent that can consume an MCP endpoint can use a Toolbox — regardless of the framework it was built on.

The endpoint looks like this:

https://zava.services.ai.azure.com/api/projects/<project>/toolbox/<toolbox-name>/mcp?api-version=v1

One endpoint. Every tool in the bundle. No per-tool wiring.

Today, Toolboxes support built-in tools like Web Search, Code Interpreter, File Search, and Azure AI Search. They also support Model Context Protocol (MCP), Agent-to-Agent (A2A), and OpenAPI integrations. Authentication is handled centrally through OAuth identity passthrough and Microsoft Entra managed identity — agents don’t manage credentials themselves.

Why This Matters for DevOps Teams

The problem Toolboxes solve isn’t just developer friction. It’s an operational and governance problem.

When every team wires its own tools, credentials get duplicated. Governance is inconsistent. There’s little visibility into which tools exist across the organization, who’s using them, or whether they’re being called correctly. Security teams can’t enforce consistent policies when every agent has its own integration pattern.

Toolboxes shift that model. Tool owners define and publish once. Consuming teams connect once. And when a Toolbox is updated, agents using it don’t need to change their code.

Microsoft has organized the Toolbox lifecycle into four pillars: Discover, Build, Consume, and Govern. Build and Consume are available today. Discover (which helps teams find existing approved tools rather than rebuild them) and Govern (which provides centralized observability and controls across all tool calls) are coming soon.
According to Mitch Ashley, VP and practice lead for software lifecycle engineering at The Futurum Group, “Tool wiring has become the operational bottleneck for enterprise agent deployment, and the integration layer is now control plane territory. Foundry Toolboxes position Microsoft to govern that layer regardless of which runtime executes the agent.”

Ashley continues, “The strategic value rests on the Discover and Govern pillars, still on the roadmap. Without centralized registries and observability across tool calls, enterprises retain credential sprawl and policy gaps that already constrain agent autonomy. Procurement should weigh Toolboxes against the governance roadmap, because preview tooling alone leaves those gaps in place.”

Not Locked to Foundry

One concern teams often raise with Microsoft-native tooling is vendor lock-in. Here, the answer is fairly clear. Toolboxes are created and governed in Foundry, but any agent runtime that supports MCP can consume them. That includes agents built with Microsoft Agent Framework, LangGraph, GitHub Copilot, Claude Code, or custom code.

You can manage tools centrally in Foundry and still use them across your existing agent infrastructure.

Getting Started

Getting a Toolbox up and running takes a few steps. You create an AIProjectClient, define your toolbox with the tools and authentication it needs, grab the unified MCP endpoint that Foundry generates, and attach it to your agent. Versioning is built in — you can promote a tested version to production, share the endpoint broadly, and continue iterating without breaking downstream agents.

Microsoft has published sample code for Microsoft Agent Framework, LangGraph, and Copilot SDK, along with an AZD CLI quickstart and support in the Foundry Toolkit for VS Code.

The Bigger Picture

Toolboxes reflect something the industry is starting to accept: the AI agent problem isn’t just about models. The integration and infrastructure layer matters just as much. Right now, tool wiring is often the bottleneck — not model capability.

If Toolboxes deliver on the governance and discoverability features still on the roadmap, this could be a meaningful step toward making enterprise agent development more reliable and repeatable. The public preview is a good place to test that assumption.

Documentation is available at Microsoft Learn, and the Foundry Portal is open for exploration at ai.azure.com.



from DevOps.com https://ift.tt/J3WOsYf
Labels:

Comments

Post a Comment

Popular posts from this blog

Cloudbees Is A Launch Partner For Google Cloud Run As Product Goes Ga

Industry Leaders Collaborate to Offer Streamlined Deployment of Containerized Applications, Better Access to CloudBees Solutions on Google Cloud Platform Marketplace   GOOGLE CLOUD NEXT, LONDON AND SAN JOSE, CA. – November 20, 2019 – CloudBees, the enterprise DevOps leader powering the continuous economy, today announced an extension of its partnership with Google. As a Google […] The post Cloudbees Is A Launch Partner For Google Cloud Run As Product Goes Ga appeared first on DevOps.com . from DevOps.com https://ift.tt/2XuFTxc
Post a Comment
Read more

Carbon-Aware DevOps: Turning CI/CD Pipelines Into Emissions-Controlled Workloads 

Turning continuous integration and continuous delivery (CI/CD) pipelines into emissions‑controlled workloads is a strategy businesses adopt to reduce the carbon footprint of their pipelines. This article examines how a Carbon-Aware DevOps strategy can help optimize CI/CD pipelines for sustainability by reducing their carbon footprint while also decreasing costs and meeting the increasing demand for innovative, eco-friendly solutions.   Understanding the Problem   Today’s organizations take advantage of CI/CD pipelines to streamline and accelerate their software delivery. However, these CI/CD pipelines can become a hindrance to sustainability because of the resources required to create, build, test and ultimately deploy software into production.   Typically, CI/CD pipelines run tens of thousands of automated builds, tests and deployments daily, thereby consuming significant compute and energy resources. If you don’t take the steps necessary to reduce the emissions generated by these ...
Post a Comment
Read more

Why Endpoint Protection Matters More than Ever in CI/CD Environments

CI/CD environments depend on far more than repositories and deployment infrastructure. Developer endpoints hold sensitive data: cloud credentials, SSH keys, deployment permissions, direct access to internal systems. Endpoint security and control are part of daily operational risk management. Engineering teams are shifting more and more toward distributed workflows, so discussions around CI/CD security include the security posture of the devices connected to the pipeline. Many organizations already focus their CI/CD security efforts on secrets management , dependency scanning and supply chain controls. However, advanced endpoint security solutions are also relevant in cloud-native development environments, where local devices maintain direct access to production workflows. Endpoint Compromise Can Bypass Mature CI/CD Controls CI/CD security discussions mostly focus on repositories, containers, infrastructure, and deployment automation. Developer endpoints are often overlooked as a par...
Post a Comment
Read more