Atlas: From a Fictional Assistant to Persistent Research Infrastructure

Atlas began, somewhat paradoxically, with a fictional machine.

For years, I had been fascinated by JARVIS, Tony Stark’s artificial intelligence in Iron Man. What interested me was not merely the spectacle of a computer capable of conversation, but the more consequential idea beneath it: an intelligent system that existed continuously alongside its user, accumulated context, acted across different tools, and remained useful even when it was not being directly addressed. My first attempt to reproduce some version of that idea was therefore named Jarvis. Yet the project eventually exposed a distinction that would shape everything that followed: there is a substantial difference between building an impressive chatbot and constructing a reliable computational system.

The original Jarvis became increasingly slow and cumbersome as I expanded it. Rather than continuing to repair an architecture that had accumulated too many assumptions, I chose to rebuild it. The release of Claude Fable 5 in June 2026, a model explicitly designed for extended coding and complex autonomous work, provided an unusually appropriate moment to attempt that reconstruction. I did not want simply to produce “Jarvis, but faster.” I wanted the resulting system to possess an identity and architecture that were genuinely my own. I renamed it Atlas, not as a replica of Stark’s assistant, but as a system intended to carry some portion of the informational and computational weight that otherwise remains on its user.

That decision produced three successive versions of Atlas, each of which altered not merely the quantity of available features but the underlying conception of what an artificial-intelligence assistant should be.

Atlas V1 established persistence. It was built as a local-first personal assistant capable of interacting through voice, a browser interface, and WhatsApp while using an Obsidian vault as long-term memory. Conversations were stored as Markdown, relevant information could be retrieved through BM25 search, and new memories could be connected through Obsidian-style [[wikilinks]]. The system could use multiple model providers, process images and PDFs, interact through Model Context Protocol connectors, execute scheduled work, delegate subtasks, and even construct additional MCP tools when an existing capability was insufficient. Significantly, the repository itself still acknowledged its ancestry: the product had become Atlas, while much of the internal Python package remained named jarvis.

V1 therefore solved the first problem I had encountered with Jarvis: continuity. A conventional chatbot is principally reactive. It receives an instruction, produces an answer, and, unless additional infrastructure is added, possesses little durable relationship with the work that preceded that interaction. Atlas instead treated memory, tools, communications, and scheduled actions as parts of the same system. In this respect, it resembled an old idea in computing more than a new one. In his 1945 essay As We May Think, Vannevar Bush imagined the memex, a system through which individuals could store information and build associative “trails” between related material. Bush even imagined a lawyer navigating connected opinions and decisions accumulated across professional experience. Atlas’s vault and wikilink architecture constitutes, in a modest contemporary form, an attempt to solve the same problem: information becomes substantially more valuable when a machine can preserve the relationships among pieces of knowledge rather than simply store isolated documents.

Atlas V2 shifted the project from persistence toward deliberation. Its central improvement was not a redesigned interface but a more sophisticated internal reasoning and retrieval architecture. The repository records a substantial transition: BM25 retrieval was supplemented by optional vector embeddings and Reciprocal Rank Fusion; linked notes could be expanded through their knowledge-graph neighbors; a single ReAct-style tool loop gained optional planning and verification passes; live execution events made the system’s behavior more observable; a goal loop enabled longer-running tasks; and Fable-based subagents could perform specialized work. The source tree reflects this expansion directly through dedicated modules such as graph.py, events.py, goal_loop.py, and fable.py.

The distinction is consequential. V1 could remember and act; V2 increasingly attempted to plan, retrieve, verify, and continue. Information retrieval, for example, ceased to depend solely upon whether a document contained the exact terminology of a query. Semantic vector retrieval could identify conceptually related passages, while graph traversal could recover neighboring information whose relevance arose from relationships rather than lexical similarity. This hybrid approach remains present in V3, whose vector engine fuses semantic embeddings with BM25 retrieval while degrading safely back to lexical search when an embedding model is unavailable.

Atlas V3 completed a more fundamental transition: from an assistant that could perform long tasks to infrastructure capable of remaining active between tasks. Even the internal package was finally renamed from jarvis/ to atlas/, marking the architectural separation from the project’s original identity. More importantly, V3 introduced an always-on heartbeat. The heartbeat operates as a background daemon, checking unresolved work, restarting interrupted goal runs, detecting repeated failures, and triggering workflows while preserving a global pause control and other safeguards.

The workflow system extends this persistence substantially further. A V3 workflow can be activated by an interval, cron schedule, webhook, WhatsApp message, heartbeat, or manual event. It can then execute a graph composed of agent calls, subagents, tools, conditional logic, notifications, and other actions. Runs are bounded by explicit step and time budgets and recorded for later inspection. V3 additionally developed a broader local workbench containing chat, code, terminal, dashboard, workflows, and files, while imposing control-plane restrictions intended to prevent the model from silently authorizing sensitive changes to its own configuration. The system was becoming less analogous to a chatbot and more analogous to a small operating environment for delegated intellectual work.

The practical significance of this progression became clearest when I considered Atlas in the context of a Korean labor-law practice.

Legal research presents almost precisely the information problem for which Atlas had gradually been designed. Korean labor law does not exist as a single webpage that can simply be handed to a language model. Relevant material is distributed across numerous governmental and legal databases. The National Law Information Center maintains statutory text, amendment histories, subordinate legislation, and multiple effective versions of statutes; the Ministry of Employment and Labor separately publishes policy materials, administrative information, and explanatory documents; and additional legal databases provide further access to legislation and translations. Even a single statute such as the Labor Standards Act exists within a changing legislative environment. As amendments enter into force at different times, legal research cannot safely rely upon one static copy of a law.

For a law firm, the bottleneck is therefore not simply access to information. It is continuous synthesis.

A conventional AI interaction might begin when an attorney manually collects several documents, uploads them, and asks a question. Atlas permits a different model. Subject to the access rules of each source, an always-running installation can periodically retrieve designated public sources, identify changed material, preserve the relevant documents in its knowledge base, connect new information with existing notes, and execute workflows that summarize or flag significant changes. Instead of requiring a researcher to repeatedly inspect numerous websites, the system can perform much of the repetitive collection and organization continuously, leaving the attorney responsible for the task that should remain human: legal judgment.

This distinction is essential. Atlas is not intended to replace counsel or independently determine what the law means. Statutory text, administrative guidance, and other legal materials do not become authoritative merely because an artificial-intelligence system has indexed them. Automated comparison and retrieval are methods of organizing evidence, not substitutes for determining its legal significance. The productive role of the agent is therefore narrower, but still substantial: finding, organizing, comparing, monitoring, and presenting evidence so that a human expert can reason from a stronger informational foundation.

This philosophy closely resembles J. C. R. Licklider’s 1960 conception of “man-computer symbiosis.” Licklider argued that humans should retain responsibility for goals, hypotheses, criteria, and evaluation, while computers perform the routinizable work necessary to prepare information for judgment. More than sixty years later, this is the model I find most compelling for Atlas. Its highest-value function is not pretending to possess professional judgment; it is reducing the mechanical burden surrounding that judgment.

Seen retrospectively, the development from Jarvis to Atlas V3 was therefore not a linear sequence of additional features. Each rebuild changed the fundamental boundary between user and machine. Jarvis was an attempt to imitate an assistant I had seen in fiction. Atlas V1 gave that idea persistent memory and tools. Atlas V2 gave it stronger retrieval, planning, verification, and goal-oriented behavior. Atlas V3 gave it continuity in time.

The Korean labor-law application reveals why that final distinction matters. When information is distributed, frequently revised, and too extensive for a person to monitor continuously, the most useful intelligent system may not be the one that produces the most eloquent response to a single prompt. It may instead be the one that quietly performs the unglamorous work of remembering what existed yesterday, detecting what changed today, connecting it with what was already known, and presenting the result when human judgment is required.

That is ultimately what Atlas became. I began by trying to build my own JARVIS. Through three iterations, however, I became less interested in reproducing a fictional artificial intelligence and more interested in answering a practical question: what would it actually mean for a computer to remain usefully present in someone’s work? Atlas is my continuing attempt to answer it.