AI-NATIVE SERIES · WEARABLE AI · THE WEARABLE LADDER, EPISODE 2 OF 3

AI Glasses, by the Documentation: 11 of My 18 Laptop Tasks Should Work Hands-Free

By Paul Jialiang Wu · agentic-portfolio-lovat.vercel.app · 2026-09-30 · 12 min read

The one question this episode answersWhich of my laptop tasks can AI glasses actually do hands-free today, and where do they break?

This piece does not answer why earlier head-worn computers died — that is episode 1, the death table — or what must become true before glasses replace a desk, which is episode 3, the prediction ledger.

What this AI glasses episode covers, and who it's for

This is episode 2 of The Wearable Ladder. Episode 1 looked back at 23 head-worn computers that failed; episode 3 looks forward with dated predictions. This one is the present tense. The plan was to answer it with a road-trip day — every task tried hands-free, every attempt logged. That day hasn't happened yet, and I won't invent it. So this edition answers from the other honest source: the documentation, task by task, with a link for every verdict. The day will then test whether the documentation is right.

It's for engineers deciding what to build for glasses, founders deciding whether a pair belongs in the kit, and anyone who bought a pair and wonders what it can actually do.

The picture: a sparring round, under the ruleset

You cannot bring a barbell into a sparring round. Whatever you do in the round, you do with what's already on you — and under the ruleset, not the highlight reel. The glasses are the only computer already on you mid-climb or mid-drive; the documentation is the ruleset.

The ruleset: what the documentation says

Before judging any task, the ground rules. The glasses are a curated bridge, not a mirror of your phone.

Meta Connect 2026 (23–24 September) changed the developer side: the toolkit for building glasses apps reached version 1.0, with a battery reading and a way to launch your app by voice. But every one of those new features is marked experimental, and apps that use them "cannot be published yet" (toolkit changelog). Voice launch opens an app; it can't pass it your request.

My 18 laptop tasks, judged by the documentation

Two caveats the table carries in its details column. Many "yes" answers are English-only and US-first — calendar and email readout are documented for English in the US. And several need a connection: offline, the assistant isn't there at all. A "yes" in the table is a yes for an English speaker in the US with signal.

What the pattern says

Look at where the "no"s land: provider (WeChat and Feishu aren't on the closed list of message apps), relay (no way to reach GitHub without the phone doing it), platform (no general hook for an agent). None of them is the battery, the camera, or the microphones. The hardware can hear me and talk back; the platform decides who it's allowed to talk to. That is episode 1's lesson in the present tense — the devices that failed weren't limited by their computers either — and it is exactly the condition episode 3 tracks as prediction P3: whether any developer can publish a glasses app by mid-2027. The guest list is starting to open: Meta's Muse agent, which already connects to GitHub among 1,500+ services, is "coming soon" to the glasses, and Meta AI Connectors let a service offer actions to the assistant — both announced at Connect 2026, both without a date or general availability (Meta: Muse, Connectors). That's P3 in motion.

Five whys: why can't the glasses do my work tasks?

1. Why can't they? Because 4 of my 18 tasks — WeChat, Feishu, GitHub, a coding agent — are documented as not supported, and the documentation is silent on the rest of my work stack. Evidence: the table above, generated from content/series/wearable-ladder/audit-tasks.yml.
2. Why are those apps missing? Because the glasses only connect to providers Meta lists — Messenger, WhatsApp, Instagram and your phone's messages — and the list is closed. Evidence: Meta help: message providers.
3. Why can't those apps add themselves? Because third-party apps for the glasses can't yet be published to the public, and publishing to the App Store "is not currently supported". Evidence: Meta's iOS integration guide.
4. Why not, when the toolkit just reached 1.0? Because every new capability in 1.0 is marked experimental, and apps using it "cannot be published yet". Evidence: toolkit 1.0 changelog.
5. So what's the real bottleneck? The root: for work, the glasses are limited by who the platform lets in, not by what the hardware can do. The same device that reads a WhatsApp message aloud can't read a WeChat one. Evidence: tasks 1 and 3 in the table — same device, same action, different app, opposite verdict.

Operate — the test that runs next

Documentation is a claim. The test is already built and live: the 18 tasks are pre-registered in content/series/wearable-ladder/audit-tasks.yml, each with what "done" means, and an owner-only phone page on this site (/glasses-audit) logs each attempt the moment it happens — pass, or fail plus which of eight layers broke. node scripts/glasses-audit.mjs pull brings the log into the repo, and this page is rebuilt with the measured result next to the documented one.

Feedback — what the documentation can't see

• Whether it's true. A help page can be stale, optimistic, or region-specific. Meta's own pages contradict each other in places (battery life with the case is 24 hours on one page, 30 on another).
• How it feels. "Supported" can still mean three tries in the wind. Only the day's timings will show that.
• Your tasks. Mine are a founder's; a nurse's or a student's list would sort differently. Make your own.

Feedforward — predictions for the day, written now

• At least 9 of the 11 documented tasks will pass on the first attempt. If fewer do, the documentation is optimistic, and that becomes the headline of the update.
• All 4 "not supported" tasks will fail, and the most common failure layer will be provider or relay. If a "no" task passes, the documentation is behind the product — also a finding.
• The measured update will be published by 2026-10-31 — or this line will say why not.
• If prediction P5 in episode 3 resolves true (the glasses' agent drives your own computer), the whole list is run again.

Where this episode sits in the series

Same story, five exits

Build it in 30 minutes

• Input: ten to twenty things you open a laptop for, written before you look anything up.
• Output: each one marked documented / not supported / undocumented, with a link.
• Invariant: the list is written first; no swapping tasks after you see the answers.
• Stop rule: if the documentation is silent, mark it undocumented — don't guess.
• Minimal record: task, done_when, documented.verdict, documented.layer, documented.source.
• Deliberately missing: the measurement. That's the day — and the second half of this page.

5S self-score, with evidence

Related

• Episode 1 — the death table: 23 head-worn computers, and why 19 of them died of money.
• Episode 3 — the prediction ledger: five conditions, eight dated predictions, a script that scores them.
• Desktop App Control — the same "measure the surface before you build" discipline, on a Mac.