NVIDIA's Open AI Agent Platform Built With 16 Companies: 3 Implementation Shifts Developers Should Bring Into Their Code This Week

⚡ This is Part 2 of a series. If you haven’t read Part 1, “Vibe Coding Was Just the Prologue: The Day Developers Become Conductors With ‘Agentic Engineering,’” please start there.

16 Companies Stepped Onto the Same Stage. What Happened at GTC 2026?

In the last article, I wrote that “developers become conductors.” The era is coming when humans direct AI agents and hold the reins of code quality and direction.

The week after I wrote that piece, a “shared score” arrived in the conductor’s hands.

March 16, 2026, NVIDIA’s GTC (GPU Technology Conference). The press release headline jumped out at me.

“NVIDIA Ignites the Next Industrial Revolution in Knowledge Work With Open Agent Development Platform” (NVIDIA Newsroom).

The list of companies that announced adoption was striking (VentureBeat).

Adobe, Atlassian, SAP, Salesforce. Cisco, CrowdStrike, ServiceNow, Siemens. Plus Amdocs, Box, Cadence, Cohesity. Dassault Systèmes, IQVIA, Red Hat, Synopsys. Sixteen companies in total.

Salesforce and SAP — aren’t those the two companies going head-to-head in CRM? And here they are, both declaring they’ll use the same toolkit.

This isn’t just a technology story. It’s a signal that “the common language for agent development has been decided.”

For developers, there are three implementation-level points worth grasping: NeMo Agent Toolkit, the A2A protocol, and OpenShell. Let’s look at them one by one.

NeMo Agent Toolkit: The Shortest Path to Turning Existing Code Into Agents

The first thing I did was open the NeMo Agent Toolkit GitHub repo (GitHub).

The toolkit’s selling point is being “framework-agnostic.” It works whether you’re using LangChain. It runs on LlamaIndex or CrewAI too. It also supports Microsoft Semantic Kernel and Google ADK (Agent Development Kit). The design lets you bring existing code in as-is.

Here’s how it works in practice. Running the toolkit’s workflow create command generates a project scaffold. The core consists of two files: pyproject.toml and config.yaml. You define the agent’s components in YAML.

# config.yaml structure (simplified)
# Define an agent's skills in NeMo Agent Toolkit
workflow:
  name: my-first-agent
  description: "Agent that searches internal knowledge"

  # Specify the framework to use
  framework: langchain

  # List the skills (what the agent can do)
  skills:
    - name: search_docs
      type: retrieval   # RAG search
    - name: summarize
      type: generation  # Summary generation

This is the part that hit home for me as someone who came from vibe coding. Since you can build the agent’s skeleton just by writing YAML, you don’t have to agonize for days over code architecture.

Pay attention to the “AI-Q Blueprint” NVIDIA has prepared as well. It’s a reference implementation for a search agent. It tops the DeepResearch Bench accuracy benchmark (NVIDIA Developer Blog). My development style is “see something working first, then customize from there.” This blueprint felt like the perfect entry point for that approach.

Notebooks that run on Google Colab without any setup are also available (NVIDIA Developer). It’s a relief not to worry about getting stuck on environment setup.

Let me share a gotcha upfront. NeMo Agent Toolkit’s latest version is v1.5, but parts of the documentation are still on v1.4. The config.yaml schema has changed subtly in some cases, so make sure to check the latest official docs. If you only read the README, you’ll burn 30 minutes the way I did.

DeepLearning.AI is offering a free course taught by NVIDIA solution architects (DeepLearning.AI). The theme is “how to run agents reliably in production” — exactly the problem you’ll face right after adopting the Toolkit. I recommend taking it after spending a weekend running the AI-Q Blueprint.

The A2A Protocol: The Common Language for Agents to Talk to Each Other

Agents built with NeMo Agent Toolkit work fine on their own. But the truly interesting part is when you connect multiple agents.

That’s where the A2A (Agent-to-Agent) protocol comes in. Originally developed by Google, it’s now an open standard donated to the Linux Foundation (A2A Protocol official site).

The problem A2A solves is clear. It answers the question, “How do agents built on different frameworks exchange information with each other?”

Some readers might be wondering how it differs from MCP (Model Context Protocol). MCP is the standard for AI models to access external tools. Here’s the clean breakdown.

• MCP: The standard for agents to access external tools and data sources. “The key that opens the toolbox.”
• A2A: The standard for agents to delegate tasks to each other. “The shared language for asking a colleague to do a job.”

A2A has been supported natively since NeMo Agent Toolkit v1.4 (NVIDIA NeMo A2A docs). According to the official docs, you can A2A-enable an existing LangGraph agent with minimal code changes.

Version 0.3 added gRPC support and security card signing features (Google Cloud Blog). More than 150 organizations have already announced A2A support.

“Our agents don’t talk to others” is starting to become an unacceptable answer.

Let me show what implementation looks like. The code to add A2A server capability to an existing LangGraph agent is this simple.

# Minimal A2A setup (NeMo Agent Toolkit)
# Exposing an existing LangGraph workflow via A2A
from nemo_agent_toolkit.a2a import A2AServer

# Expose your agent as an A2A server
server = A2AServer(
    agent=my_langgraph_agent,  # Pass in the existing agent as-is
    name="doc-search-agent",
    description="Searches and summarizes internal documents"
)
server.start(port=8080)
# That's all it takes to be callable from other A2A-compatible agents

Connect tools with MCP, connect agents with A2A. This two-layer structure looks set to become the standard form of multi-agent development in 2026.

OpenShell: The Safety Mechanism That Keeps Autonomous Agents on a Leash

I’ll be honest. Every time I hear about autonomous agents, I get a little scared.

“The AI hits APIs on its own, deploys on its own, and racks up charges on its own.” That scenario flashes through my head. As someone with a CS background, I know that the moment a user feels “something unexpected happened,” trust collapses.

NVIDIA’s answer here is an open-source runtime called “OpenShell.” It’s a mechanism that enforces security, network control, and privacy guardrails through policies (VentureBeat).

Think of it as “a box that defines in advance how far the agent is allowed to move.” No matter how smart the agent gets, it can’t call APIs outside what OpenShell permits.

In the last article, I wrote that “judging when to stop the agent matters.” OpenShell is the tool that lets you define those “stopping criteria” in code.

It matters even for solo developers in plenty of scenarios. When you’re building your own internal tools, the anxiety of “what if this bot goes rogue” follows you around. With OpenShell, you can explicitly write the boundary between “what’s allowed” and “what’s forbidden” in a policy file.

For someone who’s lived by the “if it runs, it ships” mentality, the age of safety mechanisms being built-in feels like a welcome change.

Remember CurXecute, which I mentioned in the previous article. The announcement came right after a zero-click vulnerability was discovered in a vibe coding tool. Reconciling agents that move freely with agents that move safely is becoming an implementable reality.

The Backdrop to 16 Companies Moving in Sync: The Weight of Gartner’s “40%” Forecast

Why did 16 companies move at once? Behind it lies an industry analyst forecast. The number floating around: “By the end of 2026, 40% of enterprise apps will incorporate task-specific AI agents.” At the start of 2025 it was under 5%, so that’s an 8x jump in a single year.

Looking at each company’s moves, you can feel the urgency.

Salesforce adopted NeMo Agent Toolkit in its “Agentforce” service. The plan is to build AI agents for sales, marketing, and customer service. The design uses Slack as the conversational interface.

SAP is integrating the Agent Toolkit into its “Joule Studio” platform. The vision is to run AI agents on SAP BTP (Business Technology Platform).

Adobe announced it would adopt the Toolkit for long-running agents in creativity, productivity, and marketing.

In other words, if you’re working with any of these products as a developer, NeMo Agent Toolkit may be running underneath. Even if you don’t touch it directly, it’s worth knowing about as part of the ecosystem.

Remember the Pragmatic Engineer survey I introduced last time. The one where Claude Code took the “most-loved tool” spot at 46%. The main battleground for agent development is shifting from “which LLM do you use” to “which platform do you build your agents on.” NVIDIA’s move is symbolic of that shift.

Wrap-Up: 3 Things You Can Do This Weekend

In the last article, I wrote that “with agentic engineering, developers become conductors.” What I want to convey today is that “the conductor’s score is now available as open source.”

NeMo Agent Toolkit, the A2A protocol, OpenShell. With these three pieces in place, the entry point to agent development has widened all at once.

Here are three things you can do this weekend.

1. Clone the NeMo Agent Toolkit GitHub repo (github.com/NVIDIA/NeMo-Agent-Toolkit) and run the AI-Q Blueprint. It works on Google Colab, so no environment setup headaches.
2. Read the A2A protocol spec (a2a-protocol.org). Just understanding how it differs from MCP will change your design decisions next week.
3. Try the hands-on work in the DeepLearning.AI free course (deeplearning.ai). NVIDIA solution architects teach it directly.

If there’s one thing this once-stuck engineer can say, it’s this: “Agent development is no longer just for pros.” Write some YAML, run a blueprint, connect it via A2A. That first step is now within reach this weekend.

The concept of “agentic engineering” has now connected to NVIDIA’s implementation foundation. We’re seeing the shift from “concept” to “code you can actually write.” It’s time to feel the sensation of a top-tier engineer taking up residence inside you a notch deeper.

In Part 3 of this series, I’ll cover “3 architecture design patterns to realize Gartner’s 40% forecast.” After “which platform to choose,” the next question you’ll face is “how to design it” — and that’s what I’ll be answering.

---

---