Describe the work, build the flow, track the result.
Create tasks from chat, work with files in workspaces and combine AI with automation steps. Manage the process with shared memory, approvals and output tracking; software delivery and machine management live on the same platform. The screens shown use demo data.
Describe the work in chat, follow it step by step.
The assistant turns your request into a job draft; once you approve, the job runs in a workspace or on a branch of a software project. You see what the agent does step by step — and can send the running agent an extra instruction.
Draft card. The assistant doesn’t start a job on its own: it shows what will run on a card, and you approve, edit or dismiss it.
Live log and timeline. Files read, commands run, intermediate results — in order.
Question cards. When the agent can’t decide, it brings the question to the chat; the choice is yours.
Pick up where it stopped. Re-run, fix, or continue from the files that were kept.
See it in useResearchCustomer support
Workspaces for work that needs no code repository.
Research, reports and file summaries run in a workspace: you don’t pick a repo or a branch, you write what you need and add files if you want. When the job is done, the summary and the files the agent produced wait for you on the job page and in the Outputs screen.
Start from files
Add Markdown, text, CSV, JSON, YAML, PDF and images to a job; a file containing a key or password is rejected.
A summary first, then the files
A finished job brings a summary (summary.md) and the files the agent produced; preview them as Markdown, a CSV table, JSON, PDF or images, or download them.
Pick up where you left off
A new job takes the previous one’s outputs as input; a weekly automation starts each run from the result of the last one.
Outputs in one place
The Outputs screen keeps files, published sites and your notes together: search, tag, pin and download in bulk.
You choose the network access
Off, allow-list or web for each workspace; changing it needs an authenticator code and is written to the audit log.
Retention and quota
You set per project how long files are kept and how much space they may take; a pinned file is never removed.
Combine AI steps with real automation.
Workflows aren’t just AI steps: conditions, loops, HTTP requests, code and approval nodes run on the same canvas. We don’t impose a ready-made flow; design yours with AI by describing it in the chat, or build it yourself in the editor.
Schedule it or trigger it. Automations start on a schedule or from a signed webhook event; a run can continue from the result of the previous one.
On the worker, within the rules. HTTP and code nodes run on a worker under the project’s network rules; side effects carry an idempotency key and are applied exactly once.
Start from a template. Templates for marketing, content and video production are a starting point; let the AI adapt one in the editor, review the diff, approve.
See it in useContent and SEOSalesE-commerce
Your team’s rules reach every job the same way.
Brand voice, review rules, project facts and decisions live in one shared memory; when a job starts, the relevant entries go to the agent. For example: “Brand voice is short and direct”, “Claims are backed by a source”, “An editor reviews before publishing”.
Shared memory on the home pageTyped and scoped. Every entry is a rule, a fact, a decision or a lesson, scoped globally, to a person or to a project.
A person accepts lessons. Agents propose; a proposal doesn’t enter memory until a person accepts it.
Outdated knowledge steps aside. A superseded or expired entry no longer goes to jobs, but its history stays browsable.
A job keeps its version. A running job carries on with the memory it started with; you can tell later what it worked from.
See it in useSocial mediaContent and SEO
You decide which steps need an approval.
The same product works at both ends: teams that want speed let most work through without asking, regulated teams tie every sensitive step to a person’s approval and an authenticator code. With an approval node in a workflow, a person reads the result before the step that writes to the outside.
Serbest · flow
Approvals, merges and deploys pass without asking. For closed teams.
Dengeli · rules
Risky actions are asked according to rules; a code is required for the events you pick.
Sıkı · approval
Every sensitive action needs a person’s approval and a code. For regulated teams.
Asked in every mode: machine management, force-push and security-setting changes. Automatic decisions are logged as “approved by policy”.
See it in useCustomer supportE-commerce
What happened and what it cost — on one screen.
The one question a manager has: what happened, and what did it cost? You see problems without logging into a server, and can ask about most of them in chat.
System status
Server, database, queue, machines and disks; the last hour’s errors and integration checks.
Log search and traces
Seven days of logs, searchable by job, request and trace id; tokens and passwords are masked.
Usage and cost
Per runtime and account; limit windows and when they reset, on one screen.
Key and certificate expiry
Tokens, certificates and signing keys in one list; reminders 30, 14, 7 and 1 day before expiry.
Rollout circuit breaker
If updated machines start failing, the new worker release stops rolling out on its own.
Cost brake
Daily and monthly caps on API-billed spend; it warns first and, if you choose, holds non-urgent jobs.
See it in useData collectionFinance
Connect your tools; have the chat install new ones.
You connect to the tools you use through workflows and automations, using HTTP/API, signed webhooks and MCP, and set fields and permissions to fit your work. Installing a new tool doesn’t need hand-signed files or per-machine configuration: you preview and approve; it is tried on one machine first, then rolled out to every machine.
HTTP step. GET, POST, PUT, PATCH or DELETE to your tool’s API; the credential comes from the vault, to allow-listed addresses only.
Signed incoming webhook. Another system starts a workflow or a job with a signed request.
MCP servers. Remote, or local npm/PyPI packages; version lock, a trial on one machine first, per-tool permissions.
Skill catalogues. Search with “Discover”, preview, install with an approval; pinned to a commit.
Requests with @credential. A key from the vault is used in requests without its value ever being shown.
API tokens and OpenAPI. Scoped, expiring tokens; every endpoint is in the public API document.
Outgoing webhooks. Job, approval, deploy and workflow events go signed (HMAC) to n8n, Zapier or your CI.
See it in useSalesCustomer support
For software teams: from a new repo to a deploy.
Agent work doesn’t stop at a PR. Verification, the merge decision and the release are one flow; long-running dev servers and tunnels run as services that don’t hold a job slot.
Repo
A private GitHub repo is created and linked to the project.
Agent
The job runs on its own branch; the platform does the commit and push.
Verify
The branch is verified; a PR and a merge decision are opened.
Release
Coolify, Cloudflare Pages and DNS — domains, environment variables, watched paths.
Repositories: GitHub, GitLab (gitlab.com or self-managed) and Bitbucket Cloud. Keys stay encrypted on the server and never reach the model.
See it in useSoftware
Machines
- build-01Linux x64 · containerClaude CodeCodex2/4ConnectingReady
- mac-studiomacOS arm64 · runtime sandboxClaude Codeopencode1/3ConnectingReady
- win-ops-02Windows x64 · per-job accountCodexpi0/2ConnectingReady
- docker-01Docker · containeropencodepi0/2ConnectingReady
Invoice PDF export→ build-01 · Claude Code
The machines that run the work, one pool.
The queue places each job on a suitable machine, taking capacity, disk state and the required runtime into account.
One command to connect. Linux, macOS, Windows or Docker; the install script is checked against the digest shown in the panel.
Capacity and health. Load, disk, sessions and runtime versions on one screen.
Central git identity. No logging into machines one by one; a short-lived token per push.
Signed updates. Worker releases are signed and roll out to the fleet gradually.
See it in useSoftwareData collection
A failure doesn’t wait for a person.
Overnight jobs and scheduled automations don’t sit there “failed” in the morning. Transient errors are retried with growing intervals, on another machine if needed.
- 02:14
A job stops on a transient error.
- +1 min
Automatic retry.
- +5 min
If needed, on another machine.
- done
The result arrives as one notification.
- Self-healing
- Missing branches, diverged history and permanent failures open a fix job on their own.
- Limit awareness
- When a runtime reaches its usage limit, the whole fleet knows; the job waits for the window to reopen or continues on a fallback runtime you chose. Paid API usage only if you allow it.
- Queue safety
- No jobs go to a machine whose disk is full; malformed messages don’t stall the queue.
- Outage-tolerant
- If the panel is unreachable for up to 15 minutes, running jobs carry on; results and approval requests wait on the machine.
See it in useData collectionResearch
Your server, your schedule.
One installation for one company. The control plane runs on your Linux server, and you decide when to upgrade.
- Verified install. The script checks the release signature and every file; if anything is off, it stops before changing a thing.
- Setup wizard. Organisation, security preset, first machine, git connection and a sample job — every step can be skipped.
- Safe upgrades. A mandatory backup first, then migration and a health check; if it fails, the way back is ready.
- Diagnostics. One-click server and machine checks; preview a masked support report, then download it or send it by email.
# download the signed installer
$ curl -fsSLO https://<release-url>/<version>/install.sh
$ sudo bash install.sh --domain ops.example.com \
--tls letsencrypt --email [email protected]
# verify → pull → migrate → start → health check
# then: https://ops.example.com/setupMore than a single agent tool.
| Need | Agent CLI on one machine | Remyral |
|---|---|---|
| Your own server and machines | Partly | Control plane and jobs on your side; model calls go to the provider you choose |
| Many machines, one queue | No | Yes |
| Several runtimes; wait or fall back at a limit | No | Yes |
| Adjustable autonomy, per-event verification | Partly | Yes |
| Audit chain and team roles | No | Yes |
| End-to-end flow from code to deploy | Manual | Yes |
Remyral doesn’t replace the agent CLIs; it runs them across many machines under shared rules. Remyral provides the system; you use the models with your own accounts — by subscription (e.g. Claude, ChatGPT) or with an API key. Subscription and API use are subject to the provider’s terms.
Want to see it with your own work?
In the four-week pilot you try these features on your own server, with the flow of your own work.