We wanted to see how far an AI agent could get at planning real datacenter work for a robot. Not the usual "robots run 24/7 and do five days of work in two" pitch, but a robot that quietly takes the rote, repetitive jobs off people's plates so the experts running the floor can spend their attention where it actually matters.
This repo is the knowledge layer for that. It's a set of agent skills and references an assistant uses to reason about physical datacenter work and the Enactic OpenArm robot. The idea is simple: someone brings the tasks they need done, and the assistant works out whether OpenArm can do them and produces the right grounded output, the same way it did for the three tasks in the demo below.
In practice, an operator brings a work order ("reseat the failed drive in R14," "thermal-scan row 3," "patch this new run") and asks the assistant. It checks whether OpenArm can do the job, asks any site-specific questions it needs, and produces a task plan, SOP run, or inspection assessment. The robot takes the rote work; the expert's attention goes where it matters.
Reference embodiment: OpenArm (open-source 7-DOF, highly backdrivable, bimanual arms on a stationary pedestal).
The scarce thing in a datacenter isn't manpower; it's the instinct that only comes from years on the floor. Most robotics work treats a robot as a productivity amplifier (24/7 uptime, five days of work done in two). We were after something else: using AI to rethink how people work, so a shrinking pool of experts can keep up with the growing demands of future infrastructure.
The video shows three kinds of outputs this skill stack can produce:
- Task plan: connect and route RJ45 patch cables at the panel, with feasibility, arm assignments, force limits, verification, and abort handling.
- SOP run: clear a technician's leftover test cables and reconcile the rack to a documented baseline, with fixed-order steps and an audit trail.
- Inspection assessment: thermal-scan the switches, classify readings against operator-defined context, and route real or uncertain findings to the right expert.
This repo is the planning layer behind that video. The demo tasks are captured in DEMO.md, but they are examples of the stack rather than the stack's scope. You can point the same skills at your own, more varied tasks. Worked, end-to-end outputs for each deliverable mode live in examples/.
We didn't want the assistant to be a script library with one entry per task. It's general knowledge + a per-site configuration + the judgment to ask about the rest.
GENERAL KNOWLEDGE SITE CONFIGURATION LIVE CLARIFICATION
(true in every datacenter, (true for ONE datacenter, (true for THIS task,
for every OpenArm) set once by the operator) asked at planning time)
┌──────────────────────────┐ ┌───────────────────────────┐ ┌───────────────────────────────┐
│ openarm-embodiment │ │ site-profile/ │ │ datacenter-task-planner asks: │
│ what the robot can do │ + │ this site's racks, │ + │ "which rack? is it │
│ datacenter-operations │ │ equipment, tools, │ │ powered? which bay? │
│ racks, gear, tools, │ │ conventions, policies, │ │ ESD provided?" │
│ activities, constraints │ │ what's non-standard │ │ when neither layer │
└──────────────────────────┘ └───────────────────────────┘ │ answers it │
└───────────────────────────────┘
- Don't hard-code one datacenter's reality into the skills. Standard facts (a rack unit is 44.45 mm, a hot-swap drive blind-mates) are general and live in skills. Your rack widths, your non-standard cabinets, your ESD rules, your naming scheme are site facts; they go in a
site-profile, not in the skills. - Don't dictate every task. Common task families have reusable patterns (parameterized templates), but the assistant composes a plan from general method + the site profile + answers to its own questions, rather than replaying a fixed script.
- Make "ask the right question" a feature. The planner knows which facts are commonly site-specific and, when the profile doesn't supply them, asks the operator instead of guessing.
| Decision | Choice | Implication |
|---|---|---|
| Base / mobility | Positioned, then manipulate | Base placement (which rack, what height) is a precondition, not a planned step. Skills model bimanual manipulation within one ~0.5 m workspace. A task spanning widely separated U implies re-positioning → declared, not planned. |
| Primary output | Grounded robot work output | Judge reach / force / dexterity / bimanual / constraints, then emit the appropriate task plan, SOP run, or inspection assessment. |
| Grounding | Knowledge-first | Structured knowledge + plans. References the real stack (dora-openarm, joint limits, MuJoCo scenes) but does not generate motion code yet. |
| Kind | Skill | Role |
|---|---|---|
| Embodiment | openarm-embodiment |
What OpenArm physically is and its hard limits. The single source of truth for "can the hardware do X." |
| Domain | datacenter-operations |
The datacenter: racks, equipment, tools/instruments the robot wields, the activity taxonomy (commissioning / operations / maintenance / inspection / decommissioning), objects & interfaces, constraints, and a task ontology. |
| Deployment | site-profile |
How to capture one datacenter's specifics (rack inventory, widths, equipment, tools on the robot, per-rack baseline, judgment context, conventions, policies, non-standard gear). Schema + example, selected by the DC_SITE_PROFILE env var. |
| Method: task plan | datacenter-task-planner |
Turns a one-off task into feasibility + plan. Reads the knowledge skills and the active site profile, runs the feasibility rubric, and asks the operator for anything unknown (clarification protocol). |
| Method: SOP run | sop-execution |
Runs a repeatable procedure consistently and reconciles a rack to a known baseline (complete/ordered/verified steps, audit trail). Composes datacenter-task-planner for the physical steps. |
| Method: assessment | inspection-judgment |
Turns an inspection into a real-vs-spurious assessment + escalation against operator-defined context, guiding expert attention, not just reporting a number. |
| Pattern library | task-patterns |
Reusable, parameterized templates for task families (SOP cleanup, thermal triage, module swap, connector mate, cable route…). A cookbook the method layer adapts, not an exhaustive one-skill-per-task list. |
The method skills produce three kinds of user-facing outputs:
| Mode | Example task | Output | Owned by |
|---|---|---|---|
| Task plan | cabling | feasibility + manipulation plan | datacenter-task-planner |
| SOP run | cable cleanup & rack reconciliation | verified procedure run + known state + audit | sop-execution |
| Inspection assessment | thermal switch triage | real/spurious/uncertain assessment + routed attention | inspection-judgment |
Operator: "How should the robot reseat the failed drive in R14?"
-> datacenter-task-planner
reads openarm-embodiment (reach/grip/force within limits?)
reads datacenter-operations(drive caddy interface, ESD, blast radius; activity = maintenance)
reads site-profile (active) (R14's rack type & width? robot's gripper/tools? site ESD policy?)
-- still unknown? ASK: "Is R14 a standard 19in cabinet? Is the drive in a redundant set?"
(if a task-pattern fits, adapt it)
-> FEASIBILITY: feasible / conditional / infeasible, with reasons tied to real limits
-> PLAN: ordered primitives, arm assignment, grasps, force caps, verification, abort handling
datacenter-robot-skills/
├── README.md # this file
├── AUTHORING.md # conventions: where each fact belongs, how to add patterns/profiles
├── DEMO.md # the demo scenario and output modes
├── examples/ # worked end-to-end outputs (proof + onboarding)
└── skills/
├── openarm-embodiment/ # general robot knowledge
├── datacenter-operations/ # general datacenter knowledge (incl. activities & tools)
├── site-profile/ # per-deployment configuration + example profile
├── datacenter-task-planner/ # method: feasibility + plan + clarification protocol
├── sop-execution/ # method: run an SOP, reconcile to baseline
├── inspection-judgment/ # method: sense -> judge -> route attention
└── task-patterns/ # optional reusable task-family templates
Each skill is an Agent Skill: a SKILL.md (YAML name + description, then instructions) plus optional reference/ files loaded on demand.
We keep one worked example per deliverable mode in examples/, each a full end-to-end output (request → clarify → feasibility → deliverable → verification/escalation) grounded in the example-site profile. They show exactly what the assistant produces, and they double as onboarding.
Here's the goal we're working toward: hand the assistant the tasks a team needs done, and have it reason from these skills to the grounded outputs a demo like this needs, then generalize past these three to whatever a site actually throws at it.
Where it is today: the stack is modeled end to end across embodiment knowledge (openarm-embodiment), datacenter domain knowledge (datacenter-operations), deployment configuration (site-profile), method skills (datacenter-task-planner, sop-execution, inspection-judgment), and reusable task patterns. It has worked examples for a task plan, an SOP run, and an inspection assessment. It's knowledge-first for now: structured skills, plans, and worked outputs, not generated motion code yet. Operators add a profile for their site; pattern authors add families as they recur. See AUTHORING.md.
Embodiment facts are grounded in the sibling OpenArm repos (kinematics from openarm_mujoco v2 MJCF; safety clamps from openarm_teleop; control/dataflow from dora-openarm). Estimated values are marked approximate with their derivation, not invented.