The new agentic workflow for Torq

Unifying the Assistants

The initial release of Torq was split into two assistants. The help assistant was accessible by clicking the Torq icon in the toolbar whilst in edit/navigate mode. The coding assistant was accessible only from inside the script editor. Splitting the roles like this allowed us to provide the help assistant for free inside of the documentation. However, we subsequently found that this approach had a few disadvantages.

1. It was frustrating having to switch between different modes in order to access the relevant assistant.
2. We found that users were frequently asking the help assistant code-related questions.
3. The coding assistant didn’t have access to the documentation in cases where it would have been useful.
4. There were questions that required knowledge of both the documentation and scripting API.

The new unified assistant can query a help assistant subagent. This approach allows us to avoid polluting the context window with irrelevant content from the documentation. Keeping the context window short improves the quality of responses and reduces inference costs.

Agentic Workflow

Previously, Torq did not have access to the contents of the model or any scripts. You were required to copy/paste code back and forth. This limited the usefulness of the coding assistant, and denied it access to useful context that it could have used to provide better responses.

In the latest version, we’ve added agentic capabilities to Torq. This means that Torq can now operate in a loop. It can read any scripts, create new scripts and make changes to existing scripts. Additionally, it can run standalone scripts in order to collect information about the contents of the model or even make changes to the model.

You can control Torq’s permissions through the model settings. By default, Torq is allowed to read and modify both scripts and the contents of the model. However, before modifying the contents of the model by running a standalone script, you will be asked to approve the execution of the script.

These workflow improvements make working with Torq a much more fluid and seamless experience. It also significantly improves the quality of responses, by allowing Torq to collect relevant context that it previously didn’t have access to.

Attachments

You can now attach PDF documents and images to your prompt. If you take a screenshot, you can immediately paste the image into the prompt using CTRL+V. If the underlying LLM has vision capabilities, this can be used to provide additional context.

In one experiment, we provided Torq with the manual for the Sick DT35 laser distance sensor and asked it to create a component for this sensor with the correct IO. Torq was able to identify all the IO from the 60-page manual and implement the behavior of the sensor perfectly using a physics raycast. Additionally, from the images contained in the manual, it was able to construct a dimensionally accurate visual representation of the sensor in the scene, complete with matching graphics materials.

Why not MCP?

We spent months tightly integrating these new agentic capabilities. To do so, we had to create an entirely custom harness, with countless experimentation and system prompt finetuning. So why go to all this effort rather than just creating an MCP server?

What are MCP Servers?

Model Context Protocol (MCP) servers expose a set of tools that existing AI agents, such as Github Copilot or Claude Code, can execute. This is a very quick and simple way to integrate AI into an existing piece of software. However, as is often the case, quick-and-simple comes with some real disadvantages.

The System Prompt

The system prompt is the first and most important message that gets fed into the context window. When using 3rd party agents, you typically cannot change the system prompt. This is a major issue, since the provider of the AI agent has configured the system prompt specifically for the software into which it was embedded.

For example, the system prompt for Github Copilot in VSCode repeatedly talks about working with a user inside VSCode. It is tailored specifically to writing code inside of VSCode. It includes a bunch of tools that are specific to VSCode. Its rules and guidelines are specific to VSCode. You get the idea.

(Mis)using MCP to piggyback on 3rd party agents causes LLMs to become confused, since they are being asked to work with a completely different piece of software to what was described in the system prompt. This results in a severely degraded quality of response, and frequently failed tool calls.

Polluted Context Windows

Providing agents with lots of MCP tools causes the context window to balloon. Each tool inserts some associated information into the context window, including a description of the tool and an input schema to use when calling the tool. This can result in tens of thousands of tokens being added to the context window.

The performance of LLMs rapidly degrades as the length of the context window increases. After adding just a dozen or so MCP tools, there are usually already signs of degradation, particularly when calling tools. Some LLMs are more severely affected than others. We found that the Gemini 3 series of models quickly degrade as the context window increases above just a few tens of thousands of tokens.

In most MCP servers for working with digital twins, you’ll find a plethora of tools such as:

• get_entity_property(property_name)
• set_entity_property(property_name, property_value)
• get_component_property(entity_name, component_name, property_name)
• set_component_property(entity_name, component_name, property_name, property_value)

As detailed above, each tool carries baggage that increases the length of the context window. However, there is a much more severe problem. Suppose we task the agent with creating a stack of 10 boxes with physics. To succeed at this task, the agent may need to perform hundreds of tool calls, with each tool call being executed in a specific order. It must explicitly calculate the positions of the boxes so that they rest one on top of the other. What sounds like a quick and simple task, ends up being quite complicated, very slow and very expensive.

There is an article from Cloudflare that talks about this problem in detail. The solution is to replace most of these tools with a single tool that allows the agent to execute code. With a single tool, and a single invocation of this tool, the agent can write and execute the code that programmatically creates the stack of boxes.

Run Script Tool

ProtoTwin provides Torq with a run_script tool that allows the agent to execute a standalone script at design time. Using this single tool, it can:

1. Collect information about the contents of the model.
2. Create new entities and change their properties.
3. Add, modify and remove components.
4. List, create, modify and remove materials.
5. Connect signals together using direct IO connections.
6. Add programs and instructions to robot controller components.

This list is far from exhaustive, but you can see that this single tool is particularly powerful and solves the combinatorial tool growth otherwise required in order to provide this level of functionality. In the video above, the positions of the boxes can be calculated in the script, and we’ve reduced hundreds of tool calls down to just one.

What’s next for Torq

We feel like we’re still only just scratching the surface. We’re hoping to finish the integration of IEC 61131-3 Structured Text into the SoftPLC before releasing the next version. This will enable Torq to write and test machine control logic using portable structured text. We’ll feed back diagnostics, allowing Torq to automatically correct any compilation errors. It’s also possible to feed runtime errors and runtime logs back to the model, allowing Torq to automatically detect runtime issues.