NAVER says about 100 Rookie service robots move through its 1784 headquarters and deliver café orders, parcels, lunches and other items. The fleet works because ARC, the robots, a robot-only elevator and the building's order and notification systems exchange operational state; no single component explains the service on its own.
The strongest public evidence is NAVER's report of more than 60,000 deliveries during 1,000 days of operation. That is meaningful long-run evidence, but it is a company-reported cumulative count, not a disclosed success rate. The live Tokyo Midtown Yaesu deployment must also be kept separate from NAVER's plan to expand delivery to every floor by the end of 2026.
A fleet of 100 needs a building-level control loop
NAVER's official robotics overview says roughly 100 robots at 1784 are controlled through the cloud and provide multiple services. Rookie is the mobile service robot. ARC brain handles planning and processing for motion, localization and tasks, while ARC eye combines digital-twin data with localization AI. ARC mind is the web-based robot service operating layer. These names describe related parts, not interchangeable labels for one product.
Local obstacle avoidance still matters, but a busy building adds a second problem: assigning orders across the fleet while accounting for route cost, congestion, battery and service priority. Our multi-robot task-allocation guide explains that scheduling layer. At 1784, the decision must also coordinate elevators, service points and recipient notifications, so a robot's shortest path is not always the system's best assignment.
| Component | Operational role at 1784 | What it is not |
|---|---|---|
| Rookie | Carries orders through the building | The complete ARC platform |
| ARC brain | Plans and processes movement, localization and tasks | A robot body or elevator |
| ARC eye | Estimates position from digital-twin data and localization AI | A single onboard camera |
| ARC mind | Provides a web-based robot service OS | Only a low-level motor controller |
| Roboport | Moves robots between floors | Another name for ARC |
An order passes through robots, software and physical infrastructure
The official 1784 service page lists Rookie, Roboport, the ARC System and the workplace assistant as distinct elements. An employee request supplies the item and destination; the service layer turns it into a task; ARC selects and routes a robot; building interfaces make vertical movement possible; and the recipient receives a notification. The useful unit of analysis is therefore an end-to-end delivery, not an isolated navigation demo.
Roboport is especially important because a conventional passenger elevator can become a shared bottleneck. A fleet may need reservations, entry confirmation, floor calls, fallback behavior and recovery when an elevator is unavailable. The distinction between guided vehicles and autonomous mobile robots is covered in our AMR versus AGV selection guide, but autonomy alone does not provide building integration or guarantee throughput.
| Delivery stage | System involved | Evidence an operator should record |
|---|---|---|
| Order intake | Workplace app and service backend | Rejected, cancelled and duplicated orders |
| Assignment | ARC and fleet scheduler | Queue time, battery margin and reassignment |
| Travel | Rookie and localization stack | Stops, detours and human interventions |
| Floor change | Roboport and building control | Wait time and failed boardings |
| Handover | Notification and user interface | Completion, timeout and redelivery |
What more than 60,000 deliveries actually establish
In its 1,000-day account of 1784, NAVER says around 100 robots navigate the building each day and completed more than 60,000 deliveries, including convenience-store goods, café orders, parcels, lunchboxes and personal-item exchanges. This is stronger evidence than a trade-show clip because it describes repeated use across multiple everyday services over a long period.
The count does not disclose the denominator. NAVER does not provide, on that page, total requests, failed attempts, median delivery time, recovery time or the share of trips requiring staff assistance. A buyer should request those figures and definitions before using 60,000 as a reliability benchmark. It is also a NAVER-reported result rather than an independently audited fleet-performance study, so attribution should stay visible.
The digital twin is an operating reference, not just a map
ARC eye uses digital-twin data as part of localization, and NAVER's Japan account says the deployment began by creating a digital twin of the building and defining robot routes and service points. ARC then connects service systems, building infrastructure and operational control. That makes the twin a shared spatial reference for configuring and operating services, not merely a 3D illustration shown during a sales presentation.
A digital twin should still be distinguished from testing the controls before deployment. Our virtual commissioning versus digital twin guide treats the twin as the representation and data connection, while virtual commissioning exercises control logic and failure cases. Elevator contention, a closed corridor, stale localization, lost wireless coverage and delayed handover should be tested because each can break an otherwise valid route.
Tokyo Midtown Yaesu is a deployment, while all-floor service is a target
NAVER's July 23, 2026 Japan deployment update says ARC has been deployed at Tokyo Midtown Yaesu. The company describes adapting elevator use, routes, ordering and notifications to the existing commercial building rather than relying on infrastructure designed from the start for robots. That makes the site a useful reference for portability beyond NAVER's own headquarters.
The same update says NAVER LABS plans to expand from the services in Yaesu Tower to robot deliveries on all floors by the end of the year. As of the August 7, 2026 check date, that wording is a plan, not proof that the expansion is complete. The present evidence is a real deployment at the building; fleet size, floor coverage and completion of the year-end expansion require a later official update.
What another building should validate before copying the design
Start with interfaces rather than a robot count. Document elevator APIs, doors and access gates, wireless dead zones, fire and evacuation rules, service endpoints, user authentication, charging locations and who owns recovery. If multiple robot vendors are involved, define a common task and status contract and decide where maps, permissions and traffic priorities are authoritative. A fleet cannot be operated safely from a slide showing cloud connectivity alone.
Acceptance testing should include ordinary deliveries and awkward cases: an elevator outage, a changed destination, an uncollected item, a blocked corridor, a network interruption and low battery during a priority task. NAVER 1784 demonstrates that ARC, Rookie, Roboport and building services can support sustained use in one integrated environment. It does not guarantee the same capacity or service level in a different building without site-specific mapping, infrastructure work and operating evidence.
Frequently asked questions
Are all 100 robots delivering at the same time?
NAVER says around 100 robots navigate the building each day, but it does not publish simultaneous active-fleet counts or utilization by hour on the cited page. Those figures need separate operational data.
Are ARC and Roboport the same system?
No. ARC is the cloud-based multi-robot platform connecting robots, space, services and operations. Roboport is the robot-only elevator that supports movement between floors.
Is robot delivery already available on every floor at Tokyo Midtown Yaesu?
The July 2026 official update confirms an ARC deployment, but describes all-floor robot delivery as a plan for the end of 2026. Completion needs a later official confirmation.
Official sources checked
2026-08-07