The Plexus agent harness for Windows
An agent on your real systems. Built so every action is checked before it can touch them.
An agent that can click anything on your real systems stays a liability until someone can say what it was allowed to do before it acted, and what it did after. The harness decides the before. Plexus keeps whatever the harness sends after.
§ 01 The problem
An agent that can click anything.
Two questions decide whether that agent gets near production. Before the action: what was it allowed to do? After the action: what did it actually do?
The Plexus agent harness for Windows answers both. Nothing the agent proposes reaches your system until it has been checked against the agent's role, and with Plexus connected, what happened is on the same record your auditor reads, and so is what was refused once the harness asks the record before acting.
§ 02 How work flows
The agent proposes. The harness decides.
One action at a time, in four plain steps. The agent never holds the keyboard on its own.
01
Propose
The agent looks at the screen your operators see and proposes one action. It cannot carry that action out itself.
02
Check
The harness checks the proposal against what this agent's role is allowed to do. An action outside the role stops here.
03
Act
An allowed action is carried out on the real application, a Windows desktop program or system console, the way a person would do it.
04
Record
Steps the harness forwards land on the record. Where the harness asks the record before acting, the refusal and its rule land too; the pre-launch build is built to ask, and no deployment does yet.
§ 03 What it will not do on its own
Where a person decides, a person decides.
You choose how much the agent may do on its own, per workflow, on a ladder that starts fully supervised.
Sensitive actions wait for a person.
By default, where your policy says a human decides, the agent stops and a person approves or declines. The harness keeps the decision; the Plexus record holds that the check was raised.
Commitments in your name wait for a person.
The agent does not sign, swear, or accept terms for you. Where a commitment is yours to make, a person makes it. The harness keeps that decision.
Walls stop the agent.
By default, when the agent reaches a check meant for a human, it stops. It does not carry on past it. A person takes the screen from there, or the work ends.
§ 04 Where it stands
In the current build, and what is next.
"In the current build" means the capability is built and wired into the harness's pre-launch build. It has not been verified running in a deployment, and it is not a statement about customer deployments. For checking each tool call against policy and for handing off at a wall, the record side is live today; the harness side is built in the pre-launch build and not yet connected to it in any deployment.
In the current build
- Every action the agent proposes is checked against what its role is allowed to do before it can touch the target.
- When an action is refused, the refusal and the reason are kept in the harness's own trace, not discarded.
- By default, when the agent reaches a check meant for a human, it stops and does not carry on past it. A person can take the screen from there.
- By default, sensitive actions stop and wait for a person to approve or deny, and the harness keeps that decision.
- The harness operates Windows desktop applications the way a person does, not through an API.
- An engineer installs it on a machine inside your perimeter.
Built, being switched on
- Carrying one audit context across several applications in a single piece of work.
- Spending and loop safeguards that pause an agent that is going in circles.
§ 05 On the record
A harness acts. Plexus keeps what the harness sends.
The steps the harness forwards, what the agent proposed and what the application did, are attributed to a known agent and kept on the tamper-evident Plexus record, where your auditor can check it without asking us. Refusals land there too once the harness asks the record before acting, which no deployment does yet. Where a person had to approve, the record holds that the check was raised, when, and the operator session; the approval itself is kept by the harness today.
§ 06 Where it runs
Installed in your perimeter. Plain about what leaves it.
The harness is a desktop application that runs on a Windows machine you control, next to the applications it operates, and our engineers install it with you. Nothing is hosted by us, and the Plexus record stays inside your perimeter.
One thing does leave the machine today, and you should know exactly what. To decide what to propose, the harness sends a picture of the whole screen, and the text of the application in front, to the language model you choose. By default that is a model provider's API, under your agreement with that provider. The build can also be pointed at a model you host yourself. That is an option, not the default, and it closes one path out of the machine, not all of them.
The substrate is designed to run air-gapped. The harness is not air-gapped, and we say so.
Pre-launch · first design partners
See it on a real workflow.
Bring one workflow that lives on a screen with no API. We will show you the agent doing it under the harness, and the record it leaves.
Request a demo →