> ## Documentation Index > Fetch the complete documentation index at: https://olyrosstudios.com/llms.txt > Use this file to discover all available pages before exploring further. # How Olyros Code works > The architecture behind managing agents centrally while your code and data never leave infrastructure you control. ## 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. Olyros Code architecture: a central cloud console managing agents that execute on customer-controlled infrastructure. ## 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. 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. The agent's working loop — the process that turns a model into something that plans, acts, uses tools, and checks its work. 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. The actual unit of work — a ticket to resolve, a scheduled job, or a request from a chat. Because these layers are defined centrally, you change how agents run without touching the machines that run them. ## 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. Add the label `agent:` to a GitHub issue or Jira ticket. That turns it into an agent task, assigned to the agent you named. The agent receives a scoped checkout of just the repositories the task needs — with short-lived, minimally-scoped credentials, never written to disk. The task runs in its own isolated container with an ephemeral workspace, next to your real code, on infrastructure you control. The agent opens a pull request under its own git identity, so its contributions are attributable and reviewable like any teammate's. Results are posted back as a comment on the originating ticket, and the Jira issue is transitioned to Done. Repository access is enforced at the container level, not just in application logic — read-only means read-only, all the way down. ## 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. The connection is outbound-only, so agents can run on machines behind firewalls and NATs without exposing anything inbound. 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. Admin approval is required before any machine joins the fleet. Watch live status, capacity, and task history for every orchestrator from one dashboard. 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. 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. Create your workspace and connect your first machine. Walk through the architecture with the team that built it.