lite · Structural Essence
What this diagram shows
Four ways work enters NAVis, one thing that happens in the middle, one place where anything real ends up. Strip anything else and this is still recognisably NAVis.
The one sentence
NAVis is an agent that runs on a server I own, reachable from my browser, my phone, on a schedule — all three going through the same loop — and directly from my keyboard when I need to check whether the loop actually did what it claimed.
The three paths that use the agent
Webchat: me in a browser, typing. Telegram: me on my phone, messaging. Cron: no human at all — a scheduled job that triggers itself at 04:00. All three enter the same agent loop. That loop does four things: read my identity and memory, think with an LLM, act via tools or skills, reply and write things down. It can loop through step 2 and 3 multiple times before finishing.
The fourth path that doesn't
Terminal: me SSH'd into the server, typing Linux commands directly to the filesystem. No LLM, no agent, no prediction — the file either exists or it doesn't. This is how I verify the other three paths actually did what they said they did.
Why the filesystem is singled out
The LLM can say "I wrote the file" without issuing the tool call that actually writes it. The filesystem can't lie. It's the one layer with no model in front of it. That's why the diagram puts it on its own side, and why the agent loop has an arrow going to it — the loop reads from it, writes to it, but doesn't get to edit it in its head.
What I deliberately left out
Ports, sockets, Tailscale internals, the distinction between the gateway process and the loop it hosts, the split between the webchat UI and the chat API, Telegram long-poll vs webhook, concurrency issues, cost splits. Those belong in the technical diagram. This one is for remembering the shape.