diff --git a/blog/2026-08-07-infer-forge-loop-engineering.md b/blog/2026-08-07-infer-forge-loop-engineering.md
new file mode 100644
index 000000000..32c7d26cf
--- /dev/null
+++ b/blog/2026-08-07-infer-forge-loop-engineering.md
@@ -0,0 +1,456 @@
+---
+title: "Infer-forge: Loop and Graph Engineering Around SGLang"
+author: "Tianyu Zhang, Hanlin Gao, Yusong Gao, Yun Zhang"
+date: "August 7, 2026"
+previewImg: /images/blog/infer-forge-loop/cover.png
+type: blog
+---
+
+## 1. Introduction
+
+**Inference optimization may look local in code, but its validity is global.** A kernel, communication path, or scheduling change becomes meaningful only at a specific deployment point defined by the model, workload, SLO, serving topology, runtime version, and accelerator platform. The same patch may improve one point and regress another. Agent-assisted exploration can produce more environments, experiments, measurements, and rejected paths, all of which must remain reproducible.
+
+**The first requirement is therefore reliable execution.** Reproducing a deployment point requires more than model capability: tools, environments, context, memory, Verification, and safety boundaries must remain stable. **Harness Engineering** turns those surrounding conditions into a reproducible and inspectable execution system—the basis for the abstraction **Agent = Model + Harness**[1](#ref-1),[2](#ref-2),[3](#ref-3),[6](#ref-6).
+
+**Reliable execution must then remain coherent over time.** Inference engineering Tasks often span repeated rounds of investigation, implementation, deployment, Evaluation, failure, and recovery. **Loop Engineering** connects successive executions so that one Task can preserve its Task Contract, incorporate new evidence, and satisfy its Exit Criteria by producing either a verified Deliverable or a reliable Follow-up Handoff[4](#ref-4),[5](#ref-5),[7](#ref-7).
+
+**Project-scale work exceeds the boundary of one Task.** Multiple Tasks must proceed in parallel, exchange Deliverables, share state, trigger Rework, and change direction as evidence accumulates. **Graph Engineering** organizes independently convergent Task Loops into an evolving **Task Graph**. The graph keeps released and rejected paths connected to their dependencies, constraints, and evidence, so project decisions remain explainable[10](#ref-10),[11](#ref-11),[12](#ref-12),[13](#ref-13).
+
+**Infer-forge is our implementation of this progression for inference engineering around SGLang.** Its scope follows an engineering change through the inference stack: from kernels and communication libraries, through engine integration and deployment, to Evaluation and online diagnosis. One shared workspace and three accumulating execution structures keep that end-to-end path coherent:
+
+- **MonoRepo** establishes a reproducible workspace for cross-repository engineering.
+- **Harness** supplies reusable execution capabilities, memory, Verification, and safety boundaries.
+- **Task Loop** keeps one long-running Task moving until it reaches its Exit Criteria.
+- **Task Graph** connects independently convergent Tasks into larger objectives, including project delivery and capability evolution.
+
+**Infer-forge has moved from workflow design into sustained engineering use.** Across one engineer's April–July record, the peak number of **Tasks in flight** rose from **2 to 9**—an observed **4.5× increase in engineering concurrency**. In one DeepSeek-V4-Pro serving project, **38 independently verifiable Task nodes across seven Task Types** were coordinated as a Task Graph. Together, these records show infer-forge operating at both concurrent-Task and project scale in real inference engineering.
+
+**A capable Agent can make one execution succeed; an engineering system is designed to make successful work reproducible.** Infer-forge does not promise that every Task will finish faster. It provides the structure to preserve the provenance of each deployment point, sustain verifiable work over long-running Tasks, and coordinate evidence across Task boundaries.
+
+## 2. Inference as a Deployment Space
+
+
+
+
+ Figure 1: The Constraint Chain Behind an Inference Deployment Point.
+
+
+Figure 1 turns the deployment point introduced above into a concrete chain of constraints. The **Model** determines the supported modalities and model-specific execution paths. The **Serving Scenario** translates **Modality** and **Traffic Shape** into an **SLO**. That SLO constrains the **Serving Topology**, where a **Deployment Architecture** is combined with a **Parallelism** strategy. The topology is then realized through a **Versioned Runtime Profile** that pins the engine configuration and container image for a particular service revision. Finally, the complete runtime must be built and verified on an **Accelerator Platform**. A deployment point is the full path through this chain—not any one layer in isolation.
+
+**There is no context-free inference optimization.** Different serving objectives and SLOs can require fundamentally different deployment paths, including `Colocated PD`, `PD Disaggregation`, and `EPD Disaggregation`. Each architecture changes stage boundaries, communication paths, resource balance, and the set of feasible Parallelism strategies. Those decisions propagate into the runtime profile and accelerator-specific implementation that must be verified. A kernel improvement becomes a serving result only when the complete deployment point reproduces it and passes throughput, latency, correctness, and stability gates. **Without its deployment point, a performance claim cannot be reproduced, compared, or carried forward.**
+
+**Infer-forge does not eliminate this combinatorial space; it makes every movement through it explicit and verifiable.** Instead of asking an Agent to “optimize DeepSeek-V4-Pro,” we define a Task that records the current deployment point, bounds the subset of dimensions it may change, and fixes the Verification gates before execution begins. A Task might replace the MoE backend while holding the serving scenario, topology, and accelerator constant, then produce either an accepted improvement or a documented rejection. Both outcomes reduce uncertainty for the next Task. Before any of them can be reproduced, however, the exact cross-repository code state behind the deployment point must be fixed. That is the role of the MonoRepo.
+
+## 3. MonoRepo
+
+### 3.1 Why a MonoRepo
+
+**Inference optimization crosses repository boundaries, but it must ship as one coherent system.** A change may begin in a kernel library, depend on a communication backend, enter SGLang through engine integration, and finally require a matching deployment configuration. When these repositories live in separate workspaces, their relationships become transient knowledge that engineers and Agents must repeatedly reconstruct. One missing branch or incompatible revision is enough to invalidate the result.
+
+**Infer-forge turns that dependency map into a shared workspace.** Git submodules place the relevant repositories under one root while preserving their independent histories, branch policies, access controls, and release processes. The root gives engineers and Agents a stable map of the inference stack and one entry point from which cross-repository work can be developed and verified.
+
+This structure changes cross-repository work in three ways:
+
+- **The whole stack stays in view.** Repository boundaries remain explicit, but their engineering relationships are visible from one workspace.
+- **Context stays bounded.** An Agent can navigate the full repository map while loading only the repositories required by the current Task.
+- **Integration starts in place.** Related branches can be developed, combined, and verified without repeatedly locating repositories or rebuilding their relationships from memory.
+
+**The workspace coordinates change; the Task record makes it durable.** Each Task captures the branches, commits, and execution state used for the work, and the Journal archives that record after completion. The repositories can continue evolving without erasing the provenance of work that has already been verified and delivered.
+
+### 3.2 Repository Map
+
+
+
+
+ Figure 2: Infer-forge MonoRepo.
+
+
+**One workspace does not mean one undifferentiated codebase.** Infer-forge separates repositories by the role they play in engineering: the **Built-in Workspace** coordinates cross-repository work, the **Inference Stack Repos** contain the serving system being changed, and the **Harness Repos** carry those changes from execution to verified evidence.
+
+#### Built-in Workspace
+
+**The Built-in Workspace is the coordination layer of infer-forge, not another implementation repository.** Code remains in the repository that owns it. The root contains only the mechanisms that need to operate across repository boundaries:
+
+- **Task System** materializes the workspace required by a Task: the relevant repositories, environment entry points, record locations, and—when isolation is required—a dedicated worktree and Agent session.
+- **Cross-lib Management** makes the repository graph operable. It maintains repository locations, default branches, and the operations used to synchronize and integrate changes. The actual branches and commits used for a piece of work belong to the Task record and are archived into the Journal.
+- **Skills** expose capabilities at the scope where they belong. The root provides Skills for Task lifecycle and cross-repository coordination; each repository retains the Skills specific to its own domain.
+
+#### Inference Stack Repos
+
+**Inference Stack Repos are where serving behavior and performance actually change.** [SGLang](https://github.com/sgl-project/sglang) is the center of the stack, while [Dynamo](https://github.com/ai-dynamo/dynamo) organizes SGLang instances into a distributed service. [DeepGEMM](https://github.com/deepseek-ai/DeepGEMM), [FlashMLA](https://github.com/deepseek-ai/FlashMLA), [FlashInfer](https://github.com/flashinfer-ai/flashinfer), and [Humming](https://github.com/inclusionAI/humming) provide specialized compute kernels. [DeepEP](https://github.com/deepseek-ai/DeepEP) and [Mooncake](https://github.com/kvcache-ai/Mooncake) provide expert-parallel communication and cross-node KV transfer. These repositories evolve independently, but one serving result may depend on changes across several of them at once.
+
+#### Harness Repos
+
+**Code does not become an engineering result merely because an Agent can edit it.** Harness Repos provide the capabilities that carry a change through the rest of its lifecycle: finding compute resources, preparing environments, deploying the service, running performance and correctness Evaluation, diagnosing failures and online behavior, preserving long-term records, and enforcing safety boundaries. They turn otherwise disconnected operational steps into a repeatable path from code change to verified Deliverable.
+
+**Together, the three groups form one engineering path: the Built-in Workspace prepares and coordinates the work, the Inference Stack Repos supply the system under change, and the Harness Repos carry that change to Verification.** Infer-forge brings them into one workspace without forcing them into one repository history, ownership model, or release process.
+
+## 4. Task Loop
+
+**The MonoRepo provides the workspace; the Task Loop structures how work advances over time.** Inference engineering often requires multiple rounds of Research, implementation, deployment, Evaluation, and recovery. The Task Loop keeps those executions aligned with one Goal and Task Contract until they satisfy their Exit Criteria through a verified Deliverable or a reliable Follow-up Handoff.
+
+**“Everything Can Be a Task” applies to independently verifiable units of work, not to every action.** A Task needs its own Goal, Scope, Acceptance, Verification path, and Exit Criteria. Commands and intermediate experiments remain inside it as Loop Block instances or tool calls. Once a unit of work can complete or hand off independently, it can become a Task node in a larger Task Graph.
+
+### 4.1 Overview
+
+
+
+
+ Figure 3: Task Loop Overview.
+
+
+**A Task Loop keeps its boundary stable while allowing its execution path to adapt.** **Task Definition** establishes the Task Type, Starting Context, Task Contract, and Exit Criteria. The **Main Loop** advances the work through a sequence of **Loop Block** instances and uses **Task Goal Met?** to decide whether to exit or continue. **Task Memory** preserves the current state, next Sub-target, Execution Records, and Handoff between iterations.
+
+**The Harness surrounds the loop rather than acting as another stage inside it.** It supplies the resources, methods, memory systems, Verification entry points, and safety boundaries required during execution. Different Tasks can use those capabilities in different orders without being forced through one fixed pipeline.
+
+### 4.2 Task Definition
+
+
+
+
+ Figure 4: Task Definition.
+
+
+**A Task Loop begins with a testable commitment, not with activity.** Before an agent searches the codebase, launches a deployment, or consumes evaluation capacity, the Task must state what it is trying to accomplish and how the result will be judged. **Task Definition** establishes four anchors:
+
+- **Task Type** selects a default Playbook.
+- **Starting Context** records the state from which execution begins.
+- **Task Contract** fixes the Goal, Scope, Acceptance, and Verification.
+- **Exit Criteria** define the durable **Deliverable** or **Follow-up Handoff** that execution must produce.
+
+#### 4.2.1 Task Type
+
+**A Playbook turns prior practice into a head start.** For each Task Type, it provides a lightweight, adaptable template: which repositories are likely to matter, which **Skills**, **Tools & CLI**, and Verification entry points are relevant, and which safety boundaries apply. This reduces the space the agent must search before useful work can begin.
+
+**A Playbook standardizes the starting approach, not the complete execution path.** The agent may change methods, introduce new Loop Block instances, or use capabilities outside the template as the **Task Contract** and new evidence require. It reduces repeated discovery without replacing engineering judgment.
+
+**Each Task Type captures a distinct unit of verifiable work in inference engineering:**
+
+- **Plan** defines objectives, constraints, and decomposition, then delivers an executable plan for downstream Tasks.
+- **Research** investigates a bounded uncertainty, evaluates available evidence, and delivers conclusions with explicit limitations.
+- **Code** implements any scoped code change and delivers the change together with its Verification evidence.
+- **Integration** assembles changes from multiple upstream Tasks, including across repositories or components, and verifies the combined system.
+- **Evaluation** runs functional, performance, accuracy, stress, and stability assessments and delivers evidence against Acceptance.
+- **Release** advances a verified candidate through approval, canary rollout, expansion, or rollback and records the outcome.
+- **Online Diagnosis** investigates a production issue within read-only boundaries and hands required changes to downstream Tasks.
+- **Capability** maintains the versioned **Skills & Tools** set through `Add`, `Update`, `Merge`, `Retire`, or `No Change`.
+- **+ Custom** handles verifiable work without a reusable Playbook while preserving the same Task Definition.
+
+**The taxonomy is earned through repeated practice.** An activity becomes a built-in Task Type only after its starting conventions, Acceptance boundary, and Deliverable are stable enough to guide future work. Standardization follows proven practice; it does not attempt to predict every path in advance.
+
+#### 4.2.2 Starting Context
+
+**Starting Context draws the line between known state and assumption.** A Task may begin from a blank state, a prepared environment, or an upstream result. What matters is that the source and verification status of that state remain explicit.
+
+- **Custom Setup** records conditions prepared for the current Task, such as the model, container image, deployment profile, repository versions, dataset, or experiment entry point.
+- **Imported Context** carries forward an upstream environment, intermediate result, or **Follow-up Handoff**, together with its provenance and verification status.
+
+#### 4.2.3 Task Contract
+
+**The Task Contract holds the target still while execution adapts.** **Goal** states the intended outcome, **Scope** bounds the work, **Acceptance** states the observable conditions for success, and **Verification** defines the evidence required to judge them[6](#ref-6). Without this boundary, an agent can appear to succeed simply by changing the problem after seeing the result.
+
+For an inference optimization Task, the contract may fix the model and weight format, hardware placement, serving topology, runtime versions, workload grid, and baseline. Acceptance can then require better throughput, TTFT, or TPOT without violating accuracy or stability. Changing the topology, GPU class, or workload after observing the result is a contract change—not an optimization result.
+
+**Evidence may redirect the Main Loop, but it must not silently move the finish line.** A clarification that does not materially change the Goal, Scope, or Acceptance must be explicit and recorded; a material change to any of them starts a new Task.
+
+#### 4.2.4 Exit Criteria
+
+**A Task does not end because activity stops. It ends when its state can be verified or safely continued.**
+
+- A **Deliverable** packages the completed result with enough evidence to verify the Task Contract.
+- A **Follow-up Handoff** preserves completed work, current state, unresolved questions, and the next entry point when another Task must continue the work.
+
+**Exit Criteria turn execution into durable engineering state: either a verifiable result or a reliable starting point for the next Task.**
+
+### 4.3 Loop Execution
+
+
+
+
+ Figure 5: Loop Execution.
+
+
+**A Task is sized by its engineering objective, not by the duration of a runtime session.** The Task Contract defines the complete objective; the Main Loop realizes it through one or more **Loop Block** instances as evidence emerges. When defining a Task, the user does not need to predict whether it can finish within one sustained runtime loop.
+
+**The Task is the unit of continuity; the Loop Block is the unit of execution.** Each Loop Block owns one Sub-target, one Exit Condition, one routing decision, and one set of Execution Records. Claude Code `/loop` and Codex `/goal` are current execution entry points, but neither determines the scope of the Task.
+
+#### 4.3.1 Main Loop
+
+**The Main Loop turns an open-ended Task into a sequence of evidence-producing Loop Blocks:**
+
+- **Define Loop Block** selects the current Sub-target and Exit Condition.
+- **Execution Routing** selects the Model Tier and Agent Topology for that Sub-target.
+- **Execute Loop Block** runs the block through an available sustained-execution entry point.
+- **Task Goal Met?** compares the accumulated state with the Task Contract and decides whether to exit or define another block.
+
+**Completing a Loop Block is not the same as completing the Task.** A block may confirm a hypothesis, reject an approach, or expose a new constraint. Its Exit Condition closes that local unit of work; **Task Goal Met?** determines whether the accumulated evidence satisfies the whole Task Contract. The Yes branch proceeds to Exit Criteria, while the No branch defines the next Loop Block from the evidence already produced.
+
+#### 4.3.2 Task Memory
+
+**Task Memory makes the Loop Block sequence durable and traceable.** It preserves completed Loop Blocks and the active Current Loop Block, including its Sub-target and Exit Condition. A Next Loop Block is recorded only after the current block ends and **Task Goal Met?** determines that the Task must continue.
+
+**Execution Records capture what the agent did at each step and what result it produced.** They make the execution auditable, traceable, and reproducible.
+
+**A Loop Block Handoff transfers state inside one Task; a graph-level Handoff edge connects independent Task node instances.**
+
+#### 4.3.3 Execution Routing
+
+**Execution Routing makes two orthogonal choices for the current Loop Block:**
+
+- **Model Tier** follows reasoning difficulty. Uncertainty, reasoning depth, and required expertise determine whether the block uses **Lower-tier**, **Mid-tier**, or **Strongest Available**.
+- **Agent Topology** follows content volume and expected context length. Work that fits reliably within one context uses **Single Agent**; work that must be divided across contexts uses **Multi-Agent**[14](#ref-14).
+
+A difficult but compact problem may use **Strongest Available** with **Single Agent**. A large but routine evaluation matrix may use **Lower-tier** or **Mid-tier** with **Multi-Agent**. Model Tier supplies reasoning capability; Agent Topology manages context load.
+
+Figure 5 shows one possible **Multi-Agent** topology: a **Coordinator** works with Infra, Code, and Eval, while **Reviewer** examines the result outside the main execution chain[7](#ref-7). The roles are illustrative; the actual decomposition follows the content and context requirements of the current Loop Block.
+
+If model-tier selection or subagents are unavailable, the Loop Block proceeds with the capabilities provided by the runtime, with the fallback preserved in its Execution Records.
+
+### 4.4 Harness
+
+**A Task Loop can sustain progress only if the Harness can sustain execution.** Without a stable Harness, every Loop Block must rediscover machines, reconstruct environments, locate commands, recover evidence, and renegotiate safety boundaries. Infer-forge instead provides one execution substrate built from **Node Registry**, **Skills & Tools**, **Journal**, and **Safety Guard**.
+
+**The value lies in composition, not in any capability alone.** After Task Definition, an agent can inspect resource state, prepare an environment, deploy a workload, modify and evaluate the system, and recover on another Node when necessary. Node state, operational methods, execution history, and safety constraints remain connected throughout the process, so a human does not have to rebuild the path between steps.
+
+#### 4.4.1 Node Registry
+
+
+
+
+ Figure 6: Node Registry.
+
+
+**Resource autonomy cannot begin from a guess about Node ownership.** The **Node Registry** is a Git-backed repository that reconciles declared occupancy with observed machine activity:
+
+- **Git Ledger** records which Task claims each Node. Every claim, release, and correction remains versioned and auditable.
+- **DCGM Observation** reports whether a workload is actually running on the machine.
+
+Reconciliation distinguishes **Held by Task**, **Idle < 6h**, and **Idle ≥ 6h → reclaim**. Under the current **Idle Reclaim** policy, a claim observed idle for six continuous hours is removed and the Node becomes available again. The interval is a governance parameter, not a scheduling guarantee.
+
+**The Node Registry does not select Nodes, queue work, or launch workloads. It gives those actions a trustworthy and auditable starting point.**
+
+#### 4.4.2 Skills & Tools
+
+
+
+
+ Figure 7: Skills & Tools.
+
+
+**A capable agent should not rediscover how to perform the same engineering work for every Task.** **Skills** preserve reusable approaches across SGLang Upstream, Cross-lib, Task, and Ops. **Tools & CLI** expose stable, recordable interfaces for deployment, build, weight and code synchronization, Evaluation, profiling, online diagnosis, and monitoring.
+
+A Playbook selects the relevant subset for the current Task Type. Skills narrow the decision space; Tools & CLI turn the selected decision into an action whose inputs and outputs can enter Execution Records. The agent starts from accumulated practice without being forced through a fixed path.
+
+**Skills & Tools is a versioned capability baseline, not a growing pile of instructions.** Ordinary Tasks use the current baseline. A Capability Task uses Journal evidence and revalidation after a `Model or runtime change` to decide what should be added, updated, merged, retired, or left unchanged.
+
+#### 4.4.3 Journal
+
+
+
+
+ Figure 8: Journal.
+
+
+**Evidence compounds only when the next Task can find and reuse it.** Task Memory preserves the execution state of one Task; the **Journal** carries evidence across Tasks. **LLM-wiki** connects Task records into a knowledge network, while **Multi-dim Index** organizes them by dimensions such as model, Task Type, and GPU. Together, they support Retrieve, Compare, and Filter without forcing each Task to rediscover the same facts.
+
+In one benchmark Task, the Journal surfaced an earlier record showing that `bench_serving.py` did not count `delta.reasoning_content` for reasoning models. That bug invalidated the apparent TTFT and throughput baseline. Reusing the record prevented the next Task from treating a measurement error as an engine regression.
+
+**The Journal preserves evidence; it cannot promote evidence directly into executable capability.** Any change to the Skills & Tools baseline must pass through a Capability Task and Verification.
+
+#### 4.4.4 Safety Guard
+
+
+
+
+ Figure 9: Safety Guard.
+
+
+**As agent execution becomes longer and more concurrent, an unenforced mistake can travel farther.** **Safety Guard** therefore applies constraints that no Playbook or Loop Block may bypass:
+
+- **Push Guard** and **Traceable Path** constrain how code changes move.
+- **Env Isolation** and **Production Read-only Access** constrain environments and production operations.
+- **Secrets** and **Data** constrain access to credentials and governed datasets.
+- **Human Gate** requires approval for high-risk actions.
+- **Cross-Model Adversarial Review** applies `reviewer ≠ coder` to reduce self-review blind spots[6](#ref-6).
+
+**Safety Guard constrains actions; Verification constrains claims.** In one kernel optimization Task, a candidate appeared to reach `72.30 TFLOPS`, a `5.7%` improvement over its comparison point. A later Verification exposed a race: aggregate statistics looked stable while individual elements were corrupted. The candidate was rejected before Integration.
+
+**Reliable autonomy is measured not only by what it completes, but also by what it refuses to advance.** In inference engineering, stopping a false performance win can be more valuable than producing another patch.
+
+## 5. Task Graphs
+
+
+
+**A project does not scale merely by creating more Tasks. It scales when dependencies, shared state, and control decisions become explicit.** A Task Loop gives one Task an independent path to convergence; a Task Graph connects those convergent units without dissolving their Verification boundaries.
+
+**A Task Graph is not a fixed workflow template or a closed taxonomy.** Whenever multiple Tasks need explicit dependencies, verified Handoffs, shared state, or control relationships, they can be organized into a Task Graph. The graph can serve one project, one investigation, one release, or any other objective that exceeds a single Task boundary.
+
+**Delivery Graph and Capability Graph are two recurring examples, not the only valid graph structures.** We use them to demonstrate the same graph language in two common situations: coordinating Tasks that jointly change the inference system, and maintaining the capabilities used by future Tasks.
+
+**Graph correctness begins by separating execution from state and external control.** Only a **Task node** executes work and runs a Task Loop. A **Shared repo** stores persistent state without running a loop. An **External system** represents people or platforms that interact with the graph from outside infer-forge.
+
+The edge type states what crosses each boundary:
+
+- A **Handoff edge** carries a verified Deliverable or Follow-up Handoff that becomes Imported Context for the successor Task.
+- A **State edge** represents a read from or write to a Shared repo; it does not imply Task completion or Verification.
+- A **Control edge** triggers work, returns it for revision, or changes its direction without carrying a verified result.
+
+**A write is not a Handoff; a trigger is not a Deliverable; connectivity alone is not verified progress.**
+
+### 5.1 Delivery Graph
+
+
+
+**Inference delivery is a convergence problem, not a checklist.** A Plan Task can divide the objective into Prefill, Decode, kernel, communication, and deployment workstreams. Research and Code Tasks then advance independently and in parallel, each producing evidence under its own Task Contract.
+
+**Integration is where parallel work becomes one runnable deployment point.** It assembles changes across the engine, libraries, image, and deployment configuration. The combined candidate then enters Evaluation under fixed model, Serving Scenario, hardware, performance, accuracy, and stability conditions. A failed result returns through `Rework` rather than advancing on partial success.
+
+**Release is a verified state transition, not the last box in a diagram.** Only a candidate that passes Evaluation can reach Release through a Follow-up Handoff. External `Signals` may trigger Online Diagnosis; its findings return through `Feedback` or start a Code Task through `Hotfix`. These Control edges can redirect work, but they cannot bypass Integration or Evaluation.
+
+**A Delivery Graph makes parallelism useful by forcing every path to converge through evidence.**
+
+### 5.2 Capability Graph
+
+
+
+**The Delivery Graph changes the inference system; the Capability Graph changes the system that performs the work.** Task Execution uses the current Skills & Tools baseline and records practical evidence in the Journal. Across Tasks, repeated steps, reusable commands, workflow patterns, and proven fixes become candidates for capability maintenance.
+
+**The Journal is evidence, not authority.** `Journal commit event`, `Scheduled trigger`, and `Model or runtime change` can wake a Capability Task, but none of them proves that executable behavior should change. The Task scans the Journal delta, reads the current baseline, and uses Verification to produce `Add`, `Update`, `Merge`, `Retire`, or `No Change`.
+
+**Every capability has a carrying cost and a shelf life.** Some Skills preserve durable project knowledge; others compensate for a particular model or runtime. As those systems improve, old scaffolding may consume Context, conflict with newer behavior, or constrain judgment. The Claude Code team reports removing more than 80% of its system prompt for newer models with no measurable loss on its coding evaluations[15](#ref-15). Boris Cherny has separately advocated periodically pruning `CLAUDE.md` files, Skills, and hooks[16](#ref-16).
+
+A `Model or runtime change` therefore triggers revalidation of the current baseline. Capability removal is an evidence-driven ablation method, not blanket deletion; safety boundaries and verified invariants remain unless evidence supports changing them. **A capability set that supports only `Add` does not evolve—it accumulates debt.**
+
+If a candidate requires implementation, Evaluation, or Release work, the Capability Task produces a Follow-up Handoff to the corresponding Task. **The Capability Graph prevents raw experience from mutating executable behavior while ensuring that verified experience does not remain trapped in the Journal.**
+
+## 6. One Engineer, Multiple Loops
+
+**This chapter follows one AI infrastructure engineer from sustained Task execution to concurrent work and project-scale coordination.**
+
+### 6.1 From Execution to Judgment
+
+
+
+**AI infrastructure engineering changes when execution can continue while the engineer is elsewhere.** Once an engineer has completed Task Definition and established the necessary Human Gates, an Agent can carry the work through environment setup, deployment, Evaluation, recovery, and iteration over hours or days. The Task Loop keeps that execution connected to the Task Contract, its evidence, and the next decision.
+
+Figure 13 shows the resulting working mode. While one Task Loop is still executing, the engineer can define another Task, review completed evidence, or return to unrelated engineering work. The engineer no longer has to advance every command sequence personally; scarce attention shifts from execution to judgment: setting constraints, evaluating evidence, resolving tradeoffs, and deciding what should proceed next.
+
+**One engineer can therefore direct multiple sustained Task Loops without blurring the boundary of each Task.** The Harness carries execution forward; the engineer concentrates attention where it changes the project's direction.
+
+### 6.2 Measured Operating Capacity
+
+
+
+**Figure 14 shows how the engineer's Tasks in flight changed over four months.** Each bar runs from Task creation to archive. The chart describes work-in-progress capacity, not instantaneous Agent utilization, GPU utilization, or per-Task execution speed.
+
+Across the April–July record, the median time a Task remained in flight increased from approximately **10 hours in April**, to **14 hours in May**, **20 hours in June**, and **28 hours in July**. The peak number of **Tasks in flight** rose from **2** in April and **2** in May to **6** in June and **9** in July. **Observed peak engineering concurrency therefore increased by 4.5×**, from two Tasks in April to nine in July.
+
+More Tasks in flight are useful only when each remains bounded and verifiable. These figures come from one engineer's Task records over four months. They are a longitudinal observation of operating capacity, not an estimate of infer-forge's causal effect on productivity.
+
+**In day-to-day operation, the binding constraint increasingly shifted from the engineer's next instruction to available GPU capacity.** Token budget was the next practical ceiling. Sustained Task Loops did not eliminate resource limits; they made it possible for one engineer to keep more resource-ready work moving until those limits became visible.
+
+### 6.3 Project-Scale Coordination
+
+
+
+
+ Figure 15: A Task Graph Coordinates a Project-Scale Serving Delivery.
+
+
+**One engineer coordinated *Pushing the Limits of Serving DeepSeek-V4-Pro* through 38 independently verifiable Task nodes across seven Task Types.** The graph organized four serving workstreams—short-context Prefill, long-context Prefill, low-latency Decode, and high-throughput Decode—so they could progress independently while sharing the decisions, constraints, and Verification evidence required for one Release. The four workstreams converged on four different deployment points rather than one universal optimum.
+
+One Decode Task remained open for **nine days** while other workstreams continued elsewhere in the graph. The graph prevented this long-running Task from blocking the project. No single Agent or Task had to retain the whole project context: each workstream could converge against its own Task Contract, then contribute a verified Deliverable to the larger Release.
+
+**The project produced four released serving profiles and preserved seven paths that did not enter the final Release.** Those paths were part of the engineering result: they recorded what had been evaluated, why it did not advance, and what downstream Tasks should not need to rediscover.
+
+**This is how the operating model scales: one engineer can direct multiple sustained Task Loops, converge them through a Task Graph, and preserve both the released system and the decisions behind it.**
+
+## 7. Layers Accumulate
+
+
+
+
+ Figure 16: Layers Accumulate: From Context to Task Graph.
+
+
+**Harness turns execution-local Context into durable structure for work that must continue.** Context holds the goal, code, current state, and working judgments needed for one execution. A Harness selects what deserves to outlive that execution, externalizes it for reuse, and supplies stable tools, environments, memory, verification entry points, and safety boundaries[9](#ref-9). Figure 16 is an accumulation, not a succession: Context becomes the execution core of the Harness; the Harness remains the load-bearing foundation of each Task Loop; and Task Graphs connect those Task Loops into project-scale work. Every higher layer extends the reach of the layers below without removing their capabilities or constraints.
+
+**Abstractions can change in months; reliability is earned layer by layer.** The representative essays cited here helped crystallize Harness Engineering, Loop Engineering, and Graph Engineering as a shared vocabulary in just over five months[2](#ref-2),[4](#ref-4),[13](#ref-13), but their dependency is fundamental rather than chronological. Incomplete Context can compromise one execution. A weakness in the Harness—stale knowledge, a faulty tool, or a missing constraint—can recur throughout a Task Loop and propagate across a Task Graph. Higher layers amplify both the strengths and the weaknesses beneath them. **Loop and Graph Engineering do not supersede Harness Engineering; they increase how much depends on it.**
+
+## 8. Lessons Learned
+
+### 8.1 Task Granularity
+
+**A Task boundary should be drawn where Verification can stand on its own.** A Task needs its own Task Contract—Goal, Scope, Acceptance, and Verification—and its own Exit Criteria. Work that changes only the Sub-target or Exit Condition while the Task Contract remains intact belongs in another Loop Block. Work that requires a materially different Goal, Scope, or Acceptance belongs in a new Task. A Task that is too large hides independent evidence; one that is too small turns execution into coordination overhead.
+
+The lesson from the nine-day Decode Task was not that nine days is inherently too long. Experiments governed by the same performance, accuracy, and stability contract belonged in successive Loop Blocks; directions requiring an independent Goal, Scope, or Acceptance should have become separate Tasks. A practical test is to ask where execution should return after failure: the next Loop Block, or a new Task Definition?
+
+**Split on a change in the contract, not the passage of time.**
+
+### 8.2 Evidence-Driven Task Graphs
+
+**A Task Graph should absorb evidence, not freeze assumptions.** A Plan Task defines the most credible initial decomposition, but the graph must be able to evolve as evidence changes[13](#ref-13). Research may invalidate a path, Evaluation may produce `Rework` or a new Code Task, and Feedback from Online Diagnosis may change the Scope of what follows. In response to verified evidence, the graph may add, remove, or reorder Task nodes.
+
+A downstream Task may be planned earlier, but it must not import an upstream result until that result has passed Verification and crossed a Handoff edge. In the DeepSeek-V4-Pro graph, the rejected directions, `Rework` paths, and cross-workstream constraint did not exist in the initial plan; they entered the graph only after execution produced evidence.
+
+**A graph that cannot change after planning records intention, not engineering.**
+
+### 8.3 Evidence Integrity
+
+**Evidence is only as trustworthy as the Harness that produces it.** In one benchmark Task, `bench_serving.py` ignored `delta.reasoning_content`, invalidating the apparent TTFT and throughput baseline. The Journal prevented the next Task from treating that measurement error as an engine regression, but the broader lesson is that evaluation tools, configurations, and data paths are part of the result. They require the same versioning, review, and Verification as the code under test.
+
+**A Deliverable must preserve a reproduction path, not just a conclusion.** For inference work, it should contain enough information to recreate the deployment point and compare the baseline with the candidate: exact code and runtime versions, image, deployment and workload configurations, commands, results, and failed attempts. A Follow-up Handoff states what is complete, where the evidence lives, which judgments still hold, and where the next Task should begin. Once that package is verified and imported, it becomes Imported Context.
+
+**If the next Task must reconstruct the environment or trust an assertion, the work has not been delivered.**
+
+## 9. Conclusion
+
+**Infer-forge does not reduce the complexity of inference engineering; it makes work across that complexity inspectable, resumable, and verifiable.** It keeps each change tied to its deployment point, code provenance, and evidence across repositories, execution rounds, and Follow-up Handoffs, so verified Deliverables and documented rejections can be reproduced, revisited, and carried forward.
+
+**Infer-forge supports an operating model in which one AI infrastructure engineer can direct multiple sustained Task Loops.** Our four-month record shows higher observed concurrency; whether this translates into productivity gains remains to be established through controlled measurement. We are exploring increasingly autonomous Task Graph coordination while preserving Verification boundaries, Human Gates, and engineering judgment. We hope the practices embodied in infer-forge help teams and individuals apply Harness, Loop, and Graph Engineering to large-scale, complex systems.
+
+## Acknowledgments
+
+We thank the SGLang Team and the broader SGLang community for developing and openly sharing the Skills that support agent-assisted SGLang development[8](#ref-8). We are also grateful to **Peng Zhang** of the SGLang community. We especially thank **Xiaoyu Zhang (BBuf)** for creating and sharing the `AI-Infra-Auto-Driven-SKILLS` collection[17](#ref-17).
+
+We also thank the researchers and engineering teams cited in this article. Their work on Harness Engineering, Loop Engineering, and Graph Engineering helped shape the concepts and methods behind infer-forge.
+
+## References
+
+1. Vivek Trivedy — [The Anatomy of an Agent Harness](https://www.langchain.com/blog/the-anatomy-of-an-agent-harness), LangChain, March 10, 2026.
+2. Ryan Lopopolo — [Harness engineering: leveraging Codex in an agent-first world](https://openai.com/index/harness-engineering/), OpenAI, February 11, 2026.
+3. Birgitta Böckeler — [Harness engineering for coding agent users](https://martinfowler.com/articles/harness-engineering.html), Martin Fowler, April 2, 2026.
+4. Addy Osmani — [Loop Engineering](https://addyosmani.com/blog/loop-engineering/), June 7, 2026.
+5. Sydney Runkle — [The Art of Loop Engineering](https://www.langchain.com/blog/the-art-of-loop-engineering), LangChain, June 16, 2026.
+6. Prithvi Rajasekaran — [Harness design for long-running application development](https://www.anthropic.com/engineering/harness-design-long-running-apps), Anthropic, March 24, 2026.
+7. Erik Schluntz and Barry Zhang — [Building Effective AI Agents](https://www.anthropic.com/engineering/building-effective-agents), Anthropic, December 19, 2024.
+8. SGLang Team — [Agent-Assisted SGLang Development: An Initial Exploration](https://www.lmsys.org/blog/2026-07-02-agent-assisted-sglang-development), LMSYS Org, July 2, 2026.
+9. Lilian Weng — [Harness Engineering for Self-Improvement](https://lilianweng.github.io/posts/2026-07-04-harness/), Lil'Log, July 4, 2026.
+10. Boye Niu et al. — [Flow: Modularized Agentic Workflow Automation](https://arxiv.org/abs/2501.07834), arXiv:2501.07834, 2025.
+11. Andy Xu and Yu-Wing Tai — [Meta-Agent: From Task Descriptions to Verified Multi-Agent Systems](https://arxiv.org/abs/2605.25233), arXiv:2605.25233, 2026.
+12. Ao Li et al. — [GraphFlow: A Graph-Based Workflow Management for Efficient LLM-Agent Serving](https://arxiv.org/abs/2605.22566), arXiv:2605.22566, 2026.
+13. Sydney Runkle and Harrison Chase — [3 Years of Graph Engineering with LangGraph](https://www.langchain.com/blog/3-years-of-graph-engineering-with-langgraph), LangChain, July 22, 2026.
+14. Nelson F. Liu et al. — [Lost in the Middle: How Language Models Use Long Contexts](https://arxiv.org/abs/2307.03172), TACL 2023 / arXiv:2307.03172.
+15. Thariq Shihipar — [The New Rules of Context Engineering for Claude 5 Generation Models](https://claude.com/blog/the-new-rules-of-context-engineering-for-claude-5-generation-models), Claude, July 24, 2026.
+16. Boris Cherny and Diana Hu — [Boris Cherny: Building Claude Code](https://www.ycrootaccess.com/p/boris-cherny-building-claude-code), Y Combinator Startup School, July 27, 2026.
+17. Xiaoyu Zhang (BBuf) — [AI-Infra-Auto-Driven-SKILLS](https://github.com/BBuf/AI-Infra-Auto-Driven-SKILLS), GitHub.
diff --git a/public/images/blog/infer-forge-loop/cover.png b/public/images/blog/infer-forge-loop/cover.png
new file mode 100644
index 000000000..1fdad9fb1
Binary files /dev/null and b/public/images/blog/infer-forge-loop/cover.png differ
diff --git a/public/images/blog/infer-forge-loop/fig-01-inference-deployment-space.svg b/public/images/blog/infer-forge-loop/fig-01-inference-deployment-space.svg
new file mode 100644
index 000000000..aa6ae5200
--- /dev/null
+++ b/public/images/blog/infer-forge-loop/fig-01-inference-deployment-space.svg
@@ -0,0 +1,4 @@
+
\ No newline at end of file
diff --git a/public/images/blog/infer-forge-loop/fig-02-monorepo.svg b/public/images/blog/infer-forge-loop/fig-02-monorepo.svg
new file mode 100644
index 000000000..a4a62d1fe
--- /dev/null
+++ b/public/images/blog/infer-forge-loop/fig-02-monorepo.svg
@@ -0,0 +1,3 @@
+
\ No newline at end of file
diff --git a/public/images/blog/infer-forge-loop/fig-03-task-loop-overview.svg b/public/images/blog/infer-forge-loop/fig-03-task-loop-overview.svg
new file mode 100644
index 000000000..35fa0f20b
--- /dev/null
+++ b/public/images/blog/infer-forge-loop/fig-03-task-loop-overview.svg
@@ -0,0 +1,3 @@
+
\ No newline at end of file
diff --git a/public/images/blog/infer-forge-loop/fig-04-task-definition.svg b/public/images/blog/infer-forge-loop/fig-04-task-definition.svg
new file mode 100644
index 000000000..561d59c9e
--- /dev/null
+++ b/public/images/blog/infer-forge-loop/fig-04-task-definition.svg
@@ -0,0 +1,3 @@
+
\ No newline at end of file
diff --git a/public/images/blog/infer-forge-loop/fig-05-loop-execution.svg b/public/images/blog/infer-forge-loop/fig-05-loop-execution.svg
new file mode 100644
index 000000000..67c776c43
--- /dev/null
+++ b/public/images/blog/infer-forge-loop/fig-05-loop-execution.svg
@@ -0,0 +1,4 @@
+
\ No newline at end of file
diff --git a/public/images/blog/infer-forge-loop/fig-06-node-registry.svg b/public/images/blog/infer-forge-loop/fig-06-node-registry.svg
new file mode 100644
index 000000000..0da28b341
--- /dev/null
+++ b/public/images/blog/infer-forge-loop/fig-06-node-registry.svg
@@ -0,0 +1,3 @@
+
\ No newline at end of file
diff --git a/public/images/blog/infer-forge-loop/fig-07-skills-and-tools.svg b/public/images/blog/infer-forge-loop/fig-07-skills-and-tools.svg
new file mode 100644
index 000000000..72011785f
--- /dev/null
+++ b/public/images/blog/infer-forge-loop/fig-07-skills-and-tools.svg
@@ -0,0 +1,3 @@
+
\ No newline at end of file
diff --git a/public/images/blog/infer-forge-loop/fig-08-journal.svg b/public/images/blog/infer-forge-loop/fig-08-journal.svg
new file mode 100644
index 000000000..daf9632dc
--- /dev/null
+++ b/public/images/blog/infer-forge-loop/fig-08-journal.svg
@@ -0,0 +1,3 @@
+
\ No newline at end of file
diff --git a/public/images/blog/infer-forge-loop/fig-09-safety-guard.svg b/public/images/blog/infer-forge-loop/fig-09-safety-guard.svg
new file mode 100644
index 000000000..c8e55583f
--- /dev/null
+++ b/public/images/blog/infer-forge-loop/fig-09-safety-guard.svg
@@ -0,0 +1,3 @@
+
\ No newline at end of file
diff --git a/public/images/blog/infer-forge-loop/fig-10-task-graph.svg b/public/images/blog/infer-forge-loop/fig-10-task-graph.svg
new file mode 100644
index 000000000..1139e76f1
--- /dev/null
+++ b/public/images/blog/infer-forge-loop/fig-10-task-graph.svg
@@ -0,0 +1,3 @@
+
\ No newline at end of file
diff --git a/public/images/blog/infer-forge-loop/fig-11-delivery-graph.svg b/public/images/blog/infer-forge-loop/fig-11-delivery-graph.svg
new file mode 100644
index 000000000..72423269c
--- /dev/null
+++ b/public/images/blog/infer-forge-loop/fig-11-delivery-graph.svg
@@ -0,0 +1,3 @@
+
\ No newline at end of file
diff --git a/public/images/blog/infer-forge-loop/fig-12-capability-graph.svg b/public/images/blog/infer-forge-loop/fig-12-capability-graph.svg
new file mode 100644
index 000000000..346782741
--- /dev/null
+++ b/public/images/blog/infer-forge-loop/fig-12-capability-graph.svg
@@ -0,0 +1,3 @@
+
\ No newline at end of file
diff --git a/public/images/blog/infer-forge-loop/fig-13-parallel-task-loops.svg b/public/images/blog/infer-forge-loop/fig-13-parallel-task-loops.svg
new file mode 100644
index 000000000..55b06536a
--- /dev/null
+++ b/public/images/blog/infer-forge-loop/fig-13-parallel-task-loops.svg
@@ -0,0 +1,3 @@
+
\ No newline at end of file
diff --git a/public/images/blog/infer-forge-loop/fig-14-task-activity.svg b/public/images/blog/infer-forge-loop/fig-14-task-activity.svg
new file mode 100644
index 000000000..e4f7ba90b
--- /dev/null
+++ b/public/images/blog/infer-forge-loop/fig-14-task-activity.svg
@@ -0,0 +1,3 @@
+
\ No newline at end of file
diff --git a/public/images/blog/infer-forge-loop/fig-15-deepseek-v4-pro-task-graph.svg b/public/images/blog/infer-forge-loop/fig-15-deepseek-v4-pro-task-graph.svg
new file mode 100644
index 000000000..9528d9898
--- /dev/null
+++ b/public/images/blog/infer-forge-loop/fig-15-deepseek-v4-pro-task-graph.svg
@@ -0,0 +1,3 @@
+
\ No newline at end of file
diff --git a/public/images/blog/infer-forge-loop/fig-16-layers-accumulate.svg b/public/images/blog/infer-forge-loop/fig-16-layers-accumulate.svg
new file mode 100644
index 000000000..2c9947eed
--- /dev/null
+++ b/public/images/blog/infer-forge-loop/fig-16-layers-accumulate.svg
@@ -0,0 +1,3 @@
+
\ No newline at end of file
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+