LOG // The Current State of Atlas: A Human Interface for Knowledge Graphs and AI Agents

When I wrote What Is a KEG?, the shared version of the system was still the next frontier. My KEGs worked well as local, file-backed graphs, and Tapper gave me a CLI and an MCP server for working with them. What I did not have was a good way for multiple people and AI agents to use the same KEG without sharing a filesystem or coordinating Git pulls.

Atlas is the human-facing part of my answer to that problem.

It is no longer just an idea or a mockup. I can use it to navigate and administer hosted KEGs, edit nodes, inspect relationships, and control the bounded contexts that agents use. The underlying architecture is coherent enough that the browser, CLI, REST API, and MCP server can all work with the same knowledge model.

It is also still evolving. Some large pieces are mature, some substantial changes are verified candidates rather than shipped releases, and search and discovery still have known gaps. This is a progress report, not a launch announcement.

Update (October 2026): For a map of how the pieces fit together, including the chat assistant and the relay that lets my own machines lend models and Claude Code to Atlas, see Atlas Architecture: A High-Level Overview.

Atlas, Tapper, and Tapper Hub

The names are easy to blur together, so the boundaries matter.

Tapper is the KEG engine and command-line tool. It defines the operations I expect from a knowledge graph: creating and reading nodes, editing content and metadata, following links and backlinks, querying tags and attributes, managing schemas and indexes, and preserving snapshots. It can operate on a local KEG, and its MCP server gives agents a purpose-built interface instead of asking them to manipulate storage directly.

Tapper Hub is the hosted service. It adds the parts that do not exist in a single-user filesystem: accounts, authentication, namespaces, a catalog of KEGs, grants, public and private visibility, PostgreSQL persistence, and caller-scoped REST and MCP endpoints.

Atlas is the web application inside Tapper Hub. It presents those capabilities to a person in a browser. It does not own the graph’s business rules, authorization model, or persistence. That distinction has become one of the most useful architectural constraints in the project: Atlas is a delivery surface, not the backend with a nicer name.

  flowchart LR
    human["Human browser"]
    cli["Tapper CLI"]
    agent["AI agent"]

    subgraph hub["Tapper Hub"]
        direction LR

        subgraph delivery["Delivery surfaces"]
            direction TB
            atlas["Atlas<br/>HTML + HTMX"]
            rest["REST API"]
            mcp["MCP"]
        end

        identity["Identity + namespaces + grants"]
        flights["Flights + orientation"]
        operations["Shared Tapper<br/>KEG operations"]
        repository["PostgreSQL<br/>KEG repository"]

        atlas --> operations
        rest --> operations
        mcp --> operations
        identity -. "authorizes" .-> operations
        flights -. "bounds" .-> mcp
        operations --> repository
    end

    human --> atlas
    cli --> rest
    agent --> mcp
    repository --> database[("PostgreSQL<br/>+ pgvector")]

Atlas, REST, and MCP are separate delivery surfaces over the same hosted KEG operations. Identity defines the outer access boundary; flights narrow the authority available to an agent session.

The architecture overview goes deeper on each of these boxes, along with the parts this diagram leaves out: chat, the relay, and how Atlas is deployed.

The Architecture Today

Tapper Hub is a Go service. Atlas uses server-rendered Go templates for its pages and forms, with HTMX layered on top for targeted updates. A normal link or form submission remains the baseline behavior. When JavaScript and HTMX are available, the same workflows can update a list, rail, toast, or editor region without replacing the whole page.

That tradeoff has been huge for Atlas. Every route still arrives as complete HTML, which gives search engines useful content and gives the reader a working page before JavaScript runs. HTMX then replaces only the regions that changed. Persistent interface elements—especially the chat bubble—stay mounted as I move through the application, so they keep their state and avoid the flicker and graphical glitches that come from rebuilding the whole page after every navigation.

PostgreSQL stores the hosted catalog and KEG state. The persistence layer includes node content, metadata, statistics, schemas, generated indexes, attachments, snapshots, and access-control records. pgvector is available for vector data, although the current product still relies heavily on direct lookup, structured filtering, links, backlinks, and text search. I am treating semantic retrieval as another discovery tool, not as a replacement for explicit graph structure or authorization.

The most important boundary sits above storage. Web handlers, REST endpoints, CLI clients, and MCP tools should call shared KEG business operations. They should not each reimplement what it means to edit metadata, resolve a node, rebuild an index, or check access. That lets a local KEG and a hosted KEG present compatible behavior even though their storage and transport are different.

The catalog wraps those operations in a multi-user model. A namespace groups ownership. A KEG can be public or private. Membership and explicit grants determine which private KEGs a caller can reach, while roles cap what that caller can do. Flights add another restriction for agents; they never expand the permissions of the authenticated identity beneath them.

The Human Workspace

Atlas has grown from a set of administration pages into a contextual workspace.

At the broadest level, it covers account, namespace, flight, KEG, schema, index, node, sharing, archive, and settings workflows. The application shell keeps the current namespace, KEG, or node visible while route-specific content occupies the main workspace.

The current workspace design uses contextual rails. The left rail is personal navigation: pinned namespaces and KEGs, pinned notes for the current KEG, and configured custom indexes. The right rail changes with the task. On a KEG page it can show KEG facts or settings navigation. On a node page it can show frontmatter, tags, backlinks, images, and files without pushing the note itself out of the primary reading position.

The node workspace carries the same context across View, Edit, Images, Assets, Stats, and Actions tabs. Markdown editing is separate from metadata editing. Frontmatter has form and YAML views, with schema-aware controls when a schema exists and a generic fallback when it does not. Tags are edited independently. Backlinks and attachments remain visible as context instead of becoming separate scavenger hunts.

Pins are personal rather than properties of the shared note. That sounds like a small detail, but it fixes an important modeling error: my shortcut to a node should not change how everyone else sees that node. Public stars remain a separate discovery signal.

The large contextual-workspace revision is released as of August 14, 2026. It shipped with Go and PostgreSQL-backed coverage for the new workspace behavior while preserving the REST, MCP, and KEG-operation contracts beneath it.

Responsive behavior and accessibility are structural requirements in this design. Desktop rails can collapse and resize. On small screens they become drawers with keyboard and focus management. The shell keeps one main landmark, supports skip navigation and reduced motion, and retains ordinary links and form fallbacks. Themes use a centralized palette model with automated contrast checks. Production assets are deterministic, fingerprinted, and served with cache-aware URLs.

The Agent Control Plane

The other half of Atlas is less visible but more consequential: flights.

A flight is a bounded work context for an AI agent. It selects which KEGs are in scope, caps the role available in each one, and supplies instructions for the session. The authenticated account still defines the outer permission boundary. A flight can narrow authority; it cannot manufacture access the account does not have.

Orientation is the point where that authority becomes active. An agent does not silently adopt a changed flight halfway through a call. It explicitly orients, receives one complete context, and uses that immutable context for the operation already in progress. Later calls can use a newly oriented context. If refresh fails, the prior valid authority remains intact; an intentionally blank selection enters a restricted recovery state.

That explicit boundary solved a real design problem for me. Agent hosts preserve conversations, working trees, and other live state, so changing a flight should not require destroying and recreating the entire session. At the same time, a shared process-wide variable is too weak an authority model. Session-scoped orientation lets separate agent sessions adopt changes independently without leaking authority between them.

Recovery also stays grounded in the graph. Tasks, plans, decisions, handoffs, and evidence are ordinary typed KEG records. They survive the agent process that created them and can be interpreted again later. Atlas does not need to invent a second, product-specific memory system for every agent host.

This is where the human and agent sides meet. A person can use Atlas to manage a KEG and define a flight. An agent can orient to that flight and operate through MCP. Both work over the same nodes, metadata, schemas, links, snapshots, and access rules.

What Is Mature, and What Is Not

The hosted foundation is usable today. Authentication, namespaces, public and private KEGs, membership and grant scoping, PostgreSQL-backed KEG operations, and caller-aware REST and MCP surfaces are established parts of the system. KEG and node discovery exist across the browser, CLI, and MCP, even though their projections are not yet identical.

The flight lifecycle is one of the more mature architectural pieces. Explicit orientation, session isolation, recovery behavior, and the intersection of flight roles with identity permissions have focused and race-sensitive verification behind them.

The browser work has substantial automated coverage as well. Go tests cover handlers, templates, assets, themes, progressive fallbacks, and accessibility structure. PostgreSQL-backed suites exercise persistence and authorization paths. The released workspace adds broad coverage for pins, custom indexes, rails, node tabs, metadata editing, backlinks, responsive containment, and live-update protection.

Several gaps are still open:

• Global search cannot yet treat a pasted KEG or node address as navigation. Its node matching is still too literal and does not consistently include titles and metadata.
• Live node updates have needed additional protection against stale connections repainting the wrong page after boosted navigation. A verified candidate exists, but it is not published yet.
• Listing fields and ordering differ among web, CLI, and MCP surfaces. Some discovery views include information that others omit, and user-controlled ordering is incomplete.
• More work remains around discovery and pin ordering, especially where paging and changing ranks interact.
• The final authenticated Lighthouse audit against a genuinely large KEG has not been collected. Code-level accessibility, asset, theme, and layout checks pass, but I will not turn those into a browser-performance claim until the browser evidence exists.

Lessons So Far

The strongest lesson has been to keep business operations independent of delivery surfaces. A browser route may need a very different presentation from an MCP tool, but both should agree on what a KEG operation means. When that boundary holds, I can redesign Atlas without destabilizing the agent or CLI contracts.

Progressive enhancement has had the same architectural value. Starting from server-rendered documents and ordinary form behavior forces the workflow to exist somewhere concrete. HTMX can then improve the interaction instead of becoming the only place where the interaction is defined.

Accessibility works best under the same rule. Landmarks, headings, focus movement, touch targets, overflow ownership, and reduced-motion behavior are not cleanup tasks for the end of a redesign. They influence the shell and component boundaries from the start.

For agents, authority needs to be explicit and session-scoped. Convenience mechanisms that silently rewrite a running session are difficult to reason about and even harder to test. Orientation gives the transition a name, a boundary, and failure behavior.

Finally, the graph is most useful when it holds durable shared context rather than merely archived notes. A node can describe current state, a decision, a planned change, a verification contract, or a handoff. Links make the surrounding reasoning recoverable. That is valuable to me as a human, and it is the same property that makes the system useful to agents.

Where Atlas Goes Next

The immediate direction is better search and discovery: address-aware navigation, multi-term matching across titles, content, and metadata, consistent ranking, and tighter agreement among browser, CLI, and MCP listings.

I also want to close the remaining browser validation. The tests tell me that the intended mechanics exist; a clean authenticated Lighthouse run on a large KEG will tell me how the integrated page behaves under the workload that motivated the work.

Beyond that, Atlas will keep moving toward a single workspace where knowledge management and agent workflows are not separate products. Humans should be able to see and shape the context an agent receives. Agents should leave behind structured work that a human can inspect, revise, and reuse.

The file-backed KEG started as a way to stop losing scraps of thought. Atlas is what happens when that graph has to become shared, authenticated, and understandable to more than one kind of reader. It is usable now, and the architecture finally feels like it has the right seams. I am still discovering what those seams make possible.