1Start here: what it is, what it costs, how to begin
Devoku is an AI employee that works on a computer of its own. You describe the job in chat or by voice, and it sets up its own environment and its own automation instead of borrowing a chat window for an hour. Each time it does a task it learns from that run and uses the knowledge the next time. It writes and keeps its files straight into its workspace folder, connects to whatever systems you ask it to, and automates itself when the work has to run continuously. It works out how to do your task by whatever means are needed. It keeps the workspace, the logins you gave it and what it has learned, so it does not reset before the next run. To run a Devoku employee you need to spin at least one Devoku computer, which starts at €79 a month. One Devoku computer can run many Devoku employees. You can also chat in Devoku not only with agents but with other people as well, for free, as well as forward messages in between human and agent chats instantly.
A chatbot like ChatGPT is for asking questions, with limited real-time search and limited file editing. An agent software like Claude Code, Cursor or Codex works on your own computer only until the tab closes, or inside someone else’s sandbox that has no persistent storage, no reserved CPU and RAM, and no freedom to install the tools a job needs. On top of that you are locked into one vendor’s ecosystem and depend entirely on how good its latest agents happen to be, with no way to bring your own preferred LLM or custom model.
Devoku builds a Go and Postgres runtime on top of them and normalizes them all into one identical, unsandboxed runtime, so every Devoku employee gets a real configurable computer, persistent storage, the ability to switch between any LLM model in the same environment, automatic learning through the Devoku CLI that writes down and retrieves what has been learned, the Devoku message queue system, and the ability to automate itself from what you tell it. You do not build the flow. You describe the job and get a persistent agent.
Any business that wants to scale, or any person who wants to automate their own work.
If you already use agents like Claude Code, Codex or Cursor, Devoku gives you an automation, accessibility and persistence layer on top of them. If you want to use the platform standalone, Devoku gives you an instant Devoku Jet runtime to do the same job on our own composite AI model system. If you want to expand your operations and take on more client work, you hire an army of Devoku AI employees, let them talk to each other, and let them work on what needs to be done.
A persistent Devoku computer starts at €79 a month for 2 vCPU and 8 GB of RAM, and you can run many Devoku employees on it. You can also chat with other people straight on Devoku for free.
A Devoku computer can be resized up to 8 vCPU and 64 GB of memory, or up to 80 vCPU and 512 GB of RAM for enterprise users. The default limit is 5 Devoku computers per user, which can be increased on request. Disk sizes at creation range from 40 to 300 GB included, all resizable to 1 TB, and each size has its own price on the pricing page.
If you want human chat, Chat Pro is a €9 add-on for unlimited message history in human chats and 250 GB of storage for human chat lines. Agent chat lines are available for as long as you keep your Devoku computer. VAT and sales tax are applied where applicable. Services can also be purchased through the iOS and Google Play stores at higher rates, due to platform fees.
Nearly anything you can ask it to do or automate, as long as the work is digital. You do not build pipelines or automations: you chat with Devoku through a simple chat layer and it acts instantly, rather than only answering.
When it needs details from you, such as logins and passwords for closed sources it has to reach to finish the job, it asks you to paste them securely into the encrypted Devoku Secrets Vault in that agent’s Brain, which is built on OpenBao, instead of pasting them into the chat.
For ideas, see the job examples page: 42 examples are listed there, and it is not limited to them. It is built universally, to do what you need.
Yes, because it works the way a person does: in the browser with your logins, and through an API where one exists. If you already use an app in your business or daily work, it can control it. A few examples: Gmail, Slack, Notion, HubSpot, Stripe, Asana, Shopify, Telegram, Sheets, your bank portal, your accounting software, a government registry — if you can sign in and click it, the Devoku employee can work it.
Credentials live in Secrets, and a site’s own API is used where that is faster. Most importantly, there is no connector or plugin list to wait for: it is built universally to work out the correct connection to any app. If it needs anything extra from you, it will tell you.
Minutes to the first message. To run your first Devoku employee you choose a computer size and an AI model — Devoku Jet, Claude Code, Codex or Cursor — and the employee exists. You then chat with it in a normal chat window and, together, you discuss and decide how to operate that job or automation. The agent also answers any questions you have about how Devoku works and how to use it, so you do not need to read or study the instructions beforehand. Everything happens live for you.
Yes, and that is the beauty of our custom-built Go and Postgres orchestration layer that normalizes agent work. You can control and access the same agents instantly from any device, including iOS, Android, any browser, macOS or Windows. Everything syncs in milliseconds, and you do not need to hand anything over before leaving your computer. You continue communicating with the same agent straight from your phone, through messages or by sending it voice messages.
It is our custom-built Linux image, created for agent workspaces and automations and loaded onto physical hardware starting from 2 CPUs and 8 GB of RAM, for efficient parallelism and multitasking, so that you can run many agents on a single Devoku computer.
We manage a warm liquidity pool of such computers, so most common spec types spin up for you within 15 seconds of purchasing one and then persist only for you. More powerful premium ones take up to 10 minutes, and they also persist only for you once booted.
There are three types of Devoku computer: Full-Stack, where our Devoku orchestration and agent works run on a single machine; Orchestration only, where the Devoku orchestration layer runs separately from the agents; and Workspace only, where the agents run separately from the orchestration layer. Depending on the isolation and sensitivity you need, you can opt for a single Full-Stack Devoku computer or a stack of two Devoku computers (one orchestration plus one agent workspace).
A computer of your own, sized to the price: 2 to 8 vCPU and 8 to 64 GB of memory as standard, up to 80 vCPU and 512 GB of RAM for enterprise users, 40 to 300 GB of disk included and resizable to 1 TB, root if you want it. On it:
- A workspace: a real computer-like folder that behaves like any other directory, with optional git, your tools and last week’s files still in it. You do not need to sync and fetch each job from git if you do not want to.
- A browser: a normal and a stealth browser, signed in with your logins, watchable and controllable live from the chat by both you and the agent at the same time. It can be routed directly from your Devoku computer IP or through a residential proxy such as Oxylabs or Webshare when a task requires it.
- A Brain: Rules for critical guidelines injected with every prompt; Knowledge for the accumulated, learned mechanics of performing a task; Goals so it does not forget what needs to be done; and Secrets for your sensitive information such as emails, passwords and API keys, encrypted with OpenBao and not visible in the agent’s outputs as plaintext.
- A schedule, the automator: it lets the agent repeat the job by itself, including letting the agent change the task on each run; a primary LLM model for automated runs, with a backup LLM model in case the primary fails; and runtime configuration for what to do when the chat is busy or a run fails.
- A supervisor, if you want one: a second Devoku employee above the first that heals, restarts or redirects a run that stalls. You can stack as many supervisors on top of each other as you want.
- Chat lines: separate threads for the same agent, each with its own context, so you can work on multiple tasks in the same folder at once while sharing the same agent Brains.
- Backups: encrypted restore points of the workspace, the chats, the Brain and the secrets, so you can restore a job that was already done, with configurable snapshot frequencies.
- Team: other people at read-only or read and write on the same agent in your workspace. You can all see and control the same agent, while seeing when someone is typing.
- API keys: every Devoku employee gets scoped API keys that allow other internal or external agents to reach that agent’s workspace, chat and Brains directly, or the same for a single chat line. Read and write API keys also let any internal or external system or agent control, invoke and chat with your agents.
- Devoku CLI: a CLI that lets Devoku employees interact with and control all of the most used functions listed above by themselves, so you do not need to set up anything manually.
One Devoku computer can run multiple employees at once, and each of them keeps its own runtime.
BRN holds what it knows, what it must obey and its secrets. AUT is the automator, for autonomous agent work. 247 is a supervisor that puts a second employee above the first to watch it. BRW gives you literal access to your agent workspace folder, so you can download any files it has generated onto your device. WEB shows the browser it is using, live. API is for when you want quick enabling for agents to talk to each other and pull data from each other. The rest — find, sessions, clone, team access, backups, summarisation — are described in each popup screen.
4Working without you: schedules, supervisors, recovery
Yes, once you ask for it. It arrives with the computer and the engine you chose, and it does not start working on its own. Ask it to run every morning at seven and it writes the schedule, starts it, and changes it later. It runs whether your laptop is open or not. What it will not do is give itself access it was not given: creating employees and chat lines needs an account key that you hold.
A supervisor is a second employee that does not do the work; it watches the employee that does. You write the instruction — retry, nudge, escalate — and it checks on every run. It can watch one chat line or the whole employee, and it can cover several targets at once with a separate instruction for each. A supervisor can have a supervisor above it, as many levels as the work needs. Nothing happens until you start it, and it runs on its own schedule, outside the retry stack.
It retries, inside limits you can see. Retries per context sets how many times an attempt repeats; maximum forks sets how many fresh contexts it may open. Both default to four and stop at ten. A fresh context carries the conversation with it, so the work continues where it broke. When both are used up the run stops and says so — it does not loop quietly. Then either a supervisor you assigned picks it up, or nothing does until you do.
Partly, and the part it does is the part that saves you money. When it settles on a procedure it expects to use again, it writes the steps into Knowledge and follows them next time; when the procedure changes, it revises that entry instead of adding a second one beside it. It does not record guesses or one-off state. Knowledge is not pushed into its context automatically — a line in Rules tells it when to read an entry. Ways of working belong in Rules, which always apply.
Yes, both. An image comes from a description, or from editing one already in the workspace, at five aspect ratios from square to 16:9. A video comes from a description, a still, or two frames, in 16:9 or 9:16, up to 4K and ten seconds, and a clip of up to ten seconds can be edited. Audio is best effort, not a guarantee. Both are metered — per image, per second of video — and a large batch asks for your approval first. Output lands in the workspace and in the chat.
It cannot do work that needs your hands, your signature, or a judgement made in the moment. It will not retry forever: when the limits are used up, the run stops and says so. It does not share what it learns with another employee unless you move it. And it still needs you to check the work that matters.
Every run leaves a record: what it was asked, what it opened, what it produced, how long it took and what it cost. You can watch a browser session live, read the chat line, or open the transcript a week later. If you want a second pair of eyes, put a supervisor above it and it will tell you when a run stalls.
5People and privacy: who sees what
Yes, by default. A collaborator sees only the employee you invite them to, and only at the level you give: read-only, or read and write. Nothing passes between employees unless you move it.
An individual account is the private case: one login, no one above it, nothing to administer.
An organisation account has to be able to run itself, so it reaches further, and each role stops somewhere. An Admin can open, export or delete a Member’s chats, files and work — but not another Admin’s, and not the Owner’s. The Owner can reach everything on the team. If the work has to stay behind one login, keep it on an individual account.
Two sizes: 5 people and 25, including the owner, on one bill; the pricing page has the seat price. Seats, Chat Pro and the computers bill to the team rather than to each person. Every member gets their own employee and their own Brain; a team does not merge them. The owner sets what each person may do — whether the team pays their Chat Pro, whether they may ask for a computer, how many they may run, and a monthly cap on everything billed for them. Sign-on through Okta, Microsoft Entra or Google Workspace is included on a paid team.
A Member works in their own space and cannot open anyone else’s. A Manager is assigned to specific people, with read-only or read and write on their AI workspace; those people’s human chats stay view-only. An Admin sees every Member’s and Manager’s AI workspace, can read their chats, invite and deactivate people, set limits, approve computer requests and change the card — but cannot open another Admin’s work or the Owner’s. The Owner sees everything on the team and holds the card.
Yes. Open the message’s actions, choose Forward, and send it to an employee’s chat line or to another person, with a note if you want one. The employee treats it as any other instruction. It is a one-off handover: forwarding does not open the conversation it came from, does not make the recipient a supervisor, and nothing is passed on afterwards.
Edits. A read-only collaborator can read the chats, open the files, take copies of the output and clone the employee, which carries a copy of the Brain and an isolated copy of the workspace. What they cannot do is steer it: no messages, no work broken into steps, no schedule started, no change to the settings, the Brain or the keys, and no write to the files. Read-only protects the work from being changed, not from being copied. If you need that, do not invite them.
10Memory and cloning: the Brain, and a second copy
Everything it knows and must obey, in five parts. Rules: the constraints it may not decide for itself. Goals: what it is working toward, and the status. Knowledge: procedures, facts and references. Secrets: logins and keys, resolved only when a run needs them, masked in the interface and never included in a Brain export. Context: the background it keeps about the work. You can read and edit the first three; a secret value can only be replaced.
Write it down once, in the place that fits. Standing standards — tone, what it may never do, which folder is off limits — go in Rules, because Rules always apply. A procedure you want repeated goes in Knowledge, with a line in Rules saying when to read it. Logins go in Secrets. It keeps the procedure and updates it when the work changes, so you explain it once, not every month.
Not by themselves. Each has its own Brain and nothing is shared or synchronised, so a second employee knows only what it has been given. Three ways to move it: a clone forks the Brain and brings an isolated copy of the workspace; an export moves Rules, Knowledge and Goals into any other employee, with Secrets separate; or employee B holds a scoped key for employee A and reads A’s Brain directly, or writes to it if the key allows.
CLN forks the employee: the Brain comes across, the workspace becomes an isolated copy, and the clone can edit the same project in parallel without touching the source. It always runs in a separate folder, and the app refuses a path inside the source workspace, so two runs cannot write over each other. It works whether or not the folder is a git repository.