Skip to main content
Olyros is a workspace where a company runs AI agents on its own terms: its own model keys, its own machines or a managed cloud, its own Slack, GitHub and Jira, and its own rules about who may talk to which agent. This page is the map. It names every object a user meets in the client app’s left sidebar, says how the objects relate, and points to the page that documents each one. The sidebar entry Main -> Dashboard (/dashboard) is the landing page: a snapshot of today’s interactions, tokens, cost, active agents and Slack users, the active sandboxes and running tasks, the execution environments that are online, and a usage chart for the last days (dashboardSnapshot, companyUsageStats, executionUsage, executionEnvironments). Everything it shows is explained on the pages below. New to Olyros? The numbered list under How to configure it is the order a new company follows, and Olyros for agents is the page to hand a coding agent.

​
What it does

The object model, from the outside in.
  1. A company is the tenant: every object below belongs to exactly one company, and a person reaches a company through a membership with a role (Viewer, Editor, Admin). Company settings, users and roles.
  2. Integrations connect the company to outside systems and hold the credentials: model providers (the keys every agent runs on), GitHub, Jira, Slack, remote MCP servers and custom HTTP APIs. Integrations and its per-kind pages.
  3. Agents are the assistants people talk to. Three kinds share one model: a chat agent (Agents), a persistent sandbox with its own working directory and repositories (Sandboxes), and a router, one Slack app that forwards each person to their agent (Routers). Agents draw on tools, MCP servers, skills and memory, each with a sidebar entry in the Agents group.
  4. Automation makes agents work without a person typing: workflows react to Jira, GitHub, webhook and agent events (Workflows); schedules fire on a cadence (Schedules); both, and people, create cloud tasks, one-shot units of work with an executor and a result (Cloud tasks and executors). Tickets and incoming issues are the GitHub- and Jira-facing views of that work.
  5. Execution decides where and in what a task or sandbox runs: an OHO (Olyros Home Orchestrator) machine the company connects, the Olyros Cloud pool, or the company’s own GCP project, and a runtime image with env vars and secrets (OHO machines and environments). Executors describe how the model loop runs; System Activity is the work-item queue that carries every task.
  6. Billing and usage meter all of the above: a plan, a credit wallet, usage breakdowns and cost tags (Billing and usage).
How the objects relate. An agent runs on a provider integration’s key. A sandbox is an agent plus a venue (an OHO or a cloud backend) plus a runtime image. A router has routes to agents and sandboxes and no model of its own. A workflow’s trigger comes from an integration’s events and its AI node creates a cloud task for an agent; a schedule creates a task, an issue, a work item or a workflow run. A task is placed on a backend (the agent’s pin, else the company default, else any backend) and runs inside a runtime image through an executor. Every LLM call is charged to the company’s own provider key and recorded against the agent, workflow, Slack user and cost tags for the Usage page. Access in one paragraph. Two mechanisms. Class-scoped abilities go by role: Viewer reads, Editor manages agents, workflows, integrations, environments and tools, Admin additionally manages users, skills, MCP servers, OHO hosts, Slack, billing and the company; the full table is on Company settings and in the product under Settings -> Roles. Object-scoped abilities (agent.chat, workflow.view, workflow.execute) are decided per agent or workflow by its Access tab: no grant means open to every member, any grant restricts it to the listed Olyros users, Slack users and Slack groups, and roles do not bypass it. Sidebar map. Every entry, the page that documents it, and the one-line reason when a group is not documented. Two sidebar labels do not match the model behind them: Environments (/execution) is the execution backends gallery, and Runtime Images (/environments) is the Environment model. OHO machines and environments explains both.

​
Who can use it

Any company member sees the Dashboard and every list page. What a member may change is the role and ability question answered on Company settings; each page’s “Who can use it” section names the role for every action in its area. There is no per-feature plan gating: plans limit counts (agents, seats, OHO attach) through the structural billing gate, described on Billing and usage.

​
How to configure it

The order a new company usually follows. Each step links to the page with the detail.
  1. Create the company and invite people with a role: Company settings.
  2. Add a model provider integration with the company’s own API key, since every agent runs on it: Generic and provider integrations.
  3. Create an agent, give it a prompt and knowledge, and set who may chat with it on its Access tab: Agents.
  4. Connect Slack and give the agent its own Slack app, or create a router so one Slack app serves many agents: Slack, Routers.
  5. Decide where work runs: connect an OHO machine, enable Olyros Cloud, or connect your own GCP project, then set the company default backend: OHO machines and environments.
  6. Create a sandbox when an agent needs a persistent working directory and repositories: Sandboxes; install the GitHub App first for repository access: GitHub.
  7. Automate: connect Jira or GitHub events to a workflow, or add a schedule: Workflows, Schedules, Jira.
  8. Extend agents with company tools, MCP servers and skills: Agents, MCP servers, Skills.
  9. Connect a coding agent (optional): a member creates a scoped, expiring connection under Settings -> Agent access and points Claude Code or another MCP client at it: Agent access, Olyros for agents.
  10. Watch cost: tag agents and workflows, read the Usage page, keep the wallet funded: Billing and usage.

​
Limits and defaults

Every page carries its own table. The limits a user meets first:

​
What it emits

Each area leaves its own records: conversations and memories (agents), workflow executions and node executions (workflows), cloud tasks, work items and tickets (tasks), route and binding rows (routers), usage and wallet ledger rows (billing), audit events for the security-relevant settings changes (company settings, skills, access). The Dashboard and the Usage page read those records; nothing on this page writes anything.

​
Known gaps

  • Cross-domain how-to recipes (for example “a Slack agent that runs a skill on an OHO”) are not written yet; each page documents its own area and this page only orders the steps.
  • Pages describe the client app; the admin app is mentioned only where it is a prerequisite (plans, backend entitlements, platform settings).
  • The Content sidebar group has no page by decision; it still appears in the product.

​
Customer-safe summary

Olyros lets a company run AI agents on its own model keys and talk to them from Slack and the web. Agents can have persistent sandboxes with the company’s repositories and be automated with workflows and schedules driven by Jira and GitHub. The company chooses where work runs, on its own machines, on managed cloud, or in its own Google Cloud project, and decides per agent and per workflow who may use it. Usage and cost are visible per agent, workflow, person and tag, and billing runs on a plan plus a prepaid credit wallet.