Harness Agents
A harness agent is an AI teammate that works the way an engineer or analyst does. It gets its own computer for each thread, with a shell, files and a memory of what it already did.
Behind the @mention runs Claude Code (Anthropic) or Codex (OpenAI), the same agentic tools developers use in their terminals. They run in a private sandbox on a runner, and XPT Tracker connects them to your conversation.
You talk to it like any other agent, in any thread:
@analyst take the three CSVs attached above, merge them by ticker and chart revenue growth for the top 10
It does more than answer. It can:
- write and run a script;
- install a library it needs;
- download a public dataset;
- fix its own errors and try again;
- come back with the answer, with the chart attached as a file.
Why it is different
A server-side agent thinks in a conversation with the model: it reads the thread, calls XPT tools, and replies. With OpenAI and Anthropic models it can also run code in the provider's own sandbox, within that sandbox's limits. A harness agent has a place of its own to work:
| It has | What that gives you |
|---|---|
| A shell and a real file system | It runs Python, Node, curl, git, jq — whatever the job needs. Data analysis, file conversion, scraping a public page, running a test suite. |
| Its own working directory per thread | Files it creates stay there between replies. Ask a follow-up an hour later and the intermediate results are still on disk. |
| A session that continues | It remembers what it did, what it tried and what failed, so the next message builds on the last instead of starting over. |
| Your files, in and out | Files attached to the messages it answers are handed to it. Files it produces come back attached to its reply. |
| XPT tools | Like every agent, it reads and changes tasks, projects, files and knowledge — with the permissions of the person who mentioned it. |
What its computer has
The sandbox comes with the tools an analyst reaches for, already installed:
| For | Installed |
|---|---|
| Tables and data | pandas, numpy, pyarrow (Parquet), duckdb (SQL over CSV and Parquet files) |
| Statistics and models | scipy, statsmodels, scikit-learn |
| Charts | matplotlib, seaborn |
| Excel | openpyxl, xlsxwriter, xlrd (old .xls files) |
| pypdf and pdfplumber (text and tables), pypdfium2 (a page as an image), reportlab (writing a PDF) | |
| Word and PowerPoint | python-docx, python-pptx |
| The web | requests, lxml, BeautifulSoup |
| Mathematics | sympy |
| Command line | Python, Node, git, curl, jq, ripgrep, sqlite3, 7zip, zip |
Anything else the agent installs itself, into its working directory, where it stays for the thread.
Limits. Each reply runs within limits set by the runner's administrator: memory, CPU, disk, and how long it may stay silent. The agent is told them at the start of every reply and plans its work to fit, for example by processing a large file in pieces. If a reply still runs out of memory, it is stopped. Its files and session are kept, so you can ask the agent to continue.
On XPT's own runner the limits are:
| Kind of work | CPUs | Memory | Scratch disk | Stopped after silence of |
|---|---|---|---|---|
| A reply in a discussion or brainstorm | 2 | 4 GB | 16 GB | 15 min |
| A task | 4 | 8 GB | 16 GB | 30 min |
| A scheduled job | 2 | 4 GB | 16 GB | 30 min |
A runner you host yourself has its own limits.
How a reply works
- You mention the agent. The thread shows Queued until a runner picks it up, then Thinking with a timer.
- The runner wakes the thread's sandbox. A thread that spoke recently gets its sandbox back in a fraction of a second, still holding the agent's session (see Warm replies). Otherwise a fresh container starts over the same working directory.
- The agent works. It reads the new messages, uses its shell and tools as many times as it needs, and writes files.
- It answers in the thread. Files it put in its output folder are attached. Next to the answer you see how long it took, and an (i) with the tokens the turn used.
Why it remembers
A harness agent keeps three kinds of state between your messages:
| State | Where it lives | How long |
|---|---|---|
| Working directory — downloaded data, scripts, results | On the runner, one folder per agent and thread. A copy goes to storage, so the thread can move to another runner. | 30 days after the thread was last used |
| Session — the agent's own record of the conversation and its actions | In the working directory | Until you start afresh (/new, /clear) |
| Warm sandbox — the running agent itself, frozen between replies | On the runner | 20 minutes by default after each reply |
Warm replies
After a reply the runner does not throw the sandbox away. It freezes it, with the agent still inside, and keeps it for a while (20 minutes by default). When the thread speaks again, the sandbox is thawed and the agent continues on the spot.
- A frozen sandbox uses no CPU and holds no slot.
- Measured on our runners, follow-up replies start about a second sooner: a short Claude Code reply took 2.7 s instead of 4 s.
- It happens automatically; there is nothing to switch on.
Which kind of agent to use
XPT Tracker has three ways to bring AI into your work. They complement each other.
| Server-side agent | Harness agent | Local agent (MCP) | |
|---|---|---|---|
| What it is | A model with XPT tools, run by XPT | Claude Code or Codex in a sandbox on a runner | Your own Claude Code, ChatGPT, Codex… connected to the workspace |
| You reach it by | @mention in any thread |
@mention in any thread |
Your editor, terminal or chat app |
| Has a computer | With OpenAI and Anthropic models: the provider's own sandbox for running code, with its limits. Other providers: no | Yes: its own sandbox with a shell, files and internet, set up for the work | Yours |
| Remembers between replies | The thread only | Thread, files and its own session | Whatever your client keeps |
| Speed | Seconds | A few seconds for a short reply; minutes for real work | Depends on you |
| Providers | Anthropic, OpenAI, Gemini, DeepSeek, Kimi | Anthropic (Claude Code), OpenAI (Codex) | Any MCP client |
| Best for | Quick answers, summaries, turning a discussion into tasks, questions to the knowledge base | Data work, files, scripts, research that needs a browser and a calculator, long multi-step tasks | Hands-on work from your own machine, on your own code |
When a harness agent is the right choice
| You need to… | Why a harness agent |
|---|---|
| Analyse several spreadsheets, CSVs or PDFs | It opens them as files, writes the code to join and check them, and returns a clean result file instead of guessing from pasted text. |
| Do real calculations | It runs them in Python rather than estimating — totals, statistics, models, charts. |
| Collect data from public websites or APIs | It can curl a page, page through an API, and keep what it collected for the next question. |
| Produce a file — a report, a chart, a converted document | Whatever it writes to its output folder comes back attached to its reply. |
| Work in several steps over a day | Its working directory and session persist, so "now add last quarter" builds on what is already there. |
| Run or check code | It can clone a public repository, run tests and explain what failed. |
For a one-paragraph answer, a summary of the thread or a set of tasks drafted from a discussion, a server-side agent is faster and cheaper.
Creating a harness agent
In Settings → Agents → New Agent:
- Pick Anthropic or OpenAI as the provider.
- Tick Use harness mode. The harness follows from the provider: Anthropic runs Claude Code, OpenAI runs Codex. The choice is fixed once the agent is created.
- Paste the provider API key. It is write-only and encrypted at rest; the harness authenticates with it.
After that the agent is edited like any other: name, avatar, model, system prompt, Available as workspace assistant. Its settings show a Harness mode block saying where its turns run.
Harness agents need a runner that serves your workspace: XPT's own, or one you host yourself. If none does, the form says so and asks you to contact support@xpt.ai.
In threads, its answers carry an orange Harness label.
Files
Giving it files. Attach files to your message as usual. When the agent answers, the files attached to the messages it is replying to are placed in its input folder, with a manifest that says which message each came from.
Getting files back. Ask for a file — "save the chart as PNG", "give me the cleaned table as CSV". Whatever the agent writes to its output folder is attached to its reply.
| Limit | Value |
|---|---|
| One file | 50 MB |
| Files per reply | 20 |
| All files per reply | 250 MB |
Program folders (node_modules, .venv, .git, build output) and hidden files are never sent back.
The agent can also save files straight into the workspace — Files, a task or a project — with its XPT tools.
Commands
Send a command as a message on its own: the mention and the command, nothing else.
| Command | What it does |
|---|---|
@agent /context |
Says how full its session is — tokens used out of the model's context window. |
@agent /compact |
Claude Code only: compresses the session so a long conversation can go on. The reply says how much it shrank. |
@agent /clear |
Starts a new session that reads the thread afresh. Its working directory and files stay. |
@agent /new |
Starts completely afresh: a new session and an empty working directory. Files posted in the thread stay in the thread. |
The (i) next to every answer lists these commands too.
When the context fills up. A session cannot grow past the model's context window. Near the limit the agent compacts on its own: the conversation so far is replaced by a summary, and the thread shows a line such as @agent compacted its context: 235k → 20k tokens. The agent carries on with the task, its files and what was said in the thread. Fine detail it only read along the way, such as the exact contents of a file, may be gone, and it may answer from memory instead of checking. If the detail matters, ask it to read the source again.
What a reply cost
Every finished answer shows its duration. The (i) next to it shows:
- Out — what the agent wrote, its reasoning included. The most expensive tokens of a reply.
- In — the input not read from the provider's cache. Billed at the full input price.
- Cache — the input the provider read from its cache, in tokens and as a share of all input:
Cache 399k tokens (92%). Billed at a fraction of the price. An agent that runs ten commands sends the conversation ten times, and most of that is read from the cache. - Context — how much the model held when the reply ended, and its share of the model's context window:
Context 150k of 200k tokens (75%).
The tokens are billed by your provider on the key you gave the agent.
Safety
A harness agent has a shell, so it runs in a sandbox built for that:
- One container per agent and thread. It sees only its own working directory — never another thread's, another agent's or the runner's files.
- No privileges. It runs as an unprivileged user with every capability dropped, on a read-only system disk.
- A network fence. It reaches the internet and the model provider, but not the cloud metadata service, the runner's own machine or private networks.
- Optional gVisor. On runners that serve several organisations, each sandbox can run under gVisor, an extra kernel layer between the agent and the host.
- Your permissions, not more. Its XPT tools act as the person who mentioned it, under the same rules as in the app, and every change is recorded under that person.
- Limits per reply. Each reply has CPU, memory and disk limits, and stops if it stays silent too long.