Skip to main content

Shipped catalogue: 17 worker profiles across 5 execution harnesses.

Last updated 25 August 2026

Privacy

The payload of this product is your source code, so the only privacy policy worth publishing is a specific one. This says what is stored, where it runs, and who else sees it.

What we store

Your email and name. Your workspace, its settings and its members. The tasks you submit — the full text of the instruction, because it is what the router learns from — along with each attempt, its cost, its verification result and its timeline.

For repository work: the repository name, the branch, the commit and the pull request URL. We do not keep a copy of your repository. The clone lives in the sandbox and dies with it.

API keys are stored only as a SHA-256 digest. A leaked database cannot be turned back into a working credential.

Where it runs

  • Application: Dublin, Ireland (Vercel dub1)
  • Database: Ireland (Supabase eu-west-1)
  • Sandboxes, where your code is cloned and edited: Paris, France (Vercel cdg1)
  • Model inference: model providers reached through the Vercel AI Gateway, which may be outside the EU

That last line is the honest caveat. Everything we operate is in the EU; the models are reached through the Vercel AI Gateway and inference may run elsewhere. Claiming EU-only without saying so would be a promise the product cannot keep.

Who sees your code

A task can reach more than one model call: the router classifier sees the task text, the selected worker sees the task and supplied context, and the verifier can see the task plus the worker output. A workspace owner or admin can require no provider training or provider zero data retention. Managed calls combine a qualifying Gateway catalogue label with the matching per-request control. Sandbox coding CLIs cannot carry that per-request option, so a strict policy admits them only when the deployment attests team-wide Gateway ZDR. Unknown, partial, direct, and external paths are excluded; if a strict-policy utility model is unavailable, OpenAgent skips that classifier or judge call and uses a deterministic fallback. Refusals are recorded. The default is unrestricted provider handling. These controls govern the upstream model provider; OpenAgent still stores the task, outcome, and operational records described below. OpenAgent relies on the Gateway’s provider agreements and does not independently audit provider compliance.

A policy change is enforced when the engine reaches its next model or routing checkpoint. It does not recall a model request already in flight, and a detached sandbox CLI can make calls under the previous setting until the engine wakes and revalidates it. Set the policy before submitting sensitive work; the setting is not an emergency kill switch.

GitHub, when a repository is attached, because that is where the branch is pushed.

Some workers in the catalogue run on their own provider’s infrastructure rather than in a sandbox we control — Cursor and Devin, for example. Those workers publish no model metadata, so every policy stricter than unrestricted excludes them. If an owner chooses the unrestricted policy and the router selects one, your repository is handed to that provider and its own terms and retention apply. Which worker ran a task is recorded on the task and shown in the dashboard.

Customer-connected HTTP or A2A agents receive the task and context when the router selects them. A connected MCP server receives only the tool call name and arguments the selected worker sends to it, which can contain customer data. Destructive and write calls can require human approval, but the recipient’s own terms and retention still apply. Strict provider policy excludes the customer-managed agent paths because OpenAgent cannot enforce Gateway controls on them; MCP recipients are a separate customer-directed data flow.

Stripe receives account, purchase, and payment metadata when you buy credit or enable auto top-up. Stripe does not receive task text or repository contents from OpenAgent.

We do not sell data or share it with advertisers. The operators of the service access task or repository details only when needed to operate, secure, or support the service, including when you ask us to investigate a specific run.

Sub-processors

  • Vercel — hosting, sandboxes, and the AI Gateway that reaches the models
  • Supabase — the database and authentication
  • GitHub — repository access, only for repositories you connect
  • Stripe — checkout, payment, refund, dispute, and auto top-up processing
  • The model providers the Gateway routes to for your task
  • Cursor and Devin, when the router picks one of those workers — they run on their own infrastructure, not in our sandbox
  • Customer-connected HTTP, A2A, and MCP providers — only when your workspace connects or routes to them

How long we keep it

Tasks and their outcomes are kept while your workspace exists, because they are the evidence the router uses. Sandboxes are destroyed when a run ends. GitHub tokens are minted per run and revoked when it finishes, or expire within the hour regardless.

Workspace deletion is currently handled by support rather than a dashboard button. After we verify the request with an owner, deleting the workspace removes its tasks, attempts, keys and repository links.

Your rights

If you are in the EU or UK you can ask for a copy of your data, ask us to correct it, or ask us to delete it. Write to albin.holmgren97@gmail.com and we will answer within thirty days.

If something goes wrong

If we discover a breach affecting your data we will tell you what happened, what was exposed, and what we did about it — without waiting to have a complete story first.