Parts one and two defined agents, tools, and multi-agent workflows. This installment defines the four big features harnesses bring to the table: model selection, context management, loop control, and safety.
For pipeline work, OpenCodee is a practical default harness. The same patterns apply to most harnesses, including Pi , Codex, and Claude Code.
What Drives Harness Performance?
Model
Model selection is a cost/latency tradeoff. Depending on your task, you may see major differences in how various models perform. If you need top of the line performance, you probably want a large parameter model that has been trained to operate within a harness with a very large context window.
You can think of model selection like a choice of compute; it’s not entirely the right framing, but there’s certain tasks that just aren’t plausible if your compute isn’t up to par, and other tasks may be accomplished faster. Professionally, you are likely to be constrained by company policy and inference costs when selecting a model.
Warning
Verify approved models with your security/production engineering team before running. Any file the harness reads in an unapproved cloud model is data leaving the studio with no NDA coverage
Scope determines how small of a model you can get away with. Most models get optimized for coding tasks to some degree, so it can help to frame tasks with that mindset. Smaller models may be able to handle short python scripts, which can address a large range of TD tasks beyond normal development. Be aware that smaller models will be more likely to make mistakes, and may know less about standard APIs in our industry like OpenUSD.
When working on a big software project, such as a C++ application, context length matters a lot more. This is where a SOTA model will shine.
In some cases, such as when you don’t have the absolute top of the line LLMs available and you’re working in a well-established codebase, you may want something integrated into an IDE (such as Cline) instead of a separate application like Codex/Claude Code/OpenCode/etc.
Context Management
If you’re working on big, complex tasks, even SOTA models may struggle to fit everything into their finite contexts. This is where your harness comes in. A good harness’s main task is managing context. Typically, we see three major ways that harnesses accomplish this.
Sub-Agents
In part 1 and part 2 I argued that agents are key to context management when solving big problems. Sub-agents are a great way to help manage context, by focusing the context to granular subtasks that make up a larger problem. They also can allow you to solve problems faster.
Most software that supports sub-agents supports running them in parallel. Combined with the right infrastructure to help prevent conflicts, this allows you to solve your tasks faster. At a studio, sub-agents could divide and conquer high-volume asset or scene processing.
Think of it like how Deadline or PDG TOPs work, where a single job can spawn many tasks. For example, if you are updating 50 .usda asset files, a coordinator agent can spin up 10 sub-agents to process files concurrently in separate context spaces rather than sequentially filling a single context. You get parallelism and context isolation, with each subagent only holding the logs and errors relevant to its particular file. There is risk, however; if your top level guidance is wrong, you’ll be executing the same problems at scale and possibly less visibility.
Warning
You scale up the amount of tokens you’re using as you increase the number of subagents, so there are cost risks as well
I’ve talked a lot about context management being critical to preventing context rot and degraded model performance. To put the advantage of subagents in more practical terms, consider the task of debugging a proprietary C++ plugin. Deep debugging of a C++ Crate/Maya plugin generates hundreds of lines of compiler errors. Running a dedicated sub-agent to isolate that debug cycle keeps the noise out of the master coordinator’s context. Once fixed, the sub-agent returns only a clean summary like “Successfully patched and verified build with clang” and not hundreds of lines of logs.
You don’t need a top-tier model for everything. You can use an expensive SOTA model can act as the main architect, while cheaper models handle sub-tasks like generating docstrings, parsing standard USD syntax, or writing basic pytest suites.
Sub-agents can be instantiated with specialized focuses, such as a specific set of instructions or domain tools. You can have an OpenUSD Agent with access to USD tools, a Houdini Hython Agent, and a Render Log Analysis Agent working under a single orchestrator. This will likely lead to better performance than a single context attempting to do all three things at once.
Compaction
Even with a SOTA model, long agentic sessions will eventually hit context limits, or suffer performance degradation (context rot) as the history grows. Compaction is a common operation you’ll see harnesses using, referring to a method of cutting down the current working context without overly harming ongoing performance.
The two most common techniques used are automatic summarization and text trimming. With automatic summarization, summaries are generated by the harness in a variety of different ways, primarily relying on LLMs. What gets included in the summary can make a very big difference in terms of ongoing performance, so this is one area where you might see quite the difference between harnesses. Typically, a harness will get the ongoing task, key discoveries and decisions, and a summary of current progress down.
Text trimming is the other, and it works a lot like how internal reporting tools typically trim full logs for the viewer. During normal operations, agents with access to tools like bash will end up with a lot of data in their context that is immediately important for the purpose of accomplishing things along the way, but isn’t that relevant to the bigger problem. For example, running a render may produce a lot of data that helps a model understand why a frame is black, but if that isn’t the core task, it’s not that helpful in the long run once the frame is rendering correctly. Trimming text from tool calls, logs, and so on is the other classic technique employed during compaction.
Tool Wrappers
Most models are really comfortable using the command line to do a wide variety of tasks. If your clis have good help descriptors, they can even usually figure out how to use proprietary tools without too much difficulty. This means that most harnesses can be at least somewhat helpful in a studio pipeline out of the box, especially when combined with some sort of web access to internal documentation.
Bare CLIs work if help text is good, but every fresh context pays the discovery cost. Why spend tokens on how to execute hython in the right rez environment, or describe a ton of settings to send to moonray, when you can just make it available as a single toolcall that handles the setup out of the box? It’s a smart idea to author new tools for a harness as you go, noting any that frequently require extensive tokens for models to execute correctly and wrapping them up as tool calls.
There are other good reasons to wrap tools as well. Holding logs in reserve unless the model requests them, formatting the output, having very long timeouts for VFX processes, and synthesizing errors with studio knowledge can all be good reasons to do so. Most importantly, a lot of tools used at a studio are going to be tools an LLM is less familiar with, meaning that it will lack what a TD would consider common sense when interacting with it. When these pain points are found, wrapping a tool makes a lot of sense.
Agent Loops
ReAct (Reason → Act → Observe) is the execution loop that just about everyone uses with agentic systems. Pretty much every coding harness is one of these. Expanding on them, goal loops (/goal in Codex, GASTOWN, Ralph Loopp, etc.) boil down to while not done: act(). This can be surprisingly powerful, but there are common issues with misunderstanding the initial user prompt, insufficiently precise input prompts, not solicity user feedback enough, and Reward Hacking that it’s important to have close observation and monitoring of the loop.
Info
Another concern is the token spend - you can easily burn through a lot of tokens using
/goal
Safety
In my opinion, no major harness sandboxes sufficiently for production filesystem access today. System-prompt guards and LLM judges are necessary but insufficient. For studio use, require explicit approvals, mount the show filesystem read-only by default, and run harnesses in a microVM/container (Docker/Apptainer) with network egress controls. Point to your internal sandbox standard.
Conclusion
Now you’re pretty familiar with the core ideas of what makes up a harness. In our next installment, we’ll put that to practice by first demonstrating using a coding harness to solve a common TD complaint, and then write a small custom harness to help us debug.