An agent in a sandbox that cannot reach your mail or your documents is a chat window with extra steps. We run the harness you want, wire it to the systems it needs, and keep the boundary and the audit trail in place while it works.
Two harnesses cover most of what a team needs day to day. Everything else is supported, but these are the ones we maintain ourselves.
Recommended — coding
Our opencode-based coding agent. We develop it, we maintain it, and we keep it matched to upstream — so you are not running a fork that drifts from the tool it was built on. It arrives configured with our MCP servers, memory, custom agents and tools.
We build it, we maintain it, and it tracks upstream.
Recommended — daily use
For daily usage and image creation. Model work, generation and fine-tuning on infrastructure we run, with the same MCP and memory wiring as the coding agent. This is what produced the marks on this site — the recipe is published in our content workflow runbook.
The tool we use for our own work is the tool we host for you.
Plug and play. You bring the harness you already use; we run it on the same isolation, memory and tool layer.
Coding harnesses
Run as supplied, configured against the same MCP servers and memory. Nothing is rewritten to fit our platform — the harness keeps its own behaviour, and the wiring is what we add.
Plug and play means the harness is not modified.
For personal agents that hold context between sessions. Memory, tools and the boundary are the same as the coding harnesses, so a personal agent is not a second system with different rules.
One isolation and memory layer, whatever harness sits on it.
The wiring
Every harness is configured against our MCP servers and memory store, with custom agents and tools defined per engagement. The protocol seam is where the harness ends and the platform begins, which is what makes a harness swappable without re-doing the wiring.
The wiring is shared; the harness is interchangeable.
An agent is only useful if it can reach something. Every agent we host is connected to mail and documents, so it can read, respond and execute rather than only answer.
Reach
Agents are connected to the mail system and the collaboration workspace, so they interact directly with your files: read a document, reply to a message, run a tool against a folder. Access is granted per agent, and the actions are recorded.
Read, respond, execute — with the action recorded.
Boundary
Each agent runs inside its own boundary with its own resource limits and its own policy. Reach is not a side effect of the platform — it is a rule attached to the agent, and the rule is what the audit trail shows.
Access is a policy attached to the agent, not a property of the network.