AI¶

Context engineering for production AI agents

Prompt engineering is the discipline of writing the right words for a single turn. Context engineering is the discipline of curating everything that ends up in the model's context window across an entire agent run — system prompt, tool definitions, retrieved documents, conversation history, scratchpad notes, sub-agent outputs. Anthropic named this discipline in September 2025¹ because production agents kept hitting the same wall: the model was smart enough, but the context it saw was wrong.

This post covers what context engineering is, the four strategies you actually use, the failure modes that show up in production, and the tooling that does each one well.

GPUs on Kubernetes: From Bare Metal to Schedulable in One Operator

A fresh Kubernetes cluster has no idea your nodes have GPUs. kubectl describe node shows CPU, memory, and pods — nothing else. To make a pod request a GPU you need a driver, a container runtime hook, and a device plugin advertising the hardware to the scheduler, all version-matched across every GPU node. Do it by hand and you'll re-do it on every kernel bump. This post wires it up the way you actually want — one operator — and works on any Kubernetes, not a specific vendor's distro.

Stacking MIG and Time-Slicing on One GPU Operator values.yaml

MIG carves a GPU into hardware-isolated slices. Time-slicing oversubscribes each slice so more pods can share it. Stack them and one physical GPU advertises far more schedulable units than it has silicon — useful when you have more workloads than GPUs and most of them sit idle. Here's the exact values.yaml, wired into the kommander-applications GPU Operator 26.3.0 app¹, and the labels that switch a node between layouts.

Multi-agent engineering with Claude Code: the dev loop, demonstrated

The previous post walked through a single Claude Code session — one engineer, one context window, 14 turns. That's the right shape for most work. But some tasks don't fit in one brain. A migration across 12 services, a security audit of 200 endpoints, a refactor that touches every file in the repo — these want a small team, not one engineer working 14-hour days.

Claude Code has a Task tool that spawns sub-agents with isolated context windows. The main session is the lead engineer; sub-agents are specialists. Each specialist runs to completion, returns a summary, and the lead stitches the work together. That's the multi-agent loop, in Claude Code.

This post is a full session that uses it. I'll do a real task — port a Python CLI from one config library to another across 8 files — by having Claude Code delegate parts to sub-agents. You'll see the prompts, the sub-agent invocations, where handoffs went well, and where they didn't.

The session is reconstructed from real Claude Code runs. The patterns work; the exact transcripts are illustrative.

Build Your Own Token-as-a-Service: A Self-Hosted OpenAI-Compatible AI Gateway on Kubernetes

Public LLM APIs bill you per token and leak your prompts off-prem. The fix isn't "run Ollama on a box" — it's a centralized, OpenAI-compatible inference platform your whole org consumes like a utility: one API key, token-based quotas, models that stay in your datacenter. Call it token-as-a-service. This post is the architecture — model tiering, GPU math, MIG partitioning, vLLM tuning, and KV-cache-aware routing — generic enough to run on any Kubernetes cluster with NVIDIA GPUs.

The full Claude Code dev loop, demonstrated end-to-end

Most posts about Claude Code show a single claude command and a single impressive output. That's not how you actually use it. A real session is 30+ turns: plan, write, run, fail, read the error, fix, test, commit, repeat. The interesting parts are the failures and the recovery.

This post is one full session, reconstructed from real Claude Code sessions. Every command is one you'd actually run, every code block is code you'd actually see, every bug is the kind of bug that does appear. The wall time and the exact bug-discovery sequence are approximate — the patterns are real.

The session took 14 minutes of wall time. The transcript below is annotated.

GPU DRA on Kubernetes: migrating off the NVIDIA device plugin, end-to-end

Dynamic Resource Allocation went GA in Kubernetes 1.35¹, and NVIDIA's DRA driver for GPUs shipped v0.4.1 on 2026-06-30². The nvidia.com/gpu extended resource model — the one the device plugin has used since 2017 — now has a sanctioned successor. The migration is non-trivial because the resource model is completely different (claim-based, not extended-resource-based), but the payoff is real: structured GPU allocation, native NVLink topology awareness, and a single API for MIG, MPS, time-slicing, and Multi-Node NVLink.

This post is the migration path: install the driver, write the first claim, swap one workload at a time, and run device plugin + DRA side-by-side until you're done.

GPU Sharing on Kubernetes: Time-Slicing, MIG, and MPS Compared for LLM Workloads

You have 8 H100s. You have 30 inference pods that need one GPU each. The naive answer — buy 22 more H100s — is a quarter-million-dollar mistake. The right answer is GPU sharing, and there are four of them now: time-slicing, MIG, MPS, and DRA. Pick wrong and you get OOM kills, throughput collapse, or training jobs that silently corrupt each other. Pick right and you run 30 pods on 8 GPUs with measurable isolation guarantees.

This post walks each option with the actual config, the actual tradeoffs, and the decision tree that tells you which one to use for which LLM workload.

How Much VRAM Does Your LLM Actually Need? A Field Guide to Sizing GPUs

"Will this model fit on my GPU?" has one honest answer: do the arithmetic. It's three numbers added together, and you can pull every input from a model's config.json in about two minutes. This post turns a sizing spreadsheet into a method you can run by hand.

An On-Premise RAG Reference Architecture for 100 Users: Right-Sized GPUs, HA by Design

You can build a production RAG platform on your own hardware for the price of two years of API bills, and it fits in half a rack. The trick is sizing the GPUs to the models instead of buying the biggest card on the truck. This is the full design for a 100-user, highly available, hybrid-plus-graph RAG stack, with every GPU choice backed by the VRAM math.