●AI workflows on your own serverremyral.com

Collective Intelligence Infrastructure

Many agents.One intelligence.

From content to sales, support to finance, research to software: describe the work and build the flow with AI or by yourself. Agents run on your machines, connected to your own server, and you decide which steps need an approval.

Supported agents
  • Claude Code
  • Codex
  • opencode
  • pi

Social media

demo data
See the social media example
Installation
your server
Connections
API · webhooks · MCP
Jobs
on your machines
Interface
English · Türkçe
01The product at workanimation · demo data

From a request to an output you can review.

Describe the work in chat. The assistant prepares it; an agent on your machines or a workflow you built carries it out. Review the result and continue with further instructions when needed.

  1. 01

    Write the request

    Describe the work in your own words; a clear command just runs, a request becomes a draft.

  2. 02

    Draft

    The assistant prepares a job or workflow draft. Approve it, edit it or dismiss it.

  3. 03

    Decision

    An open question comes to you as a question card, a step that needs approval as an approval card. You decide which steps need an approval.

  4. 04

    Output

    A report, a table, scheduled posts or a merged change: the result comes back to the chat with a summary for you to review.

See the social media example
demo data
  • Where is the data? Files and records stay on your infrastructure; content processed for AI goes to the model provider you choose.

  • Question cards. When an agent can’t decide, a multiple-choice or free-text question lands in the chat.

02Three benefits

Run agents as a team — under control, on the record.

The problem isn’t how good the agents are; it’s operating them as a team. Remyral is that operations layer.

  1. 01

    Agents work as a team

    Jobs go from one queue to a suitable machine instead of depending on one person’s computer. Shared memory gives every agent the same rules and decisions.

  2. 02

    You stay in control

    The control plane and the jobs run on your infrastructure. You choose how autonomous it is and which actions need an approval and an authenticator code.

  3. 03

    Every step on the record

    Approvals and privileged actions go to a tamper-evident (hash-chained) audit log; usage and cost on one screen.

03Architecturecontrol plane + workers

One control plane, as many workers as you need.

The control plane runs on one Linux server: panel, API, queue, vault and audit log. The agents don’t run there — they run on your machines.

Workers connect outbound; no inbound ports are opened on your machines.

Connects to
  • HTTP / API
  • Webhook
  • MCP
  • GitHub
  • GitLab
  • Bitbucket
  • Coolify
  • Cloudflare
  1. 01

    Install

    The control plane comes up on one Linux server through an installer that verifies the release signature.

  2. 02

    Connect

    “Add machine” in the panel, two lines on the machine; confirm the pairing code and fingerprint.

  3. 03

    Run it from chat

    Describe the work; the assistant drafts a job or carries out a clear command directly.

04Shared memoryrules · facts · decisions · lessons
demo data

Example work instructions (demo data); they don’t replace a security policy.

Every agent works from the same memory.

Your team’s rules, known facts, decisions and lessons live in one shared memory. The same memory reaches Claude Code, Codex, pi and opencode in one rendering.

  • Typed and scoped. Every entry is a rule, a fact, a decision or a lesson, scoped globally, per runtime, to a person or to a project.

  • One memory, four runtimes. Claude Code, Codex, pi and opencode read the same memory from the same rendering.

  • A person accepts lessons. Agents propose lessons; a proposal doesn’t enter memory until a person accepts it.

  • History stays. Superseded or expired knowledge stops steering agents, but its history stays browsable.

  • Reproducible jobs. Every job pins the memory versions it used, so you can tell later what it worked from.

06ConnectionsHTTP/API · signed webhooks · MCP

Build your workflow around your tools.

We don’t impose a ready-made flow. Design yours with AI or build it yourself. Connect external tools through workflows and automations using HTTP/API, signed webhooks and MCP, then configure fields and permissions for your work.

  1. 01

    Pick the tool

    Choose the tool and its API; if you’d rather not use an API, start from an exported file.

  2. 02

    Set the key and the permission

    The API key is sealed in the vault; the tool’s address is added to the project’s allow-list.

  3. 03

    Design the flow

    Describe it in the chat or build it in the editor; AI, approval and HTTP steps on one canvas.

  4. 04

    Try it with sample data

    Run it by hand first and see each step’s input and output.

  5. 05

    Schedule and track

    A schedule or a signed webhook starts it; approval requests and results come to you.

If your tool can’t produce Remyral’s signature, put a small signing step in between, or poll the tool’s API on a schedule.

The connection process in detail
07Security and data controlvault · sandbox · egress · ed25519 · hash

Work files on your infrastructure. Your rules.

  • A vault sealed with the worker’s key

    Runtime and API keys are sealed with the key of the machine that uses them; the master cannot open them. Boundary: git and deploy tokens are stored encrypted on the control plane and are never sent to a worker or the model.

  • Sandbox and network policy

    Per project: off, allow-list or web. Local network and metadata addresses are always blocked.

  • Signed releases, chained audit

    Worker updates are signed; every privileged action is on a tamper-evident (hash-chained) audit log.

Where is your data?

Control plane
Panel, database, queue, vault and audit log on your Linux server.
Jobs
Repositories, workspaces and logs on your worker machines.
Model calls
From the worker to the model provider you choose; the provider’s terms apply.
External tools
Data sent out goes to the connections you set up in workflows and automations, to allow-listed addresses.
Claims, limits and roles
—The nameRE · MYR · AL

Collective intelligence, built into the name.

A single ant knows very little. The colony, through local communication and division of labour, solves complex tasks. In Remyral, each agent does what it is good at, on another computer if need be. Work goes to the right agent, knowledge and experience are shared through a common memory, and independent work moves as one.

  1. RE

    Remana

    Our slogan: “We are redefining technology”. Remyral is a product of remana.tech.

  2. MYR

    Myrmex

    Ancient Greek for ant: the intelligence of the colony, of the whole rather than of one.

  3. AL

    Agent Layer

    The shared management and coordination layer the agents run on.

Many agents. One intelligence.

Intelligence doesn’t have to stay in one model, compute on one computer, or knowledge in one session.

The RE · MYR · AL expansion is a brand-specific meaning, not a dictionary definition.

→Pilot

Let’s start with a four-week pilot.

  1. 01

    Define the need

    In a discovery call we pin down your recurring work, the tools you use and the result you expect.

  2. 02

    Install on your server

    Remyral goes on your server, and the agents that run the work on your machines.

  3. 03

    Build and try the flow

    We build the flow together, with AI or in the editor, set the approval steps and test it with sample data before using real data.

  4. 04

    Review the results

    Together we look at the finished work, the time and the cost; you decide whether to continue.

We start from your work: which task, which tools, which output.

Pilot scope and price are agreed in the call around your needs; we reply to applications within 2 business days.

Prefer email to a form? info@remyral.com

Pilot application

Spam protection runs on our own server: once you start filling in the form, your browser completes a short check.

?FAQ

Frequently asked questions

How do model accounts work — subscription or API key?

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. For team and automated use, an API key is recommended. API keys sit in the vault, sealed with the key of the machine that uses them; a subscription login is done on the worker machine.

Which operating systems are supported?

The control plane runs on a Linux server (x86_64 or aarch64; Ubuntu 22.04+, Debian 12+, RHEL / Rocky / Alma 9+). Windows and macOS — including Docker Desktop — are not supported for the control plane. Workers run on Linux (x64, arm64 and 64-bit Raspberry Pi OS), macOS (Apple silicon and Intel), Windows 10/11 x64, and as a Docker worker.

Where does isolation start and end?

Every job runs with a sandbox profile: container (rootless Docker or Podman on Linux), runtime-sandbox (the agent’s own sandbox) or host-restricted (a restricted account on the machine; on Windows a separate account per job with process, memory and CPU limits). Limits: jobs on the same machine share localhost ports and the process list; on Linux, host-restricted jobs run one at a time and parallel jobs need the container profile; jobs that share one subscription login run one at a time. Full machine access (unconfined) only opens when both the machine and the project explicitly allow it.

What does it cost to run?

Model usage is paid directly to the provider, through your subscription or API bill. Remyral shows usage per runtime and account and lets you set daily and monthly caps on API-billed spend: it warns first and, if you choose, holds non-urgent jobs. Remyral’s own price is agreed in the pilot call.

How is it installed?

The control plane is installed on one Linux server with an installer that verifies the release signature and every file; if verification fails, it stops before changing anything. Then the setup wizard opens: organisation, domain and access, security preset, first machine, git connection and a sample job; every step can be skipped. A git connection is only needed for software projects; research, reports and file work run in workspaces that need no repository. Machines connect via “Add machine” in the panel, with a two-line command and a pairing approval.

Where does our data live?

The control plane (panel, database, queue, vault, audit log) on your server; jobs, repositories and workspaces on your worker machines. The agents’ model calls go to the model provider you choose and are subject to that provider’s terms; data sent to external tools goes to the connections you set up. Git and deploy tokens are stored encrypted on the control plane.