The Capture Gap

What everyone is building

The current wave of enterprise AI is built on one assumption: the knowledge already exists somewhere, in documents, tickets, chat and email, and the job is to connect it and reason over it. Copilots search it. Connectors pipe it between systems. Agents act on it.

That assumption holds for office work, where the work and the record are the same thing. An email is both the act and its trace. It breaks for the large share of work done with hands, on sites, away from a screen. There, the work happens in one place and the record is written later, somewhere else, by memory.

Retrieval over a ticket that says “issue resolved” retrieves “issue resolved.” A better model does not fix a missing reading. The bottleneck is not reasoning. It is capture.

Where the knowledge actually lives

Watch a tower technician clear a VSWR alarm. In twenty minutes they learn that the connector took on water, that the last visit’s fix was tape over a cracked seal, that the reading dropped from 1.9 to 1.2 after the swap, and that sector C has the same jumper and will fail next. That is exactly the knowledge an operations team, a planning model or the next technician would want.

It exists for about as long as the technician is on the tower. By the time they are back in the van, it has become a few taps on a phone and a closure code. By the end of the shift, it has become nothing.

Technicians know this is broken and they resent it. In a 2025 Salesforce survey of 350 US tradespeople and technicians, respondents estimated that admin and information gathering took about 30% of their working hours, slightly more than the 28% spent actually delivering service. Telecom and utilities reported a worse balance than the average.¹ Those are self-reported estimates from a vendor survey, so we treat them as a signal, not a measurement. The pattern matches what anyone who has managed field crews will tell you.

So the people who generate the most valuable operational data are also the ones paying the highest price to record it, and getting the least back. That is the capture gap.

Why it can be closed now

Three things had to become cheap at the same time. They now have.

1. Capture at the point of work. Mainstream AI glasses with a camera, microphones and open-ear audio are sold in volume, and vendors have started opening them to third-party apps.² Where glasses don’t fit, a phone in a chest mount does the same job.
2. Understanding what was captured. Multimodal models can read a meter, recognise a connector, transcribe speech on a noisy site and turn it into structured fields. Two years ago this needed a custom model per task.
3. Writing back to the system of record. Field-service, maintenance and ticketing systems expose APIs, and protocols like the Model Context Protocol make connectors cheaper to build and reuse across customers.

None of these is new on its own. Together, they make it possible to write the record at the source, on every job, for less than the cost of the minutes it saves.

What IVA does

IVA sees the job through the technician’s glasses or phone, listens to what they say, matches it to the asset, fault codes and procedure the team already uses, and drafts the completed record in their system. If a reading or serial number is missing, it asks by voice before the technician leaves. The technician reviews the draft on site and signs. Only then is it submitted.

Three design choices follow from the thesis:

• The record is the product. The glasses are an input device. What the customer pays for is a complete, structured, signed record in the system they already run.
• A person signs every record. IVA drafts and asks; it does not submit. In operations, a wrong record is worse than a late one, and trust is earned one signed record at a time.
• Narrow beats general. A fault-code taxonomy for one kind of crew is more useful than a general memory of everything. We go deep in two verticals before going wide.

Why the advantage could compound

Every signed record is a labelled example: what was seen, what was done, and, when the same asset comes back, whether the fix held. That outcome-labelled record of physical work is data no office copilot ever sees, and it makes the next draft better for every crew on the same equipment.

Add the connectors into each vertical’s systems of record, built once and reused, and the cost of the next deployment falls while its quality rises.

We state this as a hypothesis. A moat described before customers exist is a story, and we would rather earn it than assert it.

What we got wrong before

The first version of AI Humane’s plan, published in July 2026, started with our own consumer smart glasses and ended with a reasoning layer for all human work. It was ambitious, and it was wrong in three ways.

• It put our capital into hardware, the part of the stack that large platforms are commoditising fastest.
• It asked consumers to change their behaviour before giving them a job that needed doing. Field crews already have that job.
• It made many claims and offered no receipts. The documents that change how capital flows tend to make one claim and back it with evidence.

This memo replaces that plan. The original is archived for the record.

Evidence, and what is missing

What we have today is an external signal (the survey above), direct experience selling software and robots into telecom and industrial operations, and a working reasoning engine. What we don’t have yet is our own measurement. Until we do, this memo stays a draft.

Every pilot measures the same four things against a baseline taken in its first two days. The thresholds below are what would convince us, proposed before any pilot has run so we can’t move them afterwards.

Measure	How it’s measured	Proposed threshold
Time from job complete to record submitted	System timestamps, baseline vs. pilot	Cut by at least half
Records complete on first submission	Records returned or called back by supervisors	9 in 10 or better
Reporting time per technician per shift	Time study in baseline and run weeks	At least 30 minutes saved
First-time fix on repeat visits	Repeat jobs on the same asset within 30 days	Direction only in two weeks; tracked after

Every readout will be published on the pilots page, including the ones where IVA did not clear the bar.

The plan

Three stages. Each has one number that decides whether we move on.

1. Design partners. Run pilots with telecom field operations and industrial maintenance crews. The number: a crew that refuses to give IVA back and a customer that pays to keep it.
2. One vertical, repeatable. Build connectors for the most common systems of record in the vertical that wins stage one. The number: a new site live in under two weeks with no custom work.
3. The field record layer. Extend to the adjacent frontline work that shares the same gap: installs, inspections, audits and handovers. The number: signed records written per month, and the share of them that later prove correct.

What would prove this wrong

We would rather find out early. The thesis fails if any of these turn out to be true:

• Technicians won’t wear or use the capture device on real jobs, whatever it saves them.
• Supervisors don’t trust AI-drafted records and rewrite them anyway, so no time is saved.
• Time saved on reporting doesn’t turn into more jobs, faster closure or fewer repeat visits, so nobody pays for it.
• Systems of record are too closed to write back to without months of integration per customer.

If you run field crews and think one of these is already true, I want to hear it.

1. Salesforce, survey of 350 full-time US tradespeople and technicians, fieldwork 22 February to 6 March 2025, published April 2025. Source. ↩
2. For example, Meta’s Wearables Device Access Toolkit gives mobile apps access to its AI glasses’ camera, with microphone and speakers available over Bluetooth. Public publishing has been limited to selected partners during the preview. Source. ↩