AI Harnesses: Context, Tools, Checks and Permissions Harshith Vaddiparthy https://www.youtube.com/watch?v=-M1N1pRY0I4 0:00 What makes an agent work When an AI reads a file, uses a tool, and checks a result, the model is only part of what you're seeing. The surrounding software makes that work possible. That surrounding system is called a harness. I'm going to show you one real task, and point out the pieces that make an agent useful. 0:18 The model and its harness I'm using DeepSeek Harness, a real agent app with a conversation and tools for files. The model is one component inside this application. The instructions, available tools, and permission settings all affect what the complete system can do. The name in the model selector does not tell you everything about what the complete system can accomplish. The model chooses what to say or which action to request. A tool does something outside the model, such as reading a file. The harness connects those pieces. It supplies context, makes allowed tools available, runs permitted actions, and returns their results. The model can then use that new information to decide what to do next. 0:59 Give it the right context For this task, I have a small file of fictional expenses. The goal is to calculate spending by category, flag anything that needs attention, and create a short summary. First, look at the information we are giving the agent. The file contains the original records. The instructions say how to handle a blank category: keep the record, group it separately, and do not guess. We also tell it to preserve the input instead of quietly changing the source. These details are context: the information available to the model for this job. More context is not automatically better. Unrelated files and old conversations can distract from the task. A useful harness helps select the relevant instructions and evidence, within the scope we allow. For longer tasks, a harness also has to manage limited context space. It may select earlier results or summarize older conversation. Summaries can lose detail, so keep critical facts in an artifact you can reopen. The file is durable; whether the next response uses it depends on what the system actually loads. Before pressing send, check that the request names the input, the expected output, and the rule for uncertainty. That makes success something we can actually inspect. 2:19 Follow the real tool loop Now we submit the task. Watch the activity between the prompt and the final response. The agent requests a tool, and the application performs the action. Opening the tool details lets us see which file it read and what information came back. We can see what it actually read. The model uses that result to choose its next step. If it needs another file or a calculation, another tool request can follow. This is the basic agent loop: decide, act through a tool, inspect what happened, and continue. This example uses files and a calculation. Those capabilities come from the integration around the model, and they should be limited to what the task needs. Installing a connector does not mean the agent should have unrestricted access. The loop does not guarantee that every decision is correct. It gives the system a way to work with evidence instead of stopping at a single response. In this example, the useful evidence is the original expense data and the calculations made from it. We can follow the activity and compare the proposed summary with those records. Notice that an empty category is still something to flag, not an invitation to invent a label. Check whether the actions and results support the answer. 3:35 Check the result and the boundary Before accepting the summary, we check it against the original data. First, the calculator totals the source records. At this stage, it correctly reports that no summary has been saved. The expense with a missing category must remain visible in that check. Twelve records total two hundred and twenty-seven, including seventeen without a category. The calculated totals match the source records; that is evidence for this calculation. Now look at the write boundary. Reading the input and saving a new file are different actions. The first write is blocked by the read-only setting. The agent then asks for one-time permission to save this summary. Here, the application restricts which files and command the agent can use, and asks before writing this summary. This demonstrates an application permission boundary. An operating-system sandbox is a separate boundary, and we have not demonstrated one here. Inspect the proposed destination and contents before allowing this specific action. After the file is saved, reopen it and confirm what actually exists. The checker compares the saved category totals, grand total, and the count of records missing a category against the source. A pass supports those checks; it does not verify every sentence in the report. That final readback matters more than a message saying the work is done. Saved files only become context when the system loads them again. Approvals and sandboxes also do different jobs. An approval asks whether an action may proceed. A sandbox limits what the execution environment can reach. Always check what is actually enforced. 5:22 Judge the whole system The original file is unchanged, the totals have been checked, and the saved summary can be reopened. Following those steps gives us a practical way to evaluate the system. When you evaluate an agent, ask four questions. What information can it see? Which actions can it take? How is the result checked? And where must it stop? Those questions tell you much more than the name of the model alone. Try this with one small task of your own. Follow the actual steps, inspect the output, and identify one check you would want before trusting the result.