Back

Documentation

How Jelly Task works, what a worker may do, and what stops it.

Getting started

Create a project

A project is the unit everything hangs off: its own workers, its own connected accounts, its own memory. One company, one client, one side build. Nothing is shared between projects unless you deliberately share it, which is what makes it safe to run a client's work beside your own.

The Free plan includes 1 project and 1 worker, which is enough to see what this does before deciding anything.

Connect the accounts it should watch

There are 53 systems you can connect, and you connect each one with your own keys. Credentials are encrypted the moment they arrive and are never sent to a model.

Connect read-only first if you would rather. A worker that can only read still tells you a great deal, and you can widen it later.

Hire one worker

Pick from the templates or describe what you want in plain English. Give it a job, say which systems it may touch, and set how far it may go without asking.

Start it on "watch only" for a week. What it notices is a better basis for trusting it than anything written on a website.

Workers and authority

The four levels

Watch only reads your systems and changes nothing, whatever it is asked to do and whoever asks. Draft only prepares the email, post or listing and sends none of it. Ask me first shows you the exact words and the exact account, then waits. Named actions runs unattended, but only the specific actions you named on the accounts you named.

Authority is set per worker, per connected account and per tool, so a worker can read your store and still be blocked from one specific action in it. A worker can never act above its ceiling.

Choosing a model

By default the router picks, weighing the task against quality, speed and cost, and falling through to another model if one fails. Most people never think about it.

If you want a specific model, you can pin one per worker under Advanced. The default is deliberately not a model picker: which model wrote something matters far less than whether you approved it.

Stopping everything

Pause every worker in a project in one click. The next thing any of them tries is refused rather than queued to run later, which is the difference between a pause and a delay.

Approvals

What stops

Anything that publishes, spends, deletes or deploys stops as a proposal. You see the words, the account, the tool and whether the action can be undone, and you approve it, edit it before approving, or reject it.

This is not a setting you have to find. It is the default, and a worker has to be given authority explicitly before anything runs unattended.

Reviewer workers

You can put a second worker in front of yourself. One drafts, another checks it against your brand rules and the facts, and only what survives that reaches your queue. Useful once you trust the work and want less of it in front of you.

The audit log

Every action, who asked for it, who approved it and what came back, recorded on every plan and never edited. Your plan decides how far back you can read it, not whether it was kept.

Briefs and alerts

What you are told about

Failures, alerts, anything waiting for your approval, and your briefs. Successes go into the brief rather than into a notification, because notifying on every success is how failures get missed.

Each kind can be switched between in-app and email per person, so somebody who wants only approvals can have only approvals.

Briefs

A brief is what happened while you were not looking, merged across everything a project touches and ranked by consequence rather than by time. Cadence depends on your plan, from weekly up to a morning brief and a cross-project executive brief.

Plans and Work Units

Work Units

Model work is metered in Work Units. Every plan includes an allowance, and Free includes 50 a month at no cost. You can top up at any time and credits never expire.

There is also a daily ceiling on included units. It exists so one bad loop cannot spend a month's allowance in an afternoon: coming back tomorrow is a much smaller problem than a month gone by Tuesday.

Changing plan

Nothing is ever deleted when you move down a plan. Anything over the new limit is locked: still fully readable, still exportable, just unable to run. Oldest survives, so the project you have run for a year outlives the one you made on Tuesday.

Moving back up unlocks exactly what the downgrade locked, and nothing a person switched off deliberately.

Security and your data

Credentials

Connected account credentials are encrypted with AES-256-GCM and bound to the account they belong to, so a secret stored for one account cannot be opened as another. A worker never holds them: it asks for an action and the platform performs it.

Secrets are never sent to a model, and are redacted out of logs and error messages.

Between projects and between accounts

Projects are sealed off from each other. A worker reaches only the accounts connected to its own project, and memory retrieval is scoped to the project that asked, never to anything a model supplied.

If you believe you have found a way around any of that, please email support@jellytask.app rather than using the support form.

Still stuck?

Write in and a person reads it.

Contact support