ANATOMY OF AN AGENT REQUEST
Anatomy of an agent request The previous article took the agent apart, using the drain agent to name the parts. This half takes apart what those parts produce: the requests that arrive at the inference endpoint. For that we need measured runs, so the example changes to the agentic workloads that have public published traces, which are coding agents. Seen from the inference endpoint, each component answers one question about the requests. The trigger decides how many runs start and when. The harness decides how many requests a run makes. The tools decide when the next one can be sent. The system prompt, the tool definitions, and the skill decide what every request begins with. The sandbox adds time, not tokens. The model receives the sum. The subsections below take them in that order.
ANATOMY OF AN AGENTIC WORKLOAD
Anatomy of an Agentic Workload The previous article explored when an agent makes sense. It reduced an agent to a loop: a model, a set of tools, and a condition that tells it when to stop. The interesting part was the ability to decide what to do next based on the result of the previous step. But what actually happens when that loop runs, and which parts of the infrastructure are involved?
AGENT OR FLOWCHART? FIND THE BOX YOU CAN'T FINISH DRAWING
Agent or flowchart? Find the box you can’t finish drawing. I have spent a while trying to answer a simple question: what is an agent actually good for? Most examples I see don’t convince me. They look like ordinary programs with an LLM inserted into the control path. A tool gets called, a result comes back, and the model decides what happens next even though a developer could have written that decision in code. We’ve spent decades learning how to build reliable software by making control flow explicit. If the path is known, put it in code. If a decision is deterministic, make it deterministic. Handing that work to a model does not automatically make the system better.
TOPOLOGY-AWARE MULTI-GPU VM PLACEMENT
Architecting AI Infrastructure Series - Part 11 A multi-GPU VM isn’t only asking for multiple devices. It’s asking for a specific communication geometry. This distinction matters. When a platform team provisions a VM for LLM inference or fine-tuning, they’re not simply allocating two units of compute. They’re allocating two GPUs that can communicate at hundreds of gigabytes per second over NVLink. Two GPUs on the same server that must communicate via PCIe won’t deliver the same result.
UNDERSTANDING MULTI-GPU TOPOLOGIES WITHIN A SINGLE HOST
Architecting AI Infrastructure Series - Part 10 Part 9 covered why it’s important to understand the topology when using multiple GPUs. When a model runs across several GPUs, communication between them becomes part of the process. Not all GPUs in a server communicate at the same speed, and these differences can impact performance. Many AI teams prefer to run their workloads on a single server. This helps reduce network complexity and simplify deployment. Still, there are several ways to set up multiple GPUs in a single server.
UNDERSTANDING UNIFIED MEMORY ON DGX SPARK RUNNING NEMOCLAW AND NEMOTRON
NemoClaw became the talk of GTC 2026 within hours of its announcement. It wraps OpenClaw in NVIDIA’s OpenShell runtime, adds guardrails, and gives you an always on AI agent with a single install. Jensen Huang called OpenClaw the operating system for personal AI. NemoClaw is what makes that usable. This is part 4 of the AI Memory series and focuses on how memory behaves on real systems. I installed NemoClaw on a DGX Spark and ran Nemotron models locally to understand what actually happens in memory. The most important takeaway is simple. Unified memory breaks the usual GPU mental model.
WHY MULTI GPU REQUIRES TOPOLOGY AWARENESS
Architecting AI Infrastructure Series - Part 9 The AI Memory series has been showing how AI workloads use GPU memory in different ways. The Dynamic World of LLM Runtime Memory explains how the KV cache grows with each new token and becomes a main user of GPU resources. Understanding Activation Memory in Mixture of Experts Models looks at the hardware pressure that happens when activation memory spikes during the prefill phase. The series also covers how agentic systems keep memory active to stay on track during complex tasks, as discussed in Durable Agentic AI Sessions in GPU Memory.
DURABLE AGENTIC AI SESSIONS IN GPU MEMORY
The durable memory of agentic systems When a user asks a question in a chat interface and the model responds, the interaction is a single prompt completion. A prompt goes in, tokens come out. From an infrastructure perspective this is a predictable transaction. As described in The Dynamic World of LLM Runtime Memory, the KV cache grows with the prompt, peaks during generation, and is released when the session ends. The memory footprint is bounded and relatively easy to plan for.
MIG PARTITIONING, PLACEMENT GEOMETRY, AND STRANDED CAPACITY
Architecting AI Infrastructure — Part 8 Previous articles in this series explained how time-sliced GPU sharing works in both same-size and mixed-size environments. They showed that choices like profiles and the order in which workloads start can directly affect GPU utilization and whether workloads are placed successfully. In this part, we look at MIG and the design choices that affect placement success and overall resource utilization. MIG takes a different approach to GPU sharing. Instead of multiplexing compute resources between workloads, MIG splits the GPU into hardware instances. Each instance gets its own dedicated compute and memory slices slices.
SAME SIZE VS MIXED SIZE PLACEMENT AT CLUSTER SCALE
Architecting AI Infrastructure — Part 7 The Silo Capacity Visualizer from Part 6 shows how profile selection and placement-ID alignment affect memory layout inside a single GPU. While that’s helpful for understanding the basics, real capacity planning happens at the cluster level. This article introduces the Same-size vs Mixed-size Placement simulator, the second tool in the Cluster Profile Strategy Toolset. It lets you simulate vGPU placement across an entire cluster using both same-size and mixed-size policies simultaneously, with the same workload sequence for both. This way, you can directly compare their results.