
I attended the NVIDIA Japan NPN Partner Agentic AI Bootcamp.
This page has been translated by machine translation. View original
Introduction
Hello, I'm Morishige from Classmethod's Manufacturing Business Technology Division.
On June 17, 2026, I attended the "Japan NVIDIA NPN Partner Agentic AI Bootcamp" hosted by NVIDIA Japan and Macnica. This was a closed, full-day hands-on event held exclusively for employees of NVIDIA NPN (NVIDIA Partner Network) partner companies. It had quite a packed structure, covering MCP, NVIDIA NIM, LangGraph, and NeMo Agent Toolkit all in one day, with a Challenge session at the end to gauge how much participants had absorbed.
Some of you may be thinking "I couldn't attend since it was NPN-only," but the materials themselves are publicly available under the Apache 2.0 license at openhackathons-org/agentic-ai-bootcamp. The Japanese-localized notebooks are all included, so simply transcribing them for an internal study session would be well worth the effort.
In this article, I'll summarize the day's agenda, key points covered in each Lab, the structure of the Challenge, and the moments that left the biggest impression on me.
In a Nutshell
Overall, the structure started with NIM from cloud and local, then moved sequentially through MCP, LangGraph, and NeMo Agent Toolkit all in one day—a setup that lets you experience the "layers" of agent development firsthand. The finishing Challenge was story-driven, centered on extending the customer support of a fictional record EC site "Harmony Records" using MCP, requiring you to mobilize everything from the morning's layers. Since the materials repository is publicly available on GitHub, those who couldn't attend should be able to recreate it as an internal hands-on session.
Event Overview
The event was structured in two parts: Day 0 (online Dry Run) and Day 1 (in-person hands-on main session).
- Date: June 17, 2026, 9:30–19:30 (JST)
- Venue: Macnica Shinagawa Office
- Target participants: NVIDIA NPN partner employees
- Organizers: NVIDIA Japan + Macnica + OpenACC organization

Here are the materials repository and the API Catalog used as the NVIDIA-side endpoint.
The execution environment was a shared GPU instance set up on Brev, distributed in advance, with the setup calling NIM endpoints from the API Catalog via Jupyter Notebook. Environment verification was supported in the pre-event guidance, and it was a relief that the kind of trouble where "half the day gets eaten up by environment setup" was unlikely to happen on the day itself.
Day-of Agenda
The hands-on main session agenda was roughly as follows.
| Time | Session |
|---|---|
| 10:00 - 10:30 | Introduction and Cluster |
| 10:30 - 11:50 | Lab 1: Using NVIDIA NIM via Cloud and Local |
| 12:35 - 13:20 | Lab 2: Introduction to Model Context Protocol (MCP) |
| 13:20 - 13:50 | Lab 3: Low-Level MCP Server Implementation |
| 14:00 - 14:55 | Lab 4: Building Agentic Workflows with LangGraph |
| 15:05 - 16:45 | Challenge Description and Self-Style Challenge |
| 16:55 - 17:25 | Challenge Solution (Interactive Session) |
In the materials repository under tutorial/jupyter_notebook/, notebooks are lined up from 01_inference_endpoint_ja.ipynb through 06_challenge_ja.ipynb, and the style was essentially to work through one notebook at a time in order.
From here, I'll look back in turn at what each Lab covered and the points that stood out to me.
Lab 1: Calling NIM from Cloud and Local
The first Lab was a warm-up with NVIDIA NIM (NVIDIA Inference Microservices). The content involved calling OpenAI-compatible APIs using the requests library for both the NIM endpoint hosted on the API Catalog at build.nvidia.com and a NIM running locally in Docker.
The key point is that NIM speaks OpenAI-compatible schema. Both the cloud endpoint and the local Docker endpoint work with the exact same client code—just by switching the URL and model name. This connects to a later point in the NeMo Agent Toolkit Labs: simply swapping base_url lets you achieve configurations like "use the large cloud model during development, use the in-house GPU NIM in production."
As someone who had been wrestling with the vague frustration of "wanting to test while switching between local and cloud LLMs," I think it made sense to nail this down first as an entry point.
Lab 2: Getting Hands-on with FastMCP
Lab 2 was an introduction to MCP (Model Context Protocol), covering the flow of defining tools with FastMCP, the high-level SDK. Its selling point is the simplicity of turning a function into an MCP tool with a single decorator, and the tutorial's mcp_server.py is written in about this much code.
# Source: openhackathons-org/agentic-ai-bootcamp tutorial/jupyter_notebook/mcp_server.py
from mcp.server.fastmcp import FastMCP
mcp = FastMCP("simple-math")
@mcp.tool()
def add(a: int, b: int) -> int:
"""Add two numbers together."""
return a + b
if __name__ == "__main__":
mcp.run(transport="stdio")
On the client side, you go through the basic operations in order: establishing a ClientSession from the mcp Python SDK over stdio_client, retrieving the tool list with list_tools(), and calling tools with call_tool(). Many people may have only a vague awareness of MCP as "a new protocol from Anthropic," but when the server-side code is this simple, it starts to feel like something you could write yourself—so the structure does a good job of lowering the initial psychological barrier.
Lab 3: Writing a Low-level SDK and HTTP MCP Server
Lab 3 was about implementing MCP with the low-level SDK. This Lab temporarily stripped away the abstraction layer like FastMCP to understand the raw behavior of MCP: writing JSON Schema by hand with @server.list_tools(), and validating arguments before passing them to processing with @server.call_tool().
# Source: openhackathons-org/agentic-ai-bootcamp tutorial/jupyter_notebook/mcp_server_low_level.py
server = Server("simple-math")
@server.list_tools()
async def handle_list_tools() -> list[types.Tool]:
return [
types.Tool(
name="add",
description="Add two numbers together",
inputSchema={
"type": "object",
"properties": {
"a": {"type": "number"},
"b": {"type": "number"},
},
"required": ["a", "b"],
},
),
]
@server.call_tool()
async def handle_call_tool(name: str, arguments: dict | None):
if not arguments or "a" not in arguments or "b" not in arguments:
raise ValueError("Missing required arguments: a, b")
return [types.TextContent(type="text", text=str(arguments["a"] + arguments["b"]))]
In the second half, the same tools are mounted on Starlette + Uvicorn and published over HTTP (Streamable HTTP). The rationale for the distinction—stdio for local development subprocesses, HTTP for production microservices—suddenly became crystal clear. Since the Challenge involves implementing an HTTP MCP server, having this structure in your head going in turns out to quietly pay dividends.
Lab 4: Assembling LangGraph State / Node / Edge
Lab 4 was the LangGraph section. Using StateGraph, it covered assembling State (a shared information bulletin board), Nodes (processing units), and Edges (connections), all the way through building a ReAct agent with tool calls.
The technical combinations that stood out to me were:
- Using
Annotated[list, add_messages]to hold conversation history in State - Using
with_structured_output(Pydantic schema)to force LLM output into JSON, placing it at the entrance to an Intent Classifier - Passing
InMemorySaveras a CheckPointer and maintaining multi-turn conversations perthread_id - Using
interruptto insert a human confirmation step in the middle of the graph (Human-in-the-loop)
The way "what's the benefit of actually using LangGraph's interrupt?" becomes concretely understandable through the Challenge's refund flow (a step that confirms "are you sure you want to issue a refund?" with the user) shows how carefully the instructional design is layered. The explanation of State as a "bulletin board" really clicked for me, and I'm thinking of borrowing that analogy when explaining it in internal study sessions.
Lab 5: Trying NeMo Agent Toolkit's YAML and Phoenix
Lab 5 covered the operational features of NeMo Agent Toolkit (NAT). NAT is a layer above LangGraph that provides a set of features that come into play when operating agents in production: "tools, models, and Workflows can be swapped out via YAML," and "traces can be visualized in Phoenix (Arize)."
Excerpting the tutorial's movie_workflow.yml, the structure looks like this:
# Source: openhackathons-org/agentic-ai-bootcamp tutorial/jupyter_notebook/movie_workflow.yml
function_groups:
mcp_movies:
_type: mcp_client
server:
transport: streamable-http
url: 'http://127.0.0.1:${MCP_PORT}/mcp/'
llms:
nim_llm:
_type: nim
model_name: nvidia/nemotron-3-nano-30b-a3b
base_url: https://integrate.api.nvidia.com/v1
api_key: ${NVIDIA_API_KEY}
workflow:
_type: react_agent
tool_names: [mcp_movies]
llm_name: nim_llm
Replacing the MCP client code written in LangGraph with NAT means tool connections and LLM swaps only take a few lines of YAML. Furthermore, adding a telemetry section sends traces to Phoenix, letting you track on screen which tools the agent called and in what order.
Honestly, during the hands-on I found it hard to see the motivation for rewriting something I'd already built in LangGraph into NAT. But the instructor's supplementary comment—"when you want to roll out a configuration that worked for the sales department to the engineering department, you just swap the YAML"—finally made it click. When you think through to the point of "rolling out agents to customers," the desire to peel the operational layer away from hard-coded LangGraph starts to make sense.
Harmony Records Customer Support Challenge: Extending with MCP
The afternoon Challenge session was story-driven, centered on extending the customer support agent for a fictional record EC site "Harmony Records" using MCP. Skeletons are provided under challenge/ in the materials repository, divided into four sub-tasks. There was about an hour and a half of self-directed time, but completing all four end-to-end had more bite than expected, making it a great rehearsal for reassembling everything touched in the morning's Labs in a real-world scenario.
- Invoice MCP Server: Expose
search_invoicesandprocess_refundagainst the Chinook SQLite DB using Low-level MCP SDK + Streamable HTTP - QnA Agent Skill: Write an Agent Skill (
SKILL.md) that assists with SQL query generation for Music / Artist / Album / Track information using a Progressive Disclosure pattern - LLM Workflow: Build an Intent Classifier → QnA / Refund agent pipeline in LangGraph, connect it to the Invoice MCP server, and insert
interruptfor refund confirmation - NAT Workflow: Declare the same configuration in
workflow.yamland make it runnable withnat run
A rough diagram of the overall picture looked something like this:
One implementation pitfall to watch out for: since the Low-level MCP inputSchema is written directly as JSON Schema, any type mismatch there will cause mysterious validation errors on the client side. I initially wrote invoice_id in process_refund as string, which caused an endless loop when calling from LangGraph. Since error messages tend to get swallowed at the MCP layer, it's faster to verify the raw response with the nat mcp client CLI first before integrating into LangGraph.
Points That Left an Impression
Having attended, there are four points that I came away with clearer thinking on.
The first is the division of roles between MCP and Agent Skill. The lecture presented the distinction that MCP is the layer of "what tools are available" (tool specifications), while Agent Skill is the layer of "how to combine and use them" (task procedures). When you think of both at the same layer, you start to wonder "should I pack SQL query patterns into MCP too?"—but being conscious of the layer separation lets you offload that to the Skill side, which I felt reduced my design ambiguity.
The second is the positioning of NeMo Agent Toolkit. If you try to deliver an agent built in LangGraph directly to a customer, every configuration change requires rewriting Python code. By declaratively composing "MCP client," "LLM endpoint," and "Workflow" via NAT's YAML, you can roll it out to new contexts without touching Python. The explanation that "LangGraph and NAT aren't competing—they're at different layers" landed quietly but effectively.
The third is the quality of the materials. With the Brev cluster dry run included, and notebooks you can work through in order to touch everything from NIM → MCP → LangGraph → NAT → Phoenix, these materials seem reusable as an introductory guide to agent development internally. "Take this with a grain of salt," but I think they have considerable value for reuse as material for internal hands-on sessions.
The fourth is what the instructor said at the beginning about "the meaning of writing agents yourself." In an era where agents themselves can be written by AI agents, what makes the difference—when customizing for customers, inserting sub-agents, or wanting greater control—is whether you truly understand what's happening under the hood. That was the gist of it. As someone who regularly delegates most of my code to AI agents, this concern resonated strongly. The real gap in agent development seems to lie somewhere between "being able to build something that works" and "being able to build something that works with a genuine understanding of what's inside."
As for the atmosphere at the venue, many teams had multiple attendees from the same company, and it had that good quality of an offline study session where people ask each other questions as they go. TAs were also on hand throughout, so there was the reassurance of being able to get a quick answer whenever you got stuck.
Summary
The Agentic AI Bootcamp was a rare hands-on event that let participants connect and experience NIM, MCP, LangGraph, and NeMo Agent Toolkit—technologies that tend to be talked about individually—all in a single day. The Challenge was also at a difficulty level that took real effort to get through within the self-directed time, making it an event that left a solid sense of implementation experience, not just theory. Even though it's NPN partner-only, the materials themselves are publicly available on GitHub, so they should work well as a topic for internal study sessions.
Since I have a DGX Spark, I'd like to next reproduce the local NIM portion from Lab 1 on my own machine, and try rewriting the Challenge from scratch in pure Python. A follow-up Bootcamp has been announced with reinforcement learning as its theme, so I'm hoping to write that up as an article as well.
Reference Links
- Materials repository (Apache 2.0)
- NVIDIA NIM / API Catalog
- Model Context Protocol official
- LangGraph documentation
- NVIDIA NeMo Agent Toolkit
- Related past articles by the author
Code snippets in this article are quoted from openhackathons-org/agentic-ai-bootcamp (Apache License 2.0).
