The Agent system first tightens the context budget and sensors

Looking at Martin Fowler’s article Fragments: July 13, the first word that pops up is not model score, but Harness Engineering. In the retreat, some people have already put the discussion into context and sensors. This matter is very much like an emerging engineering discipline: the agent must first tighten the input, and then talk about the action expansion.

The larger the context window, the shorter the constraints.

There is a very straightforward detail in the article: someone controlled agents.md to within 200 lines. This number looks like a mysophobia, but it is actually a budget for the project. The context window is indeed getting bigger and bigger, but the larger window only means that more content can be crammed into it, but it does not mean that the model will more firmly grasp the part that should be grasped. The model usually only focuses on a small part of the context, and even if the rest of the content is there, it may just be running along.

This is the most common problem with long documents. The more rules there are, the easier it is for the really important constraints to be obscured by noise; the longer the description, the easier it is to write the boundary as the background and the background as the boundary. Keeping files short is not to save time in writing, but to force constraints to become visible, readable, and executable. What the Agent faces is not a pile of materials, but a limited operating contract.

The sensor should be compressed into a small amount of usable signal

Another change is that the discussion has begun to move up to computational sensors. The sensors here are not simply burying points, nor are they feeding the logs to the model again, but compressing the runtime status into a small number of stable signals. Once the sensor becomes the original output playback, the input will expand again; the truly valuable approach is to first cut the scene into several clear states, and then decide which details should be given to people and which details should be given to tools.

The article mentioned that switching from Python to a more controllable language such as Rust only makes sense in this context. The focus is not on language preference, but on control. What the sensor needs is not “running”, but clear boundaries, clear exception semantics, and clear resource consumption. As long as the signal is unstable, no matter how strong the model is, it can only make judgments based on jitter input.

Harness closes the action chain first

Once this discussion gets this far, harness becomes less like a shell and more like a mouthpiece. It is responsible for deciding what goes into the context and what stays out; which states can be relied upon by the model and which states must be reconfirmed by tools. Context budget, sensor design, permission boundaries, and fallback paths will all finally come to this layer.

The most easily underestimated cost in the Agent system also falls on this level. Model replacement is fast, but harness is much slower because it is bound to an action chain, a signal chain, and a failure chain. As long as this layer is not tightened and the model capabilities move forward, the system will only amplify chaos faster.

Pure read requests, one-time analysis scripts, lightweight agents without external actions, and model capabilities are still the protagonist. As soon as you start to connect private data, long-term states and real actions, the first thing to harden is no longer the model parameters, but the input boundaries and signal boundaries. The moment when an Agent truly resembles a system is often when these two layers take hold first.