Product · seven screens

One place to work, one place to manage it

The entry point, the permissions and the ledger are spread across seven screens. Employees use the first four daily; administrators oversee the last three. Staff who do not know how to prompt can follow a workflow or bring in an AI team already divided by role.

Talk to us

Workbench

A clear next step from the first sign-in

Employees install no environment and obtain no keys. The workbench guides them through a workspace request, and they enter the project once an administrator approves it.

Request a workspace, an administrator approves it
Projects, running workspaces and remaining quota on one screen
Switch to the expert view when finer control is needed

Workspace

Keep project files and context in one workspace

The workspace is the project's own environment. Files, context, tools and execution records live inside it, and a colleague can be added to the same workspace and continue.

Each workspace is a bot dedicated to a single project: it holds that project's files and history, it runs whatever capabilities are installed into it, and anyone on the team can assign it work. A bot in this sense is not a chat window that discards the context; it retains the project across sessions and across the people working on it.

A standard environment that does not depend on one person's laptop
Project files, context and execution records kept together
Several people in one workspace for collaboration and handover

Workspace interface with sessions, messages, apps and the capability market on the left and the current project on the right — The workspace carries its own sessions, messages, apps and capabilities; project files and history stay inside it.

Runtime

A workspace is an actual machine, not a chat window

Each workspace corresponds to actual vCPU, memory and disk quotas running on your own hosts. Administrators can see what was allocated and what is in use, and can expose a service running inside a workspace by port.

vCPU, memory and disk allocated per workspace, with live usage on one screen
HTTP services inside a workspace can be opened by port; public access needs review
Existing servers can be attached and managed in the same resource view

Workspace instance page showing scheduling status and allocated versus actual CPU, memory and disk usage (demo figures) — Allocated, running quota and actual use side by side, making resource consumption visible.

Discover

Approved models and agents stay inside the project

Employees see only the capabilities connected by the company and allowed for the current project. They can switch models or agents without moving project files elsewhere. CLI agents such as Claude Code, Codex and Cursor are connected centrally, and the project context is retained through the switch.

The company connects models and agents once, not per employee
Availability follows role and project
Project context is kept when switching

Capability panel inside a workspace showing installed capabilities and what else can be installed, grouped by development, docs, design, productivity, AI teams and marketing — Capabilities are installed into the workspace, so people can see what is on and what else is available.

AI quota

Give every unit of AI usage an owner

Quota is assigned by user and plan. Employees see what remains, while administrators can review usage by workspace, project, runtime and model.

Set limits in advance rather than discovering spend later
Usage by person, workspace, project, runtime and model
Cost attributable to a project for internal allocation

AI quota panel showing the current plan, remaining quota, carried-over allowance and cumulative use (demo tenant) — Employees can see the remaining quota and the rate of consumption, and request more without leaving the product.

Agent market

Agents are listed as sealed packages, not circulated as files

An agent is built once, sealed, and published to the platform. Which workspaces may install it, and which version they get, is decided centrally rather than by whoever happens to hold the file.

Signed on upload

Each package carries its own signature

Agents are uploaded as sealed packages and the platform verifies the signature on entry. An unsealed archive may also be uploaded, but it is marked unverified and is not treated as a release.

Version and engine

Compatibility is read from the package

The name, the version and the engine an agent requires are read from the package itself rather than from a submitted form, which rules out a mismatch between the two. A workspace is offered only the releases it can run.

Publish and withdraw

Withdrawing a release leaves existing installations intact

Publishing makes a release visible to the workspaces that qualify. Withdrawing it hides the release from new installations, while workspaces that already have it continue to run.

Agent market console: published agents on the left, and for the selected agent every release with its required engine range, package size and listing state — Several releases of one agent stay listed at once. Each declares the engine range it needs, and a workspace is shown only the release it can run.

Agents are reviewed before listing, not uploaded at will. The platform administrator decides what reaches the market and what remains listed; a workspace installs what has been released to it. During a pilot we go through packaging, signing and version policy with the people who will maintain your agents.

Admin console

Daily administration in one console

Administrators handle workspace resources, member access, model providers, approval requests and login records here.

Access control and roles decide who may use what
Model providers and keys held centrally rather than dispersed
Approvals, login logs and scheduled jobs in one place

EachRun administrator console overview with workspaces, agents, model access and tasks — Admin console: workspace resources, capabilities and models, tenants, projects and access.

On top of the core

Staff unfamiliar with AI can still follow the process

The three things above decide whether you can open AI up at all. This layer decides whether people use it once you have: select a workflow and follow it, or bring in an AI team already divided by role. It is not required, but it governs how quickly AI spreads inside the company.

Workflows

Select a workflow and follow it

A workflow breaks the job into steps, and each step carries the skills that step needs. Starting one creates a visual workflow: nodes advance in order and the output is filed back to the project.

Every step states what it does and which skills it uses
Output is attached to the project instead of filed by hand
Switch to the expert view when direct control is needed

A five-step workflow for running a cross-border storefront, with the skills listed under each step — From requirements to the pre-launch check: five steps, each with its skills attached.

AI teams

Bring in a team of agents split by role

The capability market holds AI teams packaged by function, covering academic research, design, engineering, finance, healthcare and marketing. Each team is divided by role and carries the skills that kind of work requires.

Divided by role, rather than one assistant expected to do everything
A team carries anywhere from a few to dozens of skills, ready to install
Teams and skills are maintained and distributed by the company

Detail view of the engineering AI team: 58 skills, each role listed with its own responsibilities — Fifty-eight roles inside one engineering team, each with its own identity, remit and workflow.

Carried forward

Long-running tasks need no supervision

On tasks with many steps, a supervising agent tracks progress and determines what happens next from the result of each step, with no one required to confirm each stage.

On a schedule

Runs at the time you set

A proven workflow can be set to run on a schedule and file its results back to the project. Recurring work such as a daily search of tender notices no longer requires anyone assigned to it.

Reaching your systems

Give AI access to business data

External services connect over MCP, allowing an agent to read and write a database or a line-of-business system for actual work on orders or stock. What connects, and how far it may reach, is settled system by system during the pilot.

Current product scope

What works now, and what needs pilot confirmation

Ready-to-use functions are listed separately from items that need on-site confirmation, so the implementation effort can be estimated.

Available now

Day-to-day platform management

Members, departments, roles and login audit
Workspace requests, approval, instances and resources
Model providers, channels and connection tests
Quota plans, user quotas and usage windows
Project, workspace, file and session sharing
AI conversations, run status, tokens and user feedback

Configuration-dependent

Runtime controls

Read-only and project-write sandbox boundaries
User approval before tool and command execution
Viewer, editor and administrator project roles
Time-limited sharing and centralized revocation

Permission prompts differ by agent and are configured for the deployment in use.

Confirmed in pilot

External systems and environments

Specific models, agents and CLI integrations
CRM, ERP, ticketing and internal APIs
Private repositories, file systems and knowledge bases
Private deployment retention and network boundaries

Technical access is not the same as a stable interface or commercial permission. Each item is checked before delivery.

What to know before you rely on it

Approval before a tool or command runs is available only for agents that support it.
Connections to business systems, internal APIs, repositories and knowledge bases are confirmed task by task during a pilot; they are not ready-made integrations.
The agent market is curated and published by the platform administrator, and a workspace only sees releases it can actually run.

See it run on your own task

Tell us what your team uses today and which data it touches, and we will walk the matching screens through one real task.