Why we're building Voyager

Most work does not disappear when the app closes. It becomes a file. Then the reason it was made starts to fade.

Plans become documents. Presentations become decks. Customer interviews become recordings and notes. Design work becomes images, project files, exports, and screenshots. Code lives in repositories, but the thinking around it often sits in PDFs, issue threads, specs, and stray notes. Research spreads across downloads, links, clipped pages, and marked up files.

The tools around us keep changing. The output of the work still lands, again and again, as files.

Files remember less than we need

But the way we work with files has barely changed.

We put a file in a folder, give it a name, and hope we can find it later. At the moment we save it, the file is clear to us. We know which project it came from, what decision it supported, whether it is current, who reviewed it, and where it might be useful again.

A month later, most of that is gone from the system. It survives in someone's memory.

The file system remembers location. It does not remember why the file mattered.

The problem is reuse, not storage

This is not a failure of personal discipline. Real work rarely fits into one clean folder tree. One file can belong to several projects, several decisions, several stages, and several possible next steps. A screenshot might look like a throwaway image today, then become evidence for a product decision later. A customer note might start as raw material, become part of a sales deck, then come back months later when the team is revisiting the same question.

People remember files through context. Most tools ask people to recover them through paths, names, and recent activity.

That gap is where a lot of time disappears.

The same work gets rebuilt because the original material is hard to find. Files get reviewed again because nobody is sure which version was used. Decisions get explained again because the supporting material is disconnected from the outcome. Criteria that were already settled get recreated for the next task.

The problem is not that we lack files. The problem is that the files we already have are hard to reuse.

Voyager is our answer to that problem: a native macOS workspace for working with files through context instead of location alone.

AI makes context more important

This matters more now because AI tools are starting to work directly with files.

The important change is simple: AI tools are beginning to act on the folders, drafts, notes, screenshots, and source files people already depend on. They can rewrite a document, summarize a recording, modify code, move files, or generate a new report from existing material.

That makes the old problem more expensive. AI can create more output, faster. But if the input, reasoning, state, and intended next step disappear after the result is saved, the team has only made the pile larger. A generated document is only useful if someone can tell what it was based on. A rewritten file still needs review. A folder touched by an agent still needs to make sense after the run is over.

If AI is going to work on files, the workspace around those files needs to become more explicit.

Voyager starts from the files you already have

We do not want to replace files. We also do not want to ask people to move years of work into a new database, a new wiki, or a new cloud workspace before that work becomes usable. People already have valuable material on their Mac. Some of it is messy. Some of it is old. Some of it is still the best starting point for the next piece of work.

Voyager is built around that belief.

A file is more useful when it can be seen through the work it belongs to. The same file may need to appear in a project brief, a customer research set, and a launch checklist without being copied three times. A group of files may need to stay together because they explain a decision, support a proposal, or define the inputs for the next run.

That is the kind of context Voyager cares about: what a file is for, what state it is in, why it was grouped, and what can happen next.

A conversation with AI should start from the files, conditions, and context the user is already looking at. Automation should be a reviewable procedure over a known set of files, not a magic step that leaves the workspace harder to understand.

A file workspace for work that comes back

We are building Voyager because too much work starts from scratch even when the raw material already exists.

The cost is bigger than search time. It is the repeated checking, explaining, and rebuilding that happens after search fails or returns something ambiguous. It is the mental load of remembering where a decision came from. It is the hesitation before using an old file because nobody knows whether it is still the right one.

Files are traces of work, records of judgment, and inputs for whatever comes next.

A good file workspace makes those files useful again.

The work is already there. Voyager is about making it usable again.