After the Answer Box

AI glasses, spatial interfaces, and the library-shaped operating layer for inquiry

In my last post, I noted some of my early thoughts around what I described as the closed-book effect: the way a fluent and seamless AI response can make learning feel finished before the researcher has even opened the sources.

The problem was not only that AI might be wrong. The problem was that AI might feel complete.

I have been trying to imagine what comes after that.

Because the dominant AI interface today is still basically a box. You type into it. It replies. Maybe the box is embedded in a search engine, a writing tool, a database, a browser, or a learning platform like Khan Academy, but the basic shape is familiar: prompt, answer, prompt, answer.

That shape matters.

The answer box trains the user to expect completion. It says: ask me something and I will give you the thing. It may offer follow-up questions, citations, summaries, or suggested prompts, but its center of gravity is still the response. The interface points toward an answer.

But serious inquiry does not usually work that way.

Research is not only a request for information. It is a process of orientation, comparison, doubt, revision, and movement. The ACRL Framework for Information Literacy gives librarians useful language for this: authority is constructed and contextual, research is inquiry, scholarship is conversation, and searching is strategic exploration (Association of College & Research Libraries [ACRL], 2016). Those ideas are not just teaching concepts. They are interface concepts. They describe what a research tool should help a user experience.

A chatbot can explain those ideas. But most chatbots do not embody them.

The interface still suggests that knowledge arrives as a polished paragraph.

That is why I keep coming back to a different question:

What should replace the answer box?

AI Is Leaving the Box

This question is becoming more urgent because AI is starting to move out of chat windows and into the physical world.

The next major AI interface may not be a chatbot at all. It may be glasses. It may be a headset. It may be a spatial display. It may be a lightweight device that sees what the user sees, hears what the user asks, and places digital information into the world around them.

This is no longer just speculative. Google has described Android XR as a platform for headsets and glasses, built in collaboration with Samsung and Qualcomm, with Gemini integrated into the experience (Izadi, 2024). Google has also framed Android XR as an open, unified platform for XR devices, with tools such as ARCore, Android Studio, Jetpack Compose, Unity, and OpenXR available to developers (Izadi, 2024).

In 2026, Google described intelligent eyewear with Gemini, including audio glasses and display glasses designed to provide help without requiring the user to pull out a phone (Izadi, 2026). The Android developer documentation now explicitly addresses XR headsets, wired XR glasses, audio glasses, and display glasses, and points developers toward familiar tools, including Jetpack XR, Unity, Godot, Unreal Engine, OpenXR, and WebXR (Android Developers, n.d.).

XREAL’s AURA is another useful signal. XREAL describes AURA as a next-generation Android XR spatial computer that combines lightweight glasses with a dedicated compute puck, powered by Android XR and Gemini, with a launch expected in Fall 2026 (XREAL, n.d.). Google also announced that reservations for XREAL AURA had opened and described it as XREAL’s first wired XR glasses powered by Android XR and the Snapdragon Reality Elite Platform (Google, 2026).

Snap is moving in a similar direction from a different angle. In June 2026, Snap introduced SPECS, a wearable computer built into see-through augmented reality glasses, positioning the product around AI assistance, work tools, entertainment, and shared experiences in the world around the user (Snap Inc., 2026).

Meta is already selling AI glasses as an everyday product category, with Ray-Ban Meta glasses marketed around built-in Meta AI, camera capture, and open-ear audio (Meta, n.d.).

I do not mention these products because I think libraries should rush out and buy every headset or pair of glasses. Most libraries probably should not. The more important point is that the interface metaphor is changing.

The industry is moving from:

AI as a box you open

toward:

AI as something that appears in the environment

That shift matters for librarians and educators.

Because if the chatbot created the closed-book effect, a wearable AI interface could create something even stronger.

It could create the closed-world effect.

The closed-world effect would happen when AI does not just answer the question, but wraps the user’s environment in immediate interpretation.

You look at a book, and the system explains it.

You look at a painting, and the system identifies it.

You look at a shelf, and the system recommends where to go next.

You look at a paragraph, and the system summarizes, translates, defines, contextualizes, and connects.

That could be extraordinary.

It could also be dangerous.

Not dangerous only in the dramatic sense. I do not mean that the glasses become malicious or that every student becomes helpless. I mean something quieter: the interface could make the world feel already interpreted.

A student standing in front of a shelf might no longer experience the shelf as a place of uncertainty, browsing, accident, and comparison. They might experience it as a surface for AI annotation. The system tells them what matters. The system highlights the relevant book. The system gives the summary. The system identifies the expert. The system suggests the next move.

And once again, the feeling of orientation might arrive before the work of orientation has happened.

That is the problem.

The future AI interface may not simply answer too quickly. It may interpret too quickly.

This is why librarians should pay attention to AI glasses, spatial computing, and XR even if we are skeptical of the hype. The important question is not whether a particular headset belongs in every library. The important question is what kind of intellectual habits these interfaces will train.

Will they train users to inspect evidence?

Will they make uncertainty visible?

Will they distinguish a citation from proof?

Will they show disagreement?

Will they help the user recognize what they do not yet know?

Or will they make the world feel pre-digested?

A library-minded AI system should not simply label the world. It should help the user move through uncertainty.

That difference matters.

The Interface Should Be a Room, Not a Box

In the last post, I ended with the idea that the next important AI interface might not be a smarter box.

Maybe it is a room.

I still think that is right.

The box returns answers.

A room supports movement.

A box says: here is the response.

A room says: here is where you are, here is what is nearby, here is what is missing, here is what disagrees, here is what you might open next.

A library is a room in that deeper sense. It is not just a container for information. It is an environment that teaches relation. Books have neighbors. Subjects have depth. Call numbers create intellectual geography. Databases reveal disciplinary boundaries. Citations create trails. Archives preserve gaps as well as evidence. A reference interview turns a first question into a better question.

The library gives inquiry a shape.

AI interfaces need that shape.

A library-minded AI system should not be built around the assumption that the user wants a final answer. It should be built around the assumption that the user needs orientation.

This is especially true for students, but it is not only true for students. Researchers need orientation. Faculty need orientation. Librarians need orientation. Readers need orientation. Organizations need orientation. Communities need orientation.

Very often, people do not need a better answer yet.

They need to know where they are.

The Product Is Not the Headset

This is where my thinking often feels like it moves beyond my typical essays.

If someone has a fundamentally new idea for how people should interact with AI, I do not think the right starting question is:

Which device will win?

The better question is:

What layer survives when the devices change?

If the goal is to build something like the “iPhone moment” or “Android moment” for AI interaction, then I would not start by building a headset company.

I would not even start by building a headset app.

I would build the operating layer that sits above the hardware.

Think about earlier platform shifts. Instagram survived multiple generations of phones because it was not really about one iPhone model. Slack survived across desktop, browser, and mobile because it owned a way of working. Figma survived because it understood collaboration through the browser better than many native tools understood collaboration through the desktop.

They did not own the device.

They owned the behavior.

That is the lesson I would carry into AI.

Roughly stated, I believe most founders will build something like this:

AI app

↓

Vision Pro

or:

AI app

↓

Meta Quest

or:

AI app

↓

Android XR

That makes sense for fast to prod workflows, but it is probably too narrow for a serious long-term idea.

The better structure is this:

AI interaction layer

↓

Adapters

↓

Vision Pro

Meta Quest

Android XR

smart glasses

phones

desktop

browser

The AI interaction layer is the company.

The hardware support is a plugin.

This distinction matters because the device race is still unstable. Some hardware will disappear. Some platforms will pivot. Some early devices will look obvious in retrospect only because everything else failed. Apple may continue to refine its premium spatial computing ecosystem. Meta may keep moving from VR headsets toward everyday AI glasses. Google may use Android XR to create a broader wearable ecosystem across multiple manufacturers. Snap may create a social AR category that does not look like the others.

No one knows yet.

So the deeper bet should not be one device.

The deeper bet should be this:

AI needs a better interaction model than the answer box.

That is the thing worth building here!

Today, the interface may live in a browser.

Tomorrow, it may live in a headset.

Later, it may live in ordinary-looking glasses.

Eventually, it may move across room displays, phones, watches, desktops, earbuds, smart glasses, and shared spaces.

That means the product should not be defined as:

a chatbot,

a VR app,

an AR app,

a search engine,

a citation tool,

a research dashboard,

or a writing assistant.

It should be defined more abstractly:

an AI-native orientation layer for inquiry.

The job of this system is not simply to answer.

The job is to help a person or community understand where they are in relation to a question, source, project, collection, argument, or body of knowledge.

That means the core experience should survive across devices.

On a laptop, it might look like a workspace.

On a phone, it might look like a compact guide.

In a headset, it might become a room.

In smart glasses, it might become a subtle overlay.

In a library building, it might become a public exhibit or a research kiosk.

In a classroom, it might become a shared map of inquiry.

Same underlying system.

Different surfaces.

Step 1: Define the Core Interaction Primitive

Every major computing era has had a basic interaction primitive.

The command line had the command.

The graphical user interface had the click.

The web had the link.

The smartphone had the tap, swipe, and pinch.

The chatbot has the prompt.

The question now is:

What becomes the mouse click of AI?

That question is still open, and answering it may be the real opportunity.

A prompt is useful, but it is not enough. A prompt treats interaction as a request-response exchange. But research, learning, and thinking are not only request-response activities. They involve wandering, comparing, doubting, returning, saving, rejecting, connecting, reframing, and asking better questions.

So the next interaction primitive may not be “ask.”

It may be something like orient.

The user brings something into the system: a question, a title, a book, a shelf, a quote, a PDF, a syllabus, a draft, a source list, an archive box, a database result, or a confusing idea.

The system does not simply answer.

It orients.

It shows the context, the neighboring ideas, the relevant sources, the disagreements, the missing evidence, the assumptions, and the possible next moves.

This is where the library metaphor becomes operational.

A library-minded AI interface should not treat knowledge as a pile of answerable prompts. It should treat knowledge as terrain.

The user is not only asking for information.

The user is trying to find their way.

Possible Interaction Primitive 1: Spatial Memory

Current AI systems are usually organized around conversations.

Conversation

Conversation

Conversation

But that is not how people understand complex work.

A research project has places.

There is the main question. There are background sources. There are key authors. There are debates. There are notes. There are discarded ideas. There are unresolved questions. There are adjacent subjects. There are things to verify later.

A better structure might be:

Rooms

Objects

People

Projects

Sources

Claims

Questions

Shelves

Trails

In this model, the AI does not merely remember chat history. It remembers the intellectual space the user is building.

A student working on Toni Morrison might have a room with primary texts, biographical context, criticism, historical background, recurring themes, theoretical approaches, and possible paper directions.

A researcher working on urban planning might have a room with zoning law, public health research, housing data, community organizations, historical policy, GIS sources, and contested terms.

A librarian preparing an exhibit might have a room with objects, labels, metadata, interpretive themes, conservation notes, possible audiences, and related holdings.

The point is not to make the interface cute or game-like.

The point is to give inquiry a shape.

Possible Interaction Primitive 2: Persistent Presence

Another possible primitive is presence.

Today, a user usually opens an AI tool, asks a question, receives an answer, and leaves.

Open ChatGPT

Ask question

Close ChatGPT

But the future interface may feel less like opening a tool and more like having intelligence available within the work itself.

That does not mean the AI should interrupt constantly.

It does not mean it should watch everything.

It does not mean it should become a surveillance companion.

A library-minded AI should be present but restrained.

It should be available when summoned. It should remember the project when the user wants it to. It should help the user return to a previous line of thought. It should notice when the user has gathered many sources but no clear question. It should help transform confusion into a path.

The right metaphor is not a nagging assistant.

It is a reference librarian who remembers what you are working on because you asked for help with that work.

That distinction matters because libraries have long treated privacy as central to intellectual freedom. ALA describes privacy as connected to its core values and its commitment to intellectual freedom, while the Association of Research Libraries has argued that research libraries should prioritize security and privacy in the use of AI tools, technology, and training data (American Library Association, n.d.; Association of Research Libraries, 2024).

A portable reference room should not become a surveillance tutor.

Possible Interaction Primitive 3: Intent Layer

Another possible primitive is intent.

Right now, most digital work still requires users to move through apps:

Open database.

Search terms.

Open article.

Save PDF.

Open citation manager.

Create note.

Open document.

Write paragraph.

Return to AI.

Ask for summary.

Check source.

Repeat.

An AI-native interface might allow a user to express intent at a higher level:

“Help me understand this debate.”

“Help me find the strongest sources for this claim.”

“Show me what I still need to verify.”

“Turn this reading list into a pathfinder.”

“Help me prepare for discussion.”

“Help me see what perspectives are missing.”

“Help me finish this paper without pretending the research is done.”

The system would not replace the work.

It would coordinate the work.

This is an important distinction.

The danger of AI is that it completes too much too quickly. The opportunity is that it can organize the next move.

A good intent layer should not say:

“Here is the final answer.”

It should say:

“Here is what your intent requires. Here is what you have already done. Here is what remains unresolved. Here are the next useful actions.”

Possible Interaction Primitive 4: Evidence Gesture

A fourth possible primitive is evidence.

In the current chatbot model, evidence is often secondary. The answer comes first, and citations may appear after it. But in serious inquiry, evidence should not be decoration. It should be structural.

The interface could make show me the evidence a basic gesture.

Every claim should be inspectable.

A user should be able to expand a claim and see:

What source supports this?

Is the source primary, secondary, scholarly, popular, archival, statistical, legal, or historical?

Does the source actually say what the system claims?

What page, passage, table, dataset, or quotation matters?

What would a skeptical reader ask?

What contradicts this?

What is missing?

This would directly resist the closed-book effect.

Instead of making the answer feel finished, the interface would make the answer feel accountable.

This is also where library AI tools need transparency. NISO’s work on generative AI and web-scale discovery has emphasized transparency among content providers, discovery providers, and libraries as generative AI begins to affect how users do research and how content is indexed and surfaced (National Information Standards Organization [NISO], 2025).

In other words, the question is not only whether the answer is good.

The question is whether the system lets the user inspect how the answer was made.

Possible Interaction Primitive 5: Neighboring Shelf

A fifth primitive is adjacency.

One of the most valuable things about a physical library is that a book has neighbors. The user can see that a topic has depth. They can stumble into related areas. They can discover that their question belongs to a larger conversation.

AI interfaces usually hide that.

They collapse the topic into a response.

A library-minded interface should restore adjacency.

For any topic, source, or question, the system should show neighboring terms, related debates, adjacent disciplines, foundational texts, newer challenges, missing perspectives, and alternative routes.

The basic gesture here is:

What is near this?

Nearness could mean intellectual, historical, methodological, disciplinary, geographic, archival, or political proximity.

This is especially important for students because they often do not know the vocabulary of the field yet. The system should help them discover the terms they did not know they needed.

The neighboring shelf is not just a nostalgic image.

It is a product feature.

Step 2: Design for Glasses First

The next major AI interface may not be a headset.

It may be glasses.

That does not mean the product should be glasses-only. It means the design constraints of glasses are useful because they force discipline.

Glasses cannot support a cluttered dashboard.

They cannot show endless panels.

They cannot ask the user to manage complicated menus.

They require short, contextual, lightweight interactions.

That is good.

If an interface works well in glasses, it will probably also work well elsewhere. If it only works on a giant desktop dashboard, it may not survive the next platform shift.

Designing for glasses means assuming the following inputs:

voice,

gaze,

gesture,

camera,

location,

context,

touchpad or ring controller,

and typed text when paired with phone or desktop.

It also means assuming the following outputs:

audio,

small visual overlays,

spatial anchors,

short summaries,

directional cues,

highlighted objects,

ambient reminders,

saved trails,

and handoff to larger screens.

The interface should not be a wall of text floating in front of the user.

It should be minimal.

For example, a student standing in a library aisle might ask:

“What am I looking at?”

A bad AI system would summarize the whole subject.

A better system might say:

“You are in a section that connects housing policy, urban planning, and municipal governance. For your paper, three useful directions are zoning, displacement, and public housing history. Do you want background, debate, or sources?”

That is a library interaction, not an answer dump.

A researcher looking at a rare object might ask:

“What should I notice first?”

A bad system would identify the object and give a generic description.

A better system would say:

“Start with material, date, provenance, marginalia, and signs of use. The binding and annotations may matter as much as the printed text.”

Again, the system orients rather than finishes.

Step 3: Create a Spatial Knowledge Engine

This is where most people miss the opportunity.

Current AI:

Prompt

Response

Future AI:

World model

But for a library-minded system, “world model” should not mean total surveillance. It should mean a structured model of the inquiry the user has chosen to work on.

The system should understand:

projects,

questions,

sources,

claims,

authors,

arguments,

evidence,

gaps,

terms,

disciplines,

people,

locations,

collections,

objects,

meetings,

drafts,

decisions,

and next steps.

This is closer to Google Maps for knowledge than a chatbot.

Google Maps does not merely answer “where is the cafe?” It gives orientation: routes, nearby places, travel time, alternatives, landmarks, traffic, saved locations, and context.

A knowledge map would do something similar for inquiry.

It would not only answer:

“What is this topic?”

It would show:

where the topic sits,

which paths are available,

which routes are well established,

which are contested,

which require background,

which sources are central,

which sources are nearby,

which claims need evidence,

and which questions remain open.

The goal is not omniscience.

The goal is orientation.

Step 4: Own the Memory Layer

The memory layer may be the most important part of the system.

Everyone is focused on models. That is understandable. Models are impressive. They improve quickly. They create the feeling that intelligence itself is the product.

But over time, many model capabilities may become widely available. The durable value may come from memory, context, workflow, trust, and user-owned knowledge structures.

Models may become commodities.

Memory becomes the moat.

But the memory has to be designed carefully.

There is a bad version of AI memory: the system tracks everything, infers everything, stores everything, and quietly builds a behavioral profile.

That is not the library model.

A library-minded memory layer should be intentional, bounded, inspectable, editable, and portable.

The user should know what the system remembers.

The user should be able to delete it.

The user should be able to export it.

The user should be able to create separate contexts for separate projects.

The user should be able to say:

Remember this for this project, but not for my general profile.

The memory layer should store things like:

conversations,

documents,

sources,

citations,

annotations,

people,

projects,

locations,

objects,

collections,

goals,

relationships,

open questions,

claims to verify,

decisions made,

terms discovered,

searches attempted,

paths abandoned,

and next steps.

The important structure is not chat history.

It is a knowledge graph.

A chat history says:

Here is what you asked before.

A knowledge graph says:

Here is what your inquiry is made of.

That difference is everything.

Step 5: Build a Knowledge Graph, Not a Chat Transcript

A knowledge graph for this system might include several types of nodes:

User

Project

Question

Source

Claim

Evidence

Author

Concept

Discipline

Collection

Object

Location

Person

Organization

Event

Term

Note

Draft

Task

Meeting

Pathfinder

Shelf

Debate

Gap

Decision

And relationships such as:

supports

contradicts

cites

is cited by

belongs to

is adjacent to

is background for

is evidence for

is disputed by

requires verification

is authored by

is part of collection

was discussed in

led to

revises

summarizes

depends on

is missing from

is next step for

This gives the AI something more meaningful to work with than a long transcript.

For example, a student’s project might contain:

Main question: How did redlining shape public health outcomes in Boston?

Key concepts: redlining, public health, housing segregation, environmental exposure, urban renewal.

Sources: one historical map, three scholarly articles, one policy report, two local archives.

Claims: redlining contributed to long-term environmental health disparities.

Evidence status: partially supported; needs local data.

Missing perspectives: community organizations, public health datasets, recent city policy.

Next step: search for neighborhood-level asthma or heat exposure data.

This is much more useful than a chat log saying the student asked for sources on redlining.

The system knows the shape of the work.

That is the product.

Step 6: Build for Communities, Not Only Individuals

The standout feature probably will not be:

AI + user

It will be:

AI + group

This matters especially for libraries, labs, classrooms, archives, and organizations.

A personal AI assistant can help one person. A community AI interface can help a group understand itself.

Let's imagine a research lab.

The system knows:

papers,

datasets,

experiments,

protocols,

meetings,

research questions,

failed attempts,

lab members,

instruments,

grant deadlines,

open problems,

and decisions made.

A new graduate student joins. Instead of reading years of scattered documents, they enter a structured orientation space.

They can ask:

“What is this lab working on?”

“What has already been tried?”

“What papers are central?”

“What assumptions does the group share?”

“What remains unresolved?”

“Where should I begin?”

Imagine a library.

The system knows:

collections,

subject guides,

archives,

exhibits,

databases,

instruction sessions,

research consultations,

faculty interests,

student needs,

common assignments,

local expertise,

digitized objects,

and underused materials.

A student asks about AI in higher education. The system does not merely answer. It connects them to databases, librarians, workshops, guides, books, debates, policies, and examples from their institution.

Imagine a startup.

The system knows:

codebase,

customers,

roadmap,

decision history,

support tickets,

sales calls,

design docs,

technical debt,

open questions,

product principles,

and competitors.

A new employee asks why something works the way it does. The system can answer not only with the current documentation but with the history of decisions that produced it.

In each case, the system is not valuable because it talks nicely.

It is valuable because it preserves, organizes, and activates collective memory.

That may be much more powerful than a personal assistant.

Step 7: Build the Device-Agnostic Runtime

The technical architecture should assume many frontends.

Today:

browser,

desktop app,

mobile app.

Tomorrow:

Android XR,

Quest,

Vision Pro,

public display,

classroom screen,

library kiosk.

Later:

smart glasses,

earbuds,

room-scale spatial computing,

ambient research environments.

Same backend.

Different frontends.

The runtime should separate core functions from device-specific presentation.

Core functions:

identity and permissions,

project memory,

knowledge graph,

retrieval,

source ingestion,

annotation,

claim extraction,

evidence checking,

pathfinder generation,

conversation,

task orchestration,

privacy controls,

export,

collaboration,

and audit trail.

Device adapters:

browser interface,

mobile interface,

XR room interface,

glasses overlay,

voice interface,

kiosk mode,

and API layer.

The product should be designed so that a new device is not a new company.

It is a new adapter.

This is how the system avoids being trapped by one hardware cycle.

Step 8: Target Android XR First, But Do Not Marry It

If forced to choose a first spatial ecosystem to watch, I would watch Android XR closely.

Not because it is guaranteed to win.

Because it has several advantages:

Google,

Samsung,

Qualcomm,

multiple manufacturers,

Gemini integration,

possible hardware diversity,

developer tooling,

and a platform strategy that resembles an ecosystem more than a single device.

Google has explicitly described Android XR as a unified platform for headsets and glasses, with opportunities for developers to build across devices using familiar Android tools and frameworks (Izadi, 2024). The Android XR developer documentation also points to a broad development stack and describes ways to build for XR headsets, wired XR glasses, audio glasses, and display glasses (Android Developers, n.d.).

That makes Android XR interesting.

But it should not become the whole bet.

Apple may still create the best premium experience. Meta may have the strongest consumer installed base. Snap may push interesting social AR. XREAL and similar companies may move faster in lightweight glasses. Future devices may come from companies that do not matter yet.

So the strategy should be:

build the core interaction layer,

support Android XR early,

support browser and mobile immediately,

support other XR platforms through adapters,

keep the knowledge graph portable,

keep the memory user-controlled,

and avoid platform-specific lock-in whenever possible.

The platform is distribution. The interaction layer is the product.

The Long-Term Architecture:

But underneath that basic diagram, there should be several layers.

Layer 1: Ingestion

The system needs ways to accept:

text,

PDFs,

webpages,

books,

citations,

images,

audio,

video,

syllabi,

notes,

slides,

archives,

catalog records,

database exports,

meeting transcripts,

spatial scans,

and object metadata.

The user should be able to bring materials into a project deliberately.

The system should not need to spy on everything.

Layer 2: Interpretation

The system analyzes what the user has brought in.

It identifies:

topics,

claims,

authors,

dates,

entities,

methods,

source types,

arguments,

citations,

uncertainties,

contradictions,

missing context,

and related terms.

Layer 3: Knowledge Graph

The system turns materials into structured relationships.

This source supports that claim.

This author belongs to this debate.

This concept is adjacent to that field.

This question requires historical background.

This claim lacks evidence.

This paper cites that older paper.

This archival object belongs to this collection.

This user note revises this earlier assumption.

Layer 4: Memory

The system remembers the project over time.

Not as an endless transcript, but as an evolving map.

What changed?

What did the user learn?

What questions were resolved?

What remains open?

What next steps were recommended?

What did the user reject?

What sources became central?

Layer 5: AI Orchestration

The system uses models to perform tasks:

summarize,

compare,

extract claims,

generate pathfinders,

suggest searches,

identify gaps,

explain concepts,

prepare discussion questions,

create reading routes,

check citations,

draft outlines,

create exhibit narratives,

generate metadata suggestions,

and prepare teaching materials.

But the model is not the product by itself.

The model is one engine inside the system.

Layer 6: Interface

The interface changes by device.

Browser: workspace, maps, documents, guides.

Mobile: capture, quick orientation, source saving, voice notes.

XR headset: rooms, shelves, spatial maps, immersive exhibits.

Smart glasses: lightweight overlays, prompts, labels, reminders, audio guidance.

Public display: shared maps, exhibits, classroom inquiry walls.

Layer 7: Governance

A serious system needs governance from the beginning.

Who owns the memory?

Who can see a project?

What gets stored?

What can be deleted?

Can a student keep work private from an instructor?

Can a group share a project without exposing individual notes?

Can a library preserve a public pathfinder while deleting private interactions?

Can the system show why it made a recommendation?

These are not secondary features.

They are part of the product.

The Association of Research Libraries’ AI principles emphasize transparency, human involvement in critical decision-making, privacy, and information integrity (Association of Research Libraries, 2024). Those principles are not just policy language. They are product requirements.

The Pure "Library Version" of the Product

For libraries, the first version does not really need to be everything.

A practical starting product could be:

an AI pathfinder builder.

The user enters:

a topic,

a research question,

a book title,

a course assignment,

a syllabus,

a source list,

or a confusing passage.

The system creates a structured research space with:

essential context,

key terms,

what to understand first,

major debates,

recommended databases,

source types to look for,

important authors,

background sources,

scholarly sources,

primary sources,

related books,

neighboring subjects,

questions to ask,

claims to verify,

missing perspectives,

and three next steps.

This alone would already be more library-minded than most chatbots.

The system should avoid final-answer language.

It should say:

Here is a way into the topic.

Not:

Here is the answer.

A second version could add source ingestion.

The user uploads five sources. The system maps them:

What do these sources agree on?

Where do they disagree?

Which claims appear strongest?

Which source is background?

Which source is evidence?

Which source is theoretical?

Which source is outdated?

What should the user read next?

A third version could add collaborative spaces.

A class, lab, or library team could build a shared inquiry room around a topic.

A fourth version could add spatial display.

The pathfinder becomes a room, shelf, map, or exhibit.

A fifth version could add smart glasses.

The system becomes an orientation layer over physical collections, exhibits, archives, or study spaces.

That is a plausible path.

Do not begin with the headset.

Begin with the pathfinder.

Then let the pathfinder become spatial.

Product Principles

A product like this obviously needs strong principles.

1. Orientation over completion

The system should help the user understand where they are, not make them feel done too early.

2. Evidence before fluency

A smooth answer is not enough. Claims should remain connected to sources.

3. Inquiry stays open

The interface should show next questions, not only final responses.

4. Context is chosen, not stolen

The user decides what to bring into the system.

5. Memory is inspectable

The user can see, edit, export, and delete what the system remembers.

6. The system shows disagreement

A serious research interface should make conflict visible.

7. The interface teaches judgment

It should not only provide information. It should help users evaluate information.

8. The product is device-agnostic

No single headset, phone, or platform owns the idea.

9. The group matters

The system should support shared inquiry, not only personal productivity.

10. The metaphor is a room, not a box

A box returns answers.

A room supports movement.

Minimum Viable Product

The first build could be modest but conceptually complete and fully functional.

Possible MVP:

The user creates a project.

They enter a topic, question, title, or source.

The system generates a Pathfinder Room with:

Overview

Key terms

What to understand first

Major debates

Source types

Search strategies

Suggested databases

Related subjects

Claims to verify

Missing perspectives

Next three moves

The user can add sources.

The system extracts claims and connects them to the project.

The user can mark sources or claims as:

trusted,

uncertain,

read later,

central,

background,

contradictory,

or needs verification.

The system maintains a project map.

The user can ask:

Where am I in this topic?

What should I read next?

What am I missing?

What claims have I not supported?

What would a skeptical reader ask?

How has my question changed?

That MVP could run in a browser.

No headset required.

But it should be designed so that later the same Pathfinder Room can become spatial.

The One-Shot Documentation Strategy

This is where the builder’s work begins before the coding begins.

If the goal is to eventually build this with a powerful coding model, the documentation should be created like a future build packet.

That packet should include:

vision document,

product principles,

target users,

core use cases,

user stories,

information architecture,

data model,

knowledge graph schema,

privacy model,

permission model,

memory rules,

interface sketches,

MVP scope,

API assumptions,

front-end requirements,

back-end requirements,

model orchestration plan,

evaluation criteria,

failure modes,

example projects,

example pathfinders,

example prompts,

example outputs,

and non-goals.

The more precise this documentation is, the more likely a future coding model can produce something coherent.

The point is not to wait passively for models to become stronger.

The point is to use the waiting period to clarify the idea until it becomes buildable.

Because the future coding model will not magically know what is meant by “library-minded AI,” “orientation,” “closed-book effect,” “pathfinder,” “spatial knowledge engine,” or “portable reference room.”

Those terms have to be defined.

The system’s values have to be defined.

The memory rules have to be defined.

The refusal rules have to be defined.

The user flows have to be defined.

The product’s relationship to evidence has to be defined.

That conceptual work is product work.

Things to Document Next

Thinking that I may need to create a full conceptual document with sections like these.

1. Name and Thesis

What is the product called?

What problem does it solve?

What does it believe that other AI tools do not?

2. Problem Statement

Define the phenomena closed-book effect.

Define why chatbot interfaces are insufficient for serious inquiry.

Define the closed-world effect.

Define why spatial AI could make the problem worse.

3. Product Metaphor

Is it a room?

A pathfinder?

A map?

A shelf?

A reference desk?

A knowledge OS?

The metaphor matters because it will shape the interface.

4. User Types

Students

Researchers

Faculty

Librarians

Archivists

Curators

Research labs

Classes

Institutions

Independent readers

5. Core Jobs to Be Done

Help me understand where to begin.

Help me evaluate this answer.

Help me find better sources.

Help me map this debate.

Help me turn a vague topic into a research path.

Help me see what I am missing.

Help my group remember what we know.

Help me move from source to question to argument.

6. User Flows

Starting from a topic.

Starting from a book.

Starting from a syllabus.

Starting from a PDF.

Starting from a shelf.

Starting from a draft.

Starting from a citation list.

Starting from a research consultation.

Starting from a classroom assignment.

7. Data Model

Projects

Sources

Claims

Evidence

Questions

Notes

People

Terms

Debates

Collections

Tasks

Pathfinders

Rooms

Shelves

Trails

8. Memory Rules

What is saved automatically?

What requires user approval?

What expires?

What is project-specific?

What is global?

What is private?

What is shared?

What is exportable?

9. Interface Modes

Answer mode

Orientation mode

Pathfinder mode

Source comparison mode

Evidence inspection mode

Research map mode

Spatial room mode

Glasses overlay mode

Group memory mode

10. Evaluation

Does the system reduce premature closure?

Does it increase source checking?

Does it improve question quality?

Does it help users identify missing perspectives?

Does it make uncertainty visible?

Does it preserve privacy?

Does it help groups remember better?

Does it make users better researchers, or only faster users?

Ultimately, I do not anticipate one device will outright win, but rather AI interaction is still in a primitive state. Right now, most AI systems are answer boxes. But research is not an answer box activity. Learning is not an answer box activity. Librarianship is not an answer box activity. Knowledge work is made of context, evidence, memory, uncertainty, relationships, and next moves. So the opportunity is to build the layer that understands those things.

Not a chatbot.

Not a headset app.

Not a prettier search bar.

A spatial, memory-aware, evidence-conscious, privacy-respecting orientation system for inquiry.

A portable reference room.

A knowledge OS.

A way to keep the book open.

If AI is going to become something we wear, something we look through, something that sits between us and the world, then librarians should be part of deciding what it teaches people to do.

Not because libraries need to chase every new gadget.

Because librarians understand something AI companies often miss:

Finding an answer is not the same as finding your way.

Maybe the next important AI interface is not a box.

Maybe it is the room from the last post, rebuilt as something you can carry with you.

A room that appears when you need orientation.

A room with shelves, sources, arguments, gaps, and questions.

A room that does not rush to close the book.

A room that helps you learn how to keep it open.

References:

American Library Association. (n.d.). Privacy. Retrieved June 23, 2026, from https://www.ala.org/advocacy/privacy

Android Developers. (n.d.). Android XR. Retrieved June 23, 2026, from https://developer.android.com/develop/xr

Association of College & Research Libraries. (2016). Framework for information literacy for higher education. American Library Association. https://www.ala.org/acrl/standards/ilframework

Association of Research Libraries. (2024). Research libraries guiding principles for artificial intelligence. https://www.arl.org/wp-content/uploads/2024/04/Research-Libraries-Guiding-Principles-for-Artificial-Intelligence.pdf

Google. (2026, June 16). XREAL AURA and more Android XR news from AWE 2026. https://blog.google/innovation-and-ai/technology/xr-ar/awe-2026/

Izadi, S. (2024, December 12). Android XR: The Gemini era comes to headsets and glasses. Google. https://blog.google/products-and-platforms/platforms/android/android-xr/

Izadi, S. (2026, May 19). Intelligent eyewear is coming this fall. Google. https://blog.google/products-and-platforms/platforms/android/android-xr-io-2026/

Meta. (n.d.). Ray-Ban Meta AI glasses: New styles & colors. Retrieved June 23, 2026, from https://www.meta.com/ai-glasses/ray-ban-meta/

National Information Standards Organization. (2025, August 5). Generative artificial intelligence and web-scale discovery. https://www.niso.org/publications/odi-ai-survey-report

Silva, S., & Zeppenfeld, A. (2026, May 19). Updates to the Android XR SDK: Introducing Developer Preview 4. Android Developers Blog. https://android-developers.googleblog.com/2026/05/android-xr-sdk-developer-preview-4-updates.html

Snap Inc. (2026, June 16). Snap Inc. debuts SPECS augmented reality glasses to make computing more human. https://investor.snap.com/news/news-details/2026/Snap-Inc–Debuts-SPECS-Augmented-Reality-Glasses-to-Make-Computing-More-Human/default.aspx

XREAL. (n.d.). Project Aura: It feels like tomorrow. Retrieved June 23, 2026, from https://www.xreal.com/aura