Projects

A project is one piece of work

Work does not arrive one profile at a time. A client needs accounts, the proxies behind them, the cookie sets that keep them signed in, the automations that run them and the tables those automations fill — and every one of those lives on a different tab. A project is the name you give that whole set.

Give it a name, a colour and a one-line goal, then add the things that serve it. The card shows what it holds — “3 profiles · 2 proxies” — and opening it gives you its contents, its rules and its memory side by side.

A project is not a folder

The app has both because neither does the other’s job. A folder answers where do I file this: a profile sits in exactly one profile folder, a proxy in exactly one proxy folder, and the two lists never mix — that is what keeps “EU residential” out of the profiles rail.

A project answers what is this for. It spans every tab, and the same thing can belong to more than one, so a shared EU proxy can serve two clients without being copied. Use folders to tidy one list, and a project to hold one job together.

What goes in, and what comes out

Membership is a link, not a move. Adding a profile to a project does not take it out of its folder, does not change it, and does not stop it working anywhere else. Removing it again removes only the link.

Every tab, narrowed

Pick a project on any tab and that tab narrows to its things: Profiles, Proxies, Cookies, Automations and Data all filter to what the project holds, so a client’s work is one click away from being the only thing on screen. Scheduled entries can belong to a project too, which is how tonight’s calendar can be read as one client’s day.

Which is what makes a project worth having on a busy workspace: the same list you already work in, with everything that is not this job taken out of it. Put an entry on the calendar and it can belong to a project too.

Rules that are enforced, not requested

A project can constrain what the assistant may do inside it. Its brief opens with a small block: a one-line goal the assistant is shown on every turn here, an autonomy level — look only, ask first, or act — a list of tools it may never call in this project, and the wall-clock hours outside which it may not change anything.

It is the difference between a system prompt and a lock. The assistant is capable enough to be worth constraining, and a constraint that only holds while the model cooperates is not a constraint.

The project's memory

Each project keeps a small set of documents the assistant reads and writes: the brief, rules it must hold to, notes on what it has learned — a selector that moved, an account’s quirk — and runbooks for a procedure that worked.

The assistant never writes there without showing you what it wants to save and waiting. What it writes it will believe on every later turn, which is exactly why nothing lands unreviewed. Only document titles reach its prompt; a body is fetched when it is actually needed, so a project can accumulate a hundred notes without making every message more expensive.

Projects over the API

A project is a named piece of work and the profiles, proxies, cookie sets, automations and datasets that serve it, along with a brief and a set of rules kept on that machine. Every route here needs a key with no folder scope: a project deliberately spans folders, so honouring one would mean answering with half a project. Reading a single document is the one route with no agent tool — it backs an MCP resource instead, so a body is fetched only once a client has decided it wants that body.

A folder-scoped key is refused outright rather than served a partial answer it cannot tell apart from a whole one. The document route is reached as argus://project/<id>/<path> — a resource rather than a tool, so a body costs context only once a client has decided it wants that body.

Delegating hands a goal to Argus's own orchestrator inside the project, which is usually better than driving the project's profiles yourself: it already holds the brief, it enforces the autonomy level and the never list in code, and it writes what it learns back into the notes. It answers with what it set in motion rather than waiting for the run to end, so read the project's context or its notes for how it went.