PitCrew

Inspiration

Data centers already have tools that show when something is wrong. The harder question is what happens next: who investigates, who goes to the equipment, and what information reaches them?

We built PitCrew around that gap. A technician should arrive with useful evidence and the right tools. When responsibility changes, the next person should know what has already been tried. This became our approach to NMC²’s challenge of helping data center teams stay ahead of disruptions.

What it does

PitCrew gives each data center sector an agent team that monitors simulated conditions, investigates developing issues, and prepares work for technicians.

Tickets include a working diagnosis, supporting evidence, unresolved questions, and physical checks. Assignment considers sector coverage, qualifications, equipment, access, availability, and checked-in location.

Technicians can record findings and escalate a case with their completed work intact. A shift brief summarizes active work and blocked plans, while preventive planning checks upcoming inspections and retirement prerequisites before creating assignments. Issues that can be handled digitally can stay with the agents without generating a field visit.

How we built it

We built a responsive application with Next.js, React, and TypeScript, backed by server-side workflows and shared Zod contracts.

Each sector has three roles. A deterministic sentinel detects relevant changes. A Nemotron investigator retrieves telemetry, maintenance plans, and shared memory to prepare a case. A Nemotron dispatcher reads that case and the eligible roster before proposing an assignment.

We connected NVIDIA Nemotron through the AI SDK and an OpenAI-compatible endpoint. The models execute real tools, while the backend enforces qualifications, approved inspection steps, and maintenance windows. Agent activity and technician findings feed the same case history.

The demonstration uses synthetic facility data and in-memory state. Desktop and phone views share the running backend through ngrok.

Challenges we ran into

One challenge was deciding when an issue actually needed a person. Creating a ticket for every unusual reading would add work instead of reducing it.

We also had to separate model judgment from operational rules. An agent can interpret evidence, but it should not bypass access requirements, assign an unqualified technician, or invent an equipment procedure.

Handoffs introduced another challenge: preserving completed checks and observations without implying that finishing a checklist means the equipment has recovered. We kept work completion separate from continued monitoring.

Accomplishments that we're proud of

Verified real Nemotron tool calls across investigation, shared memory, and dispatch.
Completed a phone workflow where a technician recorded a finding and escalated it without losing that work.
Added preventive planning that keeps blocked and future-window work out of the active queue.
Made agent decisions inspectable through their tool inputs and results.
Built a demonstration that shows a response process, rather than stopping at a dashboard.

What we learned

The most useful AI output is often a better-prepared job, not another summary.

Location helps with dispatch, but the nearest person is not always the right person. Qualifications, equipment, access, and current responsibilities still matter.

We also learned that shared memory needs to contain concrete evidence: what was observed, who performed a check, what remains uncertain, and what the next responder should do. That makes it useful to both agents and people.

What's next for hacking

Our next step is to test the workflow with data center technicians and refine it around their existing procedures.

We would connect PitCrew to monitoring and ticketing systems, add durable storage and authenticated roles, and expand the scheduling model for real shifts and maintenance plans.

We would also measure whether prepared assignments and preserved handoffs reduce repeated checks, unnecessary visits, and response delays. Those are outcomes we want to validate, rather than assume from a simulation.