The architecture in one idea
You manage everything from a central cloud console: agents, their models and knowledge, the tasks they run, and the fleet of machines that execute them. But the work itself happens on infrastructure you control. That control plane never becomes the place your code and data live. Execution runs either on your own hardware — a laptop, a build server, or a machine inside your VPN — through the orchestrator, OHO (Olyros Host Orchestrator), or in your own cloud account. Google Cloud and AWS are available today, with Azure coming soon. The result: agents operate in isolated containers right next to your real repositories and data, while you keep one console for management, monitoring, and cost.
Manage centrally in the cloud; execute on infrastructure you control.
The execution stack, plainly
Every task an agent runs is assembled from four conceptual layers. Understanding them is the fastest way to understand the whole product.Environment
The isolated container the work happens in. Use a sensible default, or bring your own Dockerfile so agents run with your team’s exact toolchain, libraries, and versions.
Executor
The agent’s working loop — the process that turns a model into something that plans, acts, uses tools, and checks its work.
Agent
The model, persona, knowledge, and tools. This is what you configure in the agent builder: system prompt, model choice, indexed knowledge with citations, memory, and tools with per-tool approval gates.
Task
The actual unit of work — a ticket to resolve, a scheduled job, or a request from a chat.
The ticket-to-PR loop
The clearest way to see the stack in motion is the workflow your engineers already use. An agent picks up a ticket, does the work, and opens a pull request your team reviews like anyone else’s.1
Label the ticket
Add the label
agent:<name> to a GitHub issue or Jira ticket. That turns it into an agent task, assigned to the agent you named.2
Scoped checkout
The agent receives a scoped checkout of just the repositories the task needs — with short-lived, minimally-scoped credentials, never written to disk.
3
Work in an isolated container
The task runs in its own isolated container with an ephemeral workspace, next to your real code, on infrastructure you control.
4
Open a pull request
The agent opens a pull request under its own git identity, so its contributions are attributable and reviewable like any teammate’s.
5
Post results and transition
Results are posted back as a comment on the originating ticket, and the Jira issue is transitioned to Done.
Built for networks that don’t open ports
The orchestrator connects the same way self-hosted CI runners do: it dials out. There are no inbound ports to open and no network reconfiguration to negotiate with your security team.Outbound-only
The connection is outbound-only, so agents can run on machines behind firewalls and NATs without exposing anything inbound.
Offline-resilient
Work continues even without connectivity. Results queue locally and sync automatically when the connection returns.
Fleet management
Machines don’t get work by simply showing up. An administrator approves each machine before it can join the fleet and receive tasks.Approve
Admin approval is required before any machine joins the fleet.
Monitor
Watch live status, capacity, and task history for every orchestrator from one dashboard.
Revoke
Remove a machine’s access instantly when it’s no longer trusted or needed.
Models: bring your own provider
Olyros Code is multi-provider by design, so you’re not locked to a single LLM vendor. Bring your own provider credentials and choose the right model per agent.Anthropic Claude
OpenAI
Google Gemini
AWS Bedrock
Azure
And more
Generic support for adding other models as your needs evolve.
See it on your own infrastructure
Get started in the console, or book a walkthrough and we’ll show you the ticket-to-PR loop running end to end.Get Started
Create your workspace and connect your first machine.
Book a Demo
Walk through the architecture with the team that built it.