title	Chapter 2 — Agentic Graph Architecture Foundations: Revision Draft
date	2026-04-06
type	book-revision-draft
status	ready-for-google-doc
chapter	2
sources	Lindenberg 12-pattern analysis of Claude Code open-source architecture
note	Single consolidated addition. Placement references Google Doc outline sections.

Section	Action	Location in Chapter Outline
Section 1	Insert	2.1 The Dual-Graph Architecture -> The Horizontal Workflow Graph (new subsection)

Section	Approximate Lines
Section 1	~60 lines (~800 words)
Net addition	~60 lines

Source	Key Contribution
Lindenberg (2026)	12-pattern taxonomy from Claude Code, OS kernel primitive mapping
Raschka (2026)	"Model quality is really context quality" --- harness-over-model thesis
Vashishta (2026)	17-platform study: LLM is smallest, most replaceable component
Sycamore Labs / Sri Viswanath (2026)	$65M seed for trust kernel commercializing Pattern 10
DeerFlow / ByteDance (2026)	45K-star fork-join implementation (Pattern 8)

Chapter 8 Revision Draft: Optimization

Prepared: 2026-04-06 Status: Draft revised sections for editorial review Conventions: O'Reilly second person, problem-first, inline citations, Example 8-M format Existing examples: 8-1 through 8-16. New examples start at 8-17. Existing figures: 8-1 through 8-3. New figures start at 8-4. Callouts used: 0 in original (budget: 4 remaining)

===SECTION 1: Constraint-First Framing for the Chapter Introduction===

Placement: Inserts after: Line 17 (after the paragraph ending "The DevOps agent ties all of it together." and before the # Selective Intelligence heading at line 18)

Replacement/Insertion text:

Before optimizing, define what "optimized" means for your system. Production teams routinely chase throughput when their bottleneck is latency, or minimize per-token cost when their bottleneck is cold-start time. James Noh (a16z, 2026) distills this from Baseten's inference engineering practice: specify your constraint set first---P99 latency budget, cost per request ceiling, minimum throughput floor---then find the configuration that satisfies all three simultaneously. Maximizing any single metric in isolation produces deployments that are technically impressive and operationally broken.

For the DevOps agent running in incident response, your constraint set looks like this: P99 response time under 2 seconds (SREs cannot wait longer), cost under $0.005 per event (thousands of events per day at production scale), and throughput to handle alert bursts without queuing. Those three numbers guide every decision in this chapter. When two optimizations conflict, the constraints break the tie.

===SECTION 2: WRP Framework as Unifying Structure for Routing Strategies===

Placement: Inserts after: Line 45 (after the sentence "There are three practical approaches, each suited to a different stage of system maturity." and before the ### Static routing by node type heading)

Replacement/Insertion text:

Before examining each routing approach, a structural observation: routing, infrastructure provisioning, and workload characterization are coupled variables, not independent decisions. The vLLM project's Workload-Router-Pool framework (Chen et al., arXiv 2603.21354, 2026) maps these interactions explicitly. Fleet provisioning depends on routing policy, which depends on workload mix---and workload mix shifts as your system moves from chat to agentic use cases. Agent requests are bursty, involve multi-step tool chains with varying latency requirements per step, and create long-lived sessions with growing KV caches that stress pool resources differently than short-lived chat interactions. A routing strategy designed for chat misroutes agent requests. A GPU pool optimized for chat under-provisions for agents' longer context accumulation patterns.

The three routing strategies below correspond to three points on this framework: static assignment (fixed Workload-to-Pool mapping at design time), threshold cascading (fixed structure with dynamic escalation), and learned routing (dynamic model selection driven by preference data). Each has a different data requirement and a different point on the engineering complexity curve.

===SECTION 3: IBM Workflow Taxonomy Grounding for Routing Strategies===

Placement: Inserts after: Line 102 (after the paragraph ending "...static routing or threshold cascading will cover 80% of the benefit with 20% of the complexity.")

Replacement/Insertion text:

IBM Research's survey on workflow optimization (arXiv 2603.22386, 2026) provides a theoretical grounding for why this progression exists. Their three-dimensional taxonomy---timing of structure determination, components selected for optimization, and signals guiding the process---maps directly onto these three strategies. Static routing is IBM's "static" timing: structure determined entirely at design time. Threshold cascading is "hybrid": a static graph with dynamic model binding at one decision point. Learned routing is fully "dynamic": model selection driven by preference signals accumulated from production data.

The survey's most actionable finding for cost optimization: most production systems rely on trace feedback (execution timing and token counts) despite it being the weakest quality signal. Adding verifier signals---actual correctness judgments on node outputs---alongside traces produces disproportionate quality improvement. This is exactly what the per-node evaluation sets in Example 8-4 provide. When you cannot yet build a learned router, build the evaluation infrastructure first. It is the prerequisite for the upgrade, and it improves your static routing decisions immediately.

===SECTION 4: KV Cache Economics and Prompt Caching===

Placement: Inserts after: Line 156 (after the paragraph ending "...A generic accuracy metric cannot capture these asymmetries. Per-node evaluation from production data can." and before the Kakao paragraph beginning "Kakao's experience building...")

Replacement/Insertion text:

Prompt caching as a cost multiplier

Model routing determines which model handles which task. Prompt caching determines how much of that model call you actually pay for. The two optimizations compose multiplicatively.

Anthropic prices cached tokens at 10% of base input cost not as a discount but as an accurate cost signal. When a cached token is served, the GPU performs a memory read---an O(n) operation. When an uncached token is processed, the GPU performs matrix multiplication across the full attention mechanism---an O(n^2) operation that grows with sequence length. The 10x price ratio tracks the actual compute cost differential at the hardware level. Cache writes cost 25% more than standard input (at 5-minute TTL) because the provider must allocate GPU high-bandwidth memory for the duration.

For agentic systems with stable system prompts and tool schemas, the economics are compelling. At a 1.25x write premium, break-even is a 20% cache hit rate. Production agentic coding workloads routinely exceed 90% hit rates on the stable prefix: Alexey M. (2026) documents 93--96% hit rates across instrumented sessions. At 93%, the 10x discount applies to 93% of all input tokens---an 84% reduction on the stable portion of every request.

One anti-pattern closes this window entirely: session compaction strategies that prune tool results before the last N tokens on every turn destroy the KV cache at each turn boundary. Your system pays the 1.25x write premium on every turn while receiving zero cache benefit. For a DevOps agent processing thousands of events per day, this is not a performance issue---it is a structural cost event on the majority of tokens, every turn. The fix is to place cache breakpoints at stable boundaries (system prompt end, tool schema end) rather than at the rolling conversation boundary.

===SECTION 5: Tokenomics Business Case for Selective Intelligence===

Placement: Inserts after: Line 209 (after the Kakao paragraph ending "...because each model's training signal is focused on a single well-defined behavior rather than diluted across competing objectives." and before the # Data Governance and Access Control heading)

Replacement/Insertion text:

The business case: tokenomics of agentic systems

Selective Intelligence is an engineering discipline, but it exists because of an economic reality. Three failures establish why it is not optional for production systems.

Vin Vashishta (March 2026) documents the pattern: OpenAI shut down Sora because compute per generation exceeded revenue despite strong adoption, Microsoft gutted free Copilot features because freemium breaks when every interaction has marginal cost, and enterprise AI shopping assistants report headline revenue uplifts while obscuring the conversion rates underneath. Macy's 4.75x revenue uplift sounds compelling until you account for the 2--4% conversion rate, meaning 25--50 sessions of premium model fees per converted transaction.

The cost-per-successful-interaction metric defined earlier in this chapter is the technical translation of Vashishta's reliability-utility-profitability framework: reliability is what fraction of interactions produce a usable result, utility is what fraction of usable results generate business value, and profitability is the ratio of value per converted interaction to total cost including all failed interactions. A 3B classifier that handles 80% of alerts at 1/30th the cost does not just reduce the token bill---it makes the remaining 20% of frontier model calls economically sustainable.

When organizations now allocate explicit token budgets per engineer---Ayesha Khanna (2026) documents $100K annual allocations becoming standard---every over-sized model call has a dollar sign attached. Using a frontier model for extraction tasks a fine-tuned 3B model handles at 1/30th the cost is measurably expensive, not merely inefficient. The optimization discipline this chapter describes is the technical response to that budget reality.

===SECTION 6: SHACL Streaming Validation for Data Governance===

Placement: Inserts after: Line 258 (after the paragraph ending "...Governance becomes a first-class citizen of the knowledge architecture rather than an external overlay." and before the paragraph "In practice, this means extending the execution graph nodes...")

Replacement/Insertion text:

SHACL (Shapes Constraint Language, W3C Recommendation) formalizes the structural constraints that Neo4j's GRANT and DENY primitives enforce at the access level. Where access control answers "who can see this?", SHACL answers "is this a valid graph modification at all?" SHACL shapes define required properties, value ranges, cardinality constraints, and relationship patterns---the structural rules your graph must satisfy regardless of who is writing to it.

TopBraid SHACL API 1.5.0 (Caselli, March 2026) adds two production-relevant capabilities: Apache Jena 6.x alignment for current-generation RDF infrastructure, and Jelly I/O support for streaming binary RDF validation. The streaming capability matters for the incremental update pattern in Example 8-9. Rather than batch-validating the entire graph after a wave of deployment events, SHACL validation runs on each incoming event, catching constraint violations at ingestion time before they propagate into the agent's reasoning paths.

For the DevOps agent's Knowledge Graph, this means the MONITORED_BY relationship introduced in the migration above carries a SHACL shape: it must point from a Service node to an AlertRule node, and the AlertRule must have a non-null name property. A deployment event that creates a malformed relationship fails validation at ingestion---it never reaches the graph query engine, and it never generates a misleading blast radius estimate during incident response.

===SECTION 7: Delta Computation and Stateful KV Persistence===

Placement: Inserts after: Line 531 (after the paragraph ending "...vLLM maintains 50-80ms time-to-first-token with 100 concurrent users. TensorRT-LLM offers 30-50% higher throughput at scale but requires more engineering overhead to deploy." and before the Specialized hardware bullet)

Replacement/Insertion text:

Session-level KV reuse. Prefix caching solves a horizontal problem: many concurrent users sharing an identical system prompt prefix. Delta computation solves a temporal problem: one session reusing computation across sequential turns. In a 1,000-token agentic prompt where only 150 tokens changed since the previous turn, conventional inference reprocesses all 1,000 tokens. Delta computation avoids reprocessing the 850 unchanged tokens entirely.

LayerScale (Norgren, 2026) implements this through two mechanisms: context affinity routing, which directs all turns of a session to nodes holding the relevant KV state, and GPU-to-GPU KV tensor transfer that bypasses the CPU bottleneck for state migration. The result is inference cost that scales with the delta rather than the full context length---a structural advantage that grows as sessions lengthen and the proportion of unchanged context increases.

The connection to the earlier vLLM serving configuration is direct: context affinity routing is the routing primitive that enables both prefix caching (horizontal sharing) and full session-state persistence (temporal reuse). Your serving configuration must route same-session requests to the same backend nodes for either technique to work. Stateless load balancing---round-robin across identical backends---forfeits both.

===SECTION 8: Disaggregated Inference Architecture===

Placement: Inserts after: Line 533 (after the paragraph ending "SambaNova's SN50 RDU targets multi-model serving specifically, with a tiered memory architecture that enables millisecond-level hot-swapping between specialist models." and before the paragraph "These three approaches compose...")

Replacement/Insertion text:

Disaggregated serving. The roofline model explains why all of the above approaches still leave performance on the table for prefill-heavy workloads. Asheesh Goja (March 2026) demonstrates the physics: the H100's ridge point (~295 FLOPs/byte) creates structurally incompatible optimization targets for prefill (compute-bound, high arithmetic intensity) and decode (bandwidth-bound, ~1 FLOP/byte). No software trick eliminates this incompatibility---it is the Von Neumann bottleneck manifesting at the workload level.

Disaggregated serving separates prefill and decode onto hardware matched to each workload's arithmetic intensity. For the DevOps agent, this matters most during alert bursts: a sudden wave of incidents produces a prefill spike (analyzing new changelogs, logs, and dependency manifests) followed by a sustained decode phase (generating predictions and recommendations). A single-pool architecture is under-resourced for one phase and over-resourced for the other. MLPerf Inference v6 (April 2026) validated disaggregated serving at benchmark scale: Emilio Andere (2026) documents a 2.77x throughput improvement on GB300 NVL72 through disaggregated prefill/decode pools, wide expert parallelism, and fused kernels---with 95.5% efficiency when mixing heterogeneous GPU hardware in the same pool.

For agentic systems specifically, AMD's MI355X outperforming NVIDIA's B300 on latency-sensitive MLPerf scenarios signals market segmentation that matters for your infrastructure decisions: throughput-optimized hardware for batch workloads, latency-optimized hardware for interactive agent responses.

===SECTION 9: TMA and GPU Programming Model Shift===

Placement: Inserts after: Line 454 (after the paragraph ending "...On the LiveJournal graph (4.8M nodes, 69M edges), betweenness centrality that took 7 minutes on CPU completed in 5 seconds, a 485x speedup." and before the paragraph "What does this mean for the DevOps agent?")

Replacement/Insertion text:

The GPU programming model underlying these gains has shifted significantly with the Hopper architecture, and understanding the shift helps you evaluate whether your graph analytics pipeline is capturing available performance. Pre-Hopper, every thread in a kernel independently computed a global memory address, consuming Load-Store Unit pipeline capacity and holding address temporaries in registers---a pattern that scaled poorly as thread counts grew. Tensor Memory Accelerator (TMA), introduced in Hopper, inverts this: one initiating thread passes logical coordinates to a dedicated DMA engine loaded with a TensorMap descriptor encoding the tensor's full geometry. Hardware resolves addresses, applies XOR swizzling to eliminate shared memory bank conflicts, and signals completion via mbarrier rather than blocking all warps with __syncthreads().

The practical impact is substantial. Aleksa Gordic's H100 matmul benchmark (March 2026) jumps from 32 TFLOP/s (baseline warp-tiling) to 317 TFLOP/s when TMA and Tensor Cores are enabled---a 10x gain attributable to reduced LSU saturation and to the compute/memory overlap that mbarrier enables. For graph analytics kernels doing irregular memory access, the reduced register pressure from TMA means more registers available for computation, and the mbarrier completion model means non-waiting warps continue executing graph traversal while data transfers complete.

One correctness constraint is non-obvious: TMA auto-swizzles data during transfer. Kernels reading TMA-written shared memory must apply the same XOR swizzle pattern (output = input ^ (masked >> 3)) to their read indices, or they retrieve wrong values. This produces silent corruption---no error, just incorrect PageRank scores---making it one of the most dangerous optimizations to apply without careful testing. Florian Mattana (April 2026) documents this trap explicitly as the canonical failure mode for Hopper kernel ports.

===SECTION 10: CPU-GPU Sync Elimination and Profiling Methodology===

Placement: Inserts after: Line 458 (after the paragraph ending "...The production pattern is a three-phase round-trip: extract the subgraph from the database, run analytics on GPU, and write the results back as node properties." and before the Example 8-11 heading)

Replacement/Insertion text:

Before writing GPU-accelerated graph code, understand where your actual bottleneck is---it may not be on the GPU at all. A class of performance problems invisible to naive wall-clock timing creates GPU idle time that neither throughput benchmarks nor wall-clock comparison reliably surfaces.

Sayak Paul (HuggingFace, April 2026) documents the methodology for finding these hidden bottlenecks: a module tree traversal calling named_modules() across 400+ submodules eight times per denoising step accumulated 21.6ms of pure Python overhead per iteration. The wall-clock improvement after elimination was 0.8%, from 574.3ms to 569.8ms on H100---the GPU was already masking the CPU overhead by executing concurrently. Standard wall-clock timing completely misses this class of problem.

The correct diagnostic is trace analysis: torch.profiler with record_shapes=True, profile_memory=True, and with_stack=True, exported as Chrome JSON and analyzed in Perfetto UI. Searching the trace for cudaStreamSynchronize events reveals every point where CPU logic forces GPU drain before continuing. For your graph analytics pipeline, the three anti-patterns to search for are: .item() or nonzero() calls on GPU tensors forcing synchronous device drain, torch.tensor(gpu_scalar) pulling GPU values to CPU instead of torch.stack(), and module tree traversals inside inference loops cached on first call rather than repeated per step. Any of these prevents kernel fusion under torch.compile and creates compounding overhead at the graph sizes typical of production infrastructure Knowledge Graphs.

===SECTION 11: GPU Observability as Prerequisite===

Placement: Inserts after: Line 790 (after the # Common Pitfalls heading and the paragraph "Optimization introduces its own failure modes. The pitfalls below are the ones most likely to surface in production." and before the first pitfall paragraph beginning "Routing to models that cannot handle edge cases.")

Replacement/Insertion text:

Measuring the wrong thing. You cannot optimize what you cannot measure, and standard GPU monitoring stacks regularly measure the wrong thing. Paul Gresham (April 2026) documents three specific failures on DGX Spark hardware: unified memory misreported (shared CPU-GPU memory read as discrete), HugePages ignored entirely, and ARM big.LITTLE topology flattened to a single compute tier. The root cause is that most monitoring tools assume x86 plus discrete GPU. As ARM GPU hardware (Grace Hopper, Jetson) becomes standard, this accuracy gap widens.

The consequence for optimization is worse than just wrong dashboard numbers. If your monitoring stack misreports GPU memory utilization, your batch size tuning is based on incorrect headroom estimates, your KV cache sizing decisions are based on incorrect allocation data, and your cost-per-invocation calculations are based on incorrect utilization figures. Every downstream optimization built on inaccurate hardware telemetry is potentially wrong.

The fix is spec-compliant monitoring that reads NVML directly rather than wrapping abstraction layers. Gresham's nv-monitor is a single C file, under 80KB binary, zero runtime dependencies, that exports 20+ Prometheus metrics by reading the hardware specification directly. Before tuning inference parameters, validate your monitoring pipeline with a synthetic load generator---confirm that the dashboard numbers respond correctly to known workloads before trusting them to guide production decisions.

===SECTION 12: Encoder Inference Optimization===

Placement: Inserts after: Line 531 (within the "Optimized serving" section, after the vLLM multi-LoRA description, specifically after "TensorRT-LLM offers 30-50% higher throughput at scale but requires more engineering overhead to deploy." and before the "Session-level KV reuse" paragraph added in Section 7 above)

Replacement/Insertion text:

Encoder serving as a distinct optimization domain. Your DevOps agent's retrieval pipeline uses encoder models for embedding generation, reranking, and named entity recognition. These are not decoder models and do not benefit from the same optimizations. Running encoder inference through a continuous batching framework designed for decoders wastes GPU capacity through padding inefficiency and causal masking overhead that encoders do not need.

vLLM Factory (Dennis D., April 2026) demonstrates that encoders served through a pooling runner pattern---continuous batching without padding waste, no causal masking overhead---achieve 3.3x to 11.7x throughput improvements over reference implementations. The framework handles ColBERT retrieval, embedding models, and NER variants behind a single /pooling endpoint through vLLM's existing scheduler infrastructure.

For your agent's retrieval stack, this has a practical implication: consolidate embedding generation, late-interaction retrieval, and entity extraction behind a single serving framework rather than running separate services for each. The operational overhead of maintaining separate services for embeddings, reranking, and NER compounds at scale. A unified serving layer with shared GPU scheduling eliminates this overhead while the plugin extensibility means future vLLM optimizations propagate to all encoder workloads automatically, without maintaining forks.

===SECTION 13: Wafer-Scale and Alternative Hardware Architectures===

Placement: Inserts after: Line 533 (within "Specialized hardware", after the paragraph ending "These numbers were independently verified by Artificial Analysis at up to 75x faster than hyperscaler GPU offerings. SambaNova's SN50 RDU targets multi-model serving specifically, with a tiered memory architecture that enables millisecond-level hot-swapping between specialist models.")

Replacement/Insertion text:

The roofline model explains why specialized hardware achieves these numbers rather than optimized GPU configurations. At batch-1 decode, a 70B model performs 140 GFLOP on 140 GB of weights, yielding 1 FLOP/byte arithmetic intensity. The H100's ridge point at 295 FLOP/byte means tensor cores operate at 0.3% utilization during decode. Emilio Andere (April 2026) documents that this gap is worsening generationally: V100 shows a 139x gap between decode intensity and the compute-bound threshold, H100 shows 295x, and B200 shows 563x. Software optimization cannot close a gap this structural.

Cerebras's WSE-3 addresses this by replacing off-chip HBM with 44 GB of distributed on-chip SRAM at 21 PB/s aggregate bandwidth---7,000x more bandwidth than the H100's 3.35 TB/s. This pushes the ridge point to 0.6 FLOP/byte, making batch-1 decode compute-bound for the first time in any shipping architecture. The practical ceiling is the 133,000x bandwidth gap between on-chip SRAM and off-chip interconnects: models exceeding 44 GB SRAM reintroduce bandwidth bottlenecks, limiting the advantage to models that fit on-chip.

For edge inference, Quadric's Chimera GPNPU (Veerbhan K., April 2026) addresses a structural flaw in conventional NPU design. Every conventional NPU advertises TOPS for its matrix multiply engine only; when a model hits branching, custom activations, or attention operators outside the matrix engine's scope, execution falls to a general-purpose control CPU that runs 100-1,000x slower. Cadence's analysis of SWIN Transformer finds 77% of the workload on this fallback processor. Chimera fuses a tensor engine and general-purpose processor into every core with shared memory, eliminating the fallback cliff. For agentic inference systems, this matters because MoE routing, GQA, and custom activation functions---the structural features of frontier models---are precisely the workloads that trigger the fallback penalty on conventional NPUs.

===SECTION 14: Open-Source Infrastructure Cost Architecture===

Placement: Inserts after: Line 545 (after the ## Latency Budgets section's list ending "End-to-end with specialized inference hardware: single-digit seconds for 30+ model calls." and before the sentence "Industry guidance converges on sub-100ms...")

Replacement/Insertion text:

The self-hosting calculus. The serving frameworks above are all open-source, but "open-source" does not mean "free." Paolo Perrone (April 2026) documents the hidden cost structure: commercial APIs price at $0.01--0.03 per 1K tokens to cover hosting margins and demand elasticity. Self-hosted vLLM on equivalent hardware drops marginal cost to $0.001--0.003 per 1K tokens because GPU compute becomes a fixed cost amortized across all requests. The 10x cost reduction headline transfers hidden costs from financial expenditure to operational complexity: GPU fleet management, CUDA driver compatibility, model version upgrades, security patching, and on-call coverage.

For most production teams, a hybrid approach captures the majority of savings without the full operational burden: self-hosted serving for predictable base load (the steady stream of routine deployment events the DevOps agent processes continuously), API for burst capacity (the sudden alert spikes during incidents). This captures 60--70% of the savings without requiring a dedicated inference platform team.

The build-vs-buy decision depends on three variables: inference volume (high volume favors self-hosted; the break-even point for a single H100 instance versus API calls is typically 5--10M tokens per day), team GPU expertise (low expertise favors managed API), and P99 latency requirements (strict P99 targets favor managed infrastructure with contractual SLAs). At $150/hour loaded engineering cost, 20--30 hours/month of self-hosted infrastructure operations equals $3,000--4,500/month in implicit labor---potentially exceeding the original API bill for lower-volume deployments.

===SECTION 15: Statistical Verification for Cost Optimizations===

Placement: Inserts after: Line 789 (after the pitfall "Benchmarking models on the wrong evaluation set" ending "...build a per-node evaluation set from real production data, and re-evaluate whenever the task distribution changes." and before the pitfall "Ignoring cold-start latency for GPU acceleration.")

Replacement/Insertion text:

Detecting silent quality degradation from optimization changes. The per-node evaluation sets described earlier measure quality at a point in time. What they do not detect is subtle degradation introduced by quantization, serving framework upgrades, or batch size changes---changes small enough that aggregate accuracy metrics miss them but large enough to compound dangerously across multi-step agentic workflows.

McNemar's test, applied at the sample level rather than the task aggregate, detects accuracy changes as small as 0.3% while controlling false positive rates. Kubler et al. (Amazon, ICLR 2026) demonstrate that standard benchmarking creates a false sense of safety: the same LLM generates different responses depending on hardware, framework, and batch size, and sample-level testing catches degradations that task-level aggregates mask. For agentic systems that chain 5--15 inference calls per workflow, a 0.3% per-call degradation across 10 chained calls produces a 3% cumulative accuracy drop. That is the difference between an agent that is trusted with automated incident remediation and one that requires human review on every recommendation.

The tool is open-source, built on LM Evaluation Harness, and integrates directly with the per-node evaluation infrastructure described earlier in this chapter. Run it after every serving framework upgrade, every quantization change, and every model version bump before promoting to production.

Placement Summary

Section	Action	Location in Original Chapter
Section 1: Constraint-First Framing	Insert	After line 17, before "# Selective Intelligence" heading
Section 2: WRP Framework intro	Insert	After line 45, before "### Static routing by node type"
Section 3: IBM Workflow Taxonomy	Insert	After line 102, after "static routing or threshold cascading" paragraph
Section 4: Prompt Caching Economics	Insert	After line 156, before Kakao paragraph
Section 5: Tokenomics Business Case	Insert	After line 209, before "# Data Governance" heading
Section 6: SHACL Streaming Validation	Insert	After line 258, within Execution Graph section
Section 7: Delta Computation / Session KV	Insert	Within "Inference Acceleration" section, after TensorRT-LLM sentence
Section 8: Disaggregated Serving (MLPerf)	Insert	After specialized hardware bullet, before "These three approaches compose"
Section 9: TMA GPU Programming Model	Insert	After line 454, within "GPU-Accelerated Graph Operations" section
Section 10: CPU-GPU Sync Profiling	Insert	After line 458, before "Example 8-11"
Section 11: GPU Observability Pitfall	Insert	After line 790, first item under "Common Pitfalls"
Section 12: Encoder Inference	Insert	Within "Optimized serving" subsection, after TensorRT-LLM sentence
Section 13: Wafer-Scale Hardware	Insert	Within "Specialized hardware" bullet, after SambaNova sentence
Section 14: Open-Source Cost Architecture	Insert	After Latency Budgets list, before "Industry guidance" sentence
Section 15: Statistical Quality Verification	Insert	In "Common Pitfalls", after "wrong evaluation set" pitfall

New Examples Added

No new code examples in this revision draft. Existing Example 8-11 through 8-16 remain unchanged. If the editor wishes to add code for the prompt caching breakpoint pattern or the McNemar's test integration, recommend starting at Example 8-17.

Line Count Estimate

Section	Approximate Lines
Section 1: Constraint-First Framing	~8 lines (net new)
Section 2: WRP Framework intro	~10 lines (net new)
Section 3: IBM Workflow Taxonomy	~9 lines (net new)
Section 4: Prompt Caching Economics	~18 lines (net new)
Section 5: Tokenomics Business Case	~14 lines (net new)
Section 6: SHACL Streaming Validation	~10 lines (net new)
Section 7: Delta Computation / Session KV	~11 lines (net new)
Section 8: Disaggregated Serving	~12 lines (net new)
Section 9: TMA GPU Programming Model	~14 lines (net new)
Section 10: CPU-GPU Sync Profiling	~13 lines (net new)
Section 11: GPU Observability Pitfall	~11 lines (net new)
Section 12: Encoder Inference	~10 lines (net new)
Section 13: Wafer-Scale Hardware	~14 lines (net new)
Section 14: Open-Source Cost Architecture	~12 lines (net new)
Section 15: Statistical Quality Verification	~10 lines (net new)
Net addition	~176 lines (~5 pages)

Sources Integrated

Source	Section	Key Contribution
James Noh / Baseten (a16z, 2026)	Section 1	Constraint-first optimization framing, P99 as SLO currency
Chen et al. / vLLM WRP Framework (arXiv 2603.21354, 2026)	Section 2, 7	WRP three-dimensional inference optimization model
IBM Research / Saravia (arXiv 2603.22386, 2026)	Section 3	Workflow taxonomy mapping routing strategies; verifier signals vs trace feedback
Alexey M. (2026)	Section 4	KV cache economics: 10x price ratio explanation, 93--96% hit rates in production
Vin Vashishta (March 2026)	Section 5	Tokenomics framework; Sora/Copilot failure case studies
Ayesha Khanna (2026)	Section 5	$100K annual token budgets as organizational norm
Ashley Caselli / TopBraid SHACL API 1.5.0 (March 2026)	Section 6	Streaming SHACL validation via Jelly I/O for incremental graph update pipelines
Victor Norgren / LayerScale (April 2026)	Section 7	Delta computation; context affinity routing; session-level KV persistence
Asheesh Goja (March 2026)	Section 8	Roofline model; disaggregated serving physics
Emilio Andere / MLPerf v6 (April 2026)	Section 8, 13	2.77x throughput via disaggregated serving; 95.5% heterogeneous GPU efficiency; AMD latency win
Florian Mattana / TMA Hopper (April 2026)	Section 9	Declarative memory access; mbarrier; XOR swizzle correctness trap
Aleksa Gordic H100 matmul (March 2026)	Section 9	32 → 317 TFLOP/s benchmark quantifying TMA impact
Sayak Paul / HuggingFace (April 2026)	Section 10	CPU-GPU sync elimination; PyTorch Profiler + Perfetto trace methodology
Paul Gresham / nv-monitor (April 2026)	Section 11	GPU observability accuracy gap on DGX Spark; NVML-direct monitoring
Dennis D. / vLLM Factory (April 2026)	Section 12	Encoder inference: 3.3x--11.7x throughput gains via pooling runner pattern
Emilio Andere / Cerebras WSE-3 roofline (April 2026)	Section 13	Ridge point escalation V100→H100→B200; 21 PB/s SRAM bandwidth
Veerbhan K. / Quadric Chimera GPNPU (April 2026)	Section 13	No-fallback architecture; 77% fallback workload on conventional NPUs
Paolo Perrone (April 2026)	Section 14	Open-source LLM infrastructure cost breakdown; hybrid deployment economics
Kubler et al. / McNemar's test (Amazon, ICLR 2026)	Section 15	Sample-level degradation detection; 0.3% sensitivity; compounding agentic chain degradation

AnthonyAlcaraz/ch2-revision-draft-2026-04-06.md

Select an option

No results found

Select an option

No results found

Chapter 2: Agentic Graph Architecture Foundations — Revision Draft

The harness as operating system: lessons from Claude Code

Placement Summary

Line Count Estimate

Sources Integrated

Chapter 8 Revision Draft: Optimization

Prompt caching as a cost multiplier

The business case: tokenomics of agentic systems

Placement Summary

New Examples Added

Line Count Estimate

Sources Integrated