Skip to content
Back

Put What the Model Cannot Yet Do into the Harness

4 min read

A model can already write code, read tables, and draw charts. Ask it why a production line behaved abnormally last night, and it may misalign two devices’ timelines, mistake scheduled maintenance for a fault, and produce an elegant report around those errors. It has many general capabilities, while this particular job still needs several things: how to interpret local data, how experienced people investigate it, and which operations produce reliable evidence.

The surrounding system can supply these missing pieces first. Provide device documentation, access to maintenance records, a tool for aligning time series, and effective diagnostic methods somewhere discoverable. The model still interprets the problem and organizes its actions. The harness brings the conditions specific to this job within reach. This kind of concrete support is often where a specialized agent begins.

Put the missing pieces within reach

The first form of support is knowledge: field units, device identifiers, timestamp time zones, and the times of last night’s shutdowns. Knowing how vibration works cannot reveal which field this factory labels “amplitude.” Such information needs a retrievable source that stays current as conditions change. Documentation and records let the model apply its general understanding to the actual objects in front of it.

The second is experience. An engineer may know to check calibration records before suspecting a machine fault when a sensor trace jumps after calibration. Experience connects clues with actions: what to inspect first after a particular observation, and what evidence rules out an explanation. Preserving the conditions and outcome makes an episode useful in a later investigation. Reducing it to “sudden jumps are usually fine” turns a useful judgment into misleading advice.

The third is tools. Knowing that two traces need alignment still leaves missing values, sampling intervals, and clock offsets to handle. The model can write a program on demand or call a validated processing function. The latter turns a recurring precise operation into a stable interface, avoiding repeated implementation and defining its inputs, outputs, and errors. A specialized agent can thereby draw on existing software capabilities without recreating them from text each time.

The fourth is workflow: establish whether the data is usable, locate the abnormal interval, compare explanations, and deliver conclusions with their evidence. A workflow preserves dependencies between pieces of work. A model may know how to perform every step yet omit one during a long task; the workflow can initially maintain those relationships for it. The system can check mandatory delivery conditions while leaving other steps as guidance the model adapts to the situation.

The example below lets you add these four forms of support individually. The model and task stay the same; what changes is the evidence and assistance available for doing the work. Notice the blind spot each addition addresses. Enabling all four supplies the conditions shown here; the eventual report still has to stand up to the data and business facts.

Same model, better working conditionsTask: explain last night's production-line anomaly. Add the support it can use.

Forms of support available: 0 / 4

Knowledge · Field definitions and maintenance records Missing

Units, time zones, and shutdown times have no confirmed source.

Experience · A previous calibration case Missing

No relevant past case suggests where to investigate first.

Tools · Validated alignment function Missing

Time alignment must be implemented and checked during this task.

Workflow · Evidence-based investigation guide Missing

The task has no supplied sequence or delivery checklist.

The rows show what each resource supplies. Enabling everything does not guarantee a correct report.

A folder can hold a method of working

Knowledge needs documentation, experience needs cases, tools can be scripts, and workflows can be written in natural language. They fit naturally in one folder. Its entry point explains when the material applies and where to begin; other files hold references, cases, and executable programs. Agent Skills uses this organization: expose a name and description first, read the instructions when relevant, and load further material as needed.

This separates two scales. A skill library can accumulate material from many domains while a task reads only the relevant parts. A script can process a large dataset while returning just the results the model needs. The model’s finite context is available for current decisions, while external files and programs handle storage and execution. The folder is a simple structure whose value lies in making working methods easy for a model to find, use, and edit.

Actual work then continues to reshape this support. A person’s reminder to inspect calibration records can become reusable experience. A tool discovering inconsistent device clocks can turn a failure into a check for the next task. Revised support helps the model complete the work and leaves trajectories containing observations, actions, and outcomes. Selected trajectories can then enter training, making the choice of what to inspect in a situation part of the model’s own behavior.

External support then takes on a different division of labor. A learned diagnostic habit needs fewer reminders; newly created maintenance records still need reading, and precise data-processing programs remain useful. Effort can move to the next gap without permanently retaining the original elaborate guidance. The harness helps the model do today’s work while organizing effective practices into material it can learn from tomorrow.