---
id: "lib-2026-10-30-yoro-layerx-s-second-remote-coding-agent"
type: "library"
title: "yoro, LayerX's second remote coding-agent environment"
title_original: "yoroによろしくぅ！Ai Workforce 事業部のリモートコーディングエージェント環境 yoro のご紹介"
lang: "JA"
org: "LayerX (Zenn)"
source_type: "Practitioner post"
date: "2026-10-30"
week: "2026-W44"
url: "https://nosov.ai/library/lib-2026-10-30-yoro-layerx-s-second-remote-coding-agent/"
original_url: "https://zenn.dev/layerx/articles/a277f83a93d300"
tier: "B"
tier_name: "Useful, limited"
tier_reason: "LayerX SRE describes an in-house remote coding-agent platform with detailed isolation and monitoring design and a month of usage counts; specific and candid about open gaps, but usage figures are self-reported with no quality or cost data."
summary_basis: "full-text"
original_minutes: "12"
tags: ["ai technology", "background agents", "agent isolation", "observability"]
---

# yoro, LayerX's second remote coding-agent environment

Original title: yoroによろしくぅ！Ai Workforce 事業部のリモートコーディングエージェント環境 yoro のご紹介

Tier B (Useful, limited): LayerX SRE describes an in-house remote coding-agent platform with detailed isolation and monitoring design and a month of usage counts; specific and candid about open gaps, but usage figures are self-reported with no quality or cost data.

Summary based on the full text.

## In short

A Zenn post from LayerX (30 October 2026) by an SRE in the company's Ai Workforce division, presenting yoro, a remote coding-agent environment. It is the second such platform inside LayerX, after another division's background agent. Each person gets a Coder workspace on AKS where Claude Code or Codex runs without permission prompts, picks up work from Slack, local agents, GitHub or the division's own task product, and returns plans, PRs and reviews. Because agents run unattended, the team built its own isolation and monitoring to fit a division that handles customer confidential data. Usage grew sevenfold in four weeks, mostly from automatic PR reviews.

## Key numbers

- 656: requests to the platform from 25 September to 24 October 2026
- 55 to 387: weekly requests, week of 28 September versus week of 19 October
- 400 / 202 / 43: automatic PR reviews / requests from terminals and the admin UI / Slack-emoji requests in that period
- about 3x: the team manager's PRs in his first three weeks on the platform versus the three weeks before
- 6: entry points: internal task product, Slack, local terminal, preview-environment UI, schedule, GitHub review requests

## What it reports

- Origin: the team manager brought Coder back from KubeCon Japan 2026. Workspaces are Kubernetes pods defined by Terraform templates and custom resources applied by Argo CD; they stop when idle and keep a persistent home directory.
- Flow: the preview-environment admin UI receives every request; a resident process in the workspace creates a git worktree per request, starts the chosen agent, and reports back to the source at milestones.
- The internal task product's "hand to yoro" button sends task text to the person's workspace and receives status and PR back; this link exists only in the internal deployment, not the customer product.
- Isolation: each workspace runs in a Kata Containers lightweight VM and cannot start otherwise; Cilium denies all unapproved traffic and egress goes only to Azure Firewall allow-listed hosts; each person gets their own LLM gateway key, not a shared credential.
- Monitoring inside the VM: Claude Code's OpenTelemetry events record which tool was used for which request and when; prompt text and command strings are stripped so the log does not become a store of secrets. Codex is logged only from outside.
- Outside the VM, which agents cannot disable with sudo: a custom host-kernel eBPF probe catches files executed in the workspace through a virtiofsd flag, plus outbound traffic volume. All logs, request records and AKS audit logs sit in self-hosted ClickHouse, so one SQL query traces a request to executed files and network traffic.
- Compared with Cursor's Cloud Agent and Devin: those keep the agent loop in the vendor's cloud and send code and command output there; with yoro only the model API sees it, and integrations are under the team's control. The cost is running it themselves.
- Automatic review: one AI review per PR across all reviewers' workspaces, re-reviewing only new pushes; results go to Slack with an Approve button once clean; humans approve and merge.
- Open problems: from outside the VM, command arguments are invisible (the AKS VM kernel lacks kprobes and BTF), so a curl run is seen but not its URL; allowed destinations such as GitHub and LLM APIs can still carry data out, and agents reading Slack threads or others' PRs may follow injected instructions. The most sensitive customer work is not yet given to yoro.

## How they got it

The builder's description of the system, with request counts from its own logs and the manager's PR count before and after. No figures on PR quality, defects or cost.

## Limits

- Throughput only; growth is mostly automatic reviews, not authored changes.
- The manager's 3x PR figure is one person over three weeks, and he reports he cannot keep up with reviewing them.
- Security gaps listed by the author remain open.

## Why it matters for companies

Running agents without permission prompts is becoming normal for background work, and this is one of the more complete public designs for doing it on company infrastructure: VM-level isolation, deny-by-default egress, per-person keys, and logs the agent cannot switch off. The candid gaps are just as useful: allow-listed destinations are exfiltration paths, and prompt injection through Slack or PRs is unsolved, which is why the most sensitive work stays out. Teams choosing between vendor cloud agents and self-hosting should weigh where code and command output travel against the cost of operating the platform.

## Key passages in translation

> 許可を待たずに動かすぶん、お客様の機密情報を扱う事業部に合わせて、隔離と監視を自分たちで作り込みました。

Because it runs without waiting for permission, we built our own isolation and monitoring to suit a division that handles customer confidential information.

> VM の中の記録は、エージェントや人が sudo で止められます。そこで、VM の外にあるノードのホストからも記録しています。

Logging inside the VM can be stopped by the agent or a person with sudo, so we also log from the node host outside the VM.

> お客様の機密情報のように機密度がいちばん高い情報を扱う作業は、まだ yoro に任せていません。

We do not yet give yoro work that handles the most sensitive information, such as customer confidential data.

Original: https://zenn.dev/layerx/articles/a277f83a93d300