Is “Harness Engineering” Just Rebranded Engineering Common Sense?

First Pitfall: Stuffing All Documentation into a Single Agent

In the SGLang community, users constantly ask diverse questions—how to deploy DeepSeek‑V3 on eight GPUs, why a gateway cannot reach a worker, or the performance gap between GLM‑5 INT4 and the official FP8. The support team cannot keep up.

One seemingly straightforward idea is to create an omniscient Agent that contains all SGLang documentation, code, and cookbooks, and let it answer everything.

The result is obvious: irrelevant answers and endless chatter. The context window is not RAM; over‑filling it scatters attention. A single Agent trying to understand quantization, PD separation, diffusion serving, and hardware compatibility ends up mastering none of them deeply.

Final Solution: Expert Specialization + Structured Routing

The proposed solution is simple: split the documentation by function, assign each sub‑domain its own Expert Agent, and add a Manager that receives questions, decomposes them, activates the relevant experts in parallel, and aggregates the answers.

SGLang’s documentation already has natural functional boundaries—advanced features, platform details, supported models. Cookbooks are organized per model. Each expert only handles its own slice.

Key decisions include:

Progressive disclosure : No Agent loads the entire document set; each loads only its domain‑specific portion. The Manager decides which expert to call based on the question type. This design yields far greater benefit than simply swapping in a stronger model.

Repository as truth : All knowledge lives in the how-to-sglang repository as markdown files, avoiding reliance on external docs or oral conventions. An attempt to write a massive sglang-maintain.md covering everything quickly failed—once the docs became stale, the Agent was led astray. The OpenAI Codex team made the same mistake.

Structured routing : The mapping from question type to Agent is expressed as an explicit routing table. For a GLM‑5 INT4 query, both the Cookbook expert and the Quantization expert are activated. The Manager does not guess; it looks up the index.

Nothing New

In hindsight, this design aligns almost perfectly with what the “harness engineering” community advocates, yet the author was unaware of those buzzwords while implementing it. Knowing the terminology is unnecessary.

Information fed to an Agent must be concise → progressive disclosure<br/>System should be split into dedicated sub‑modules instead of a omniscient Agent → separation of concerns, single‑responsibility principle<br/>Knowledge must reside in a repository → docs‑as‑code<br/>Routing and constraints must be structured, not left for the Agent to guess → shift‑left constraints<br/>Feedback loops should be as tight as possible → full reasoning‑chain logs + LLM‑as‑judge verification

These correspond to classic software‑engineering concepts: separation of concerns, single‑responsibility principle, docs‑as‑code, and shift‑left constraints.

Now they are simply transplanted into LLM workflows, and some people feel a new name is warranted.

"Every few months someone invents a new term, writes a ten‑thousand‑word article, copies a few big‑company cases, and the whole community starts debating. But if you look closely, it’s always the same thing."

Model Power Isn't What Drives Real Improvements

Chayenne observes that on the how-to-sglang repo, they have never achieved a qualitative leap by swapping in a stronger model. Real breakthroughs come from environmental improvements—more precise knowledge partitioning, smarter routing logic, and tighter feedback loops.

Whether you call it harness engineering, context engineering, or something else, it is simply good engineering practice, not a new discipline.

She also raises an open question: if model capabilities continue to grow exponentially, will there ever be a point where a model can construct its own environment? OpenClaw grew from 400 k lines of code to 1 M lines in a month, driven entirely by AI. Who built that environment—humans or AI?

If AI takes over, will these design principles still matter in two years? The author does not know, but in all observable cases today, the most valuable work remains human‑driven.

Nevertheless, a catchy name can attract attention and research, as deep learning itself demonstrates. Naming can help unify understanding across eras, but it must be accompanied by rational scrutiny rather than blind hype, and we should not abandon first‑principles thinking.