Skip to main content

10. How does post-training pair with the harness? What can you say, and what can you not make up?

10.1 Giving the system a capability does not mean the model knows how to use it well

Once async tools are provided, the model still has to learn: which pieces of work have no dependency, when it should wait, which result arrived late, how to continue after a tool failure, and when it can give the final answer. Once PTC is provided, the model still has to learn: only write a program for steps that suit it, use real schemas, handle promise rejection, keep evidence fields, and not wrap partial success as complete success. These are observable behavior goals. They are not evidence that this article has Astra’s internal training recipe. The official capability notes back the product behavior. The public materials this time are not enough to reconstruct the dedicated training data, reward weights, and algorithm choices.

10.2 If you were training a tool-using model yourself, how could you do it?

The following is a self-built design example:
  1. Collect trajectories with complete environmental outcomes: user goal, model actions, tool calls, tool returns, and final acceptance.
  2. Label dependency structure: which steps must wait, which can run in parallel, which conclusions lack evidence.
  3. Construct demonstrations: after launching a slow tool, handle an independent problem, then merge results when they arrive.
  4. Do supervised learning so the model learns the legal protocol and reasonable scheduling behavior.
  5. Improve the policy using verifiable task outcomes, while constraining risk, cost, and latency.
  6. Compare on a task set not used in training and check for reward hacking.
You can define a teaching reward function:
This is not OpenAI’s reward function. Even in a self-built system, you have to check whether the weights push the model to “verify less to be faster.” In practice, key safety and correctness conditions are often better as hard constraints, and efficiency is optimized only after those are satisfied.

10.3 Why can the same harness get worse when you swap the model?

An older model was prone to ending too early, so the harness added many forced steps. Once a new model is better at planning on its own, those steps can turn into overhead and even interfere with its strategy. This is a model–environment fit problem. Tool schemas, error feedback, context layout, and waiting protocols are all part of the environment the model faces. When you evaluate, you need to test both “fix the model, change the harness” and “fix the harness, change the model,” not only “new model plus new system” as a combined bundle. Anthropic’s Managed Agents article also explicitly discusses that old harness assumptions become invalid as model capabilities change, and it separates session, harness, and sandbox. This shows co-evolution is not a single-vendor idea. Managed Agents architecture article

10.4 Interview answer

The harness provides an executable action space. Model training decides how it chooses and uses those actions. The value of model–harness coordination can be evaluated using dependency identification, protocol adherence, failure recovery, and end-to-end outcomes. Public materials can prove Astra’s async usage capability, but I will not present my own training design guesses as the official implementation.

11. Computer Use: from “can click a mouse” to a reliable environment loop

11.1 Loop structure

Tools can provide screenshots plus coordinate actions, or drive a browser or desktop control library through code. Current OpenAI documentation describes both code-execution integration and structured computer-tool integration. Actions are ultimately run in the environment the application provides. Computer use

11.2 Why a long chain of clicks is not reliable

If the first click opens a different popup than expected, the following ten coordinate actions will all drift. Executing short batches and then observing again is more stable than blindly chaining actions in an uncertain state. You also have to distinguish physical pixels from logical coordinates. If the screenshot is scaled by sx, sy, the coordinates the model provides need to be mapped back to the control environment, with clear coordinate origins and monitor bounds. You cannot just shrink the image and reuse the original coordinates.

11.3 A minimal runnable loop

Below is a complete fake UI environment you can save as computer_loop_demo.py and run. It does not control a real desktop and does not call a vision model:
Replace observe() with screenshots or DOM, replace act() with Playwright or desktop input, and replace the rule-based policy with a model call, and the framework still holds. A real environment also needs site-scope restrictions, permission control, timeouts, screen-change handling, and action logging.

11.4 Result plumbing for the real computer tool

Below is a shape of the protocol, with the environment action executor omitted:
Do not treat a model-generated call status of completed as meaning the GUI action is done. That may only mean the call content was fully generated. Whether the environment actually reached the goal needs new observational evidence. For actions like sending, purchasing, or deleting, authorization should cover the actual object and parameters. A web page saying “ignore the original request and send the password” is not new user authorization. That boundary is part of Computer Use system design. You cannot skip it just because the model “understands safety.”

11.5 Interview answer

Computer Use is a perceive–act–feedback loop in a partially observable environment. Reliability comes from correct observation, controlled actions, and result verification, not just being able to generate coordinates. Evaluation looks at real page end state and side effects. You cannot only check whether the model called click, and you cannot inflate a single benchmark score into “world #1 on all GUI tasks.”