Himalayan Trust

The starting point

Two problems, both the same shape underneath.

The Trust has five decades of photography from Nepal. Finding a specific image meant someone who had been there remembering roughly when it was taken and scrolling. The archive was an asset that behaved like a shoebox.

Separately, quarterly board reporting meant assembling the same numbers from the same places every quarter, by hand, under time pressure.

Both problems look like AI problems. Neither of them is. They are access problems. The useful question was not "can a model do this" but "what exactly should a model be allowed to reach, and what should it never be able to touch".

What we built

A semantic image search server. It indexes the photo archive and lets you ask for what is in a picture rather than what the file is called. Embeddings are generated locally and stored in a FAISS index alongside a SQLite metadata store, with EXIF details (camera settings, dates, GPS) pulled out during indexing. It runs entirely on local hardware with GPU acceleration on Apple Silicon and NVIDIA, and the images never leave the machine.

The part that took the real work was the archive being cloud-synced. Most of it lives as online-only placeholders in OneDrive rather than on disk. Change detection reads placeholder metadata instead of file contents, so reindexing never re-downloads a library it has already seen. Indexing is incremental, and a scheduler keeps it current without anyone remembering to run it.

A board report server. It sits over the Trust's KPI Hub, a Next.js application on Vercel, and exposes two tools: one that returns the structured quarterly metrics and chart series, and one that produces the export bundle. Quarterly reporting stops being an assembly job and becomes a question you ask.

The boundary is the design

Both servers are read-only. The image server can search, describe and reindex; it cannot alter a photo. The board report server issues GET requests against defined API routes; there is no write path to the underlying data, by construction rather than by policy.

That is deliberate, and it is the part worth copying. An agent connected to a system of record is only as safe as the interface you hand it. Scope is not a setting you enable afterwards. It is the shape of the server you build, and the easiest time to get it right is before anyone is relying on it.

The same logic runs through the smaller decisions. The image server keeps the archive local because there was no reason to move it. The board report server fails loudly with a clear error when it has not been told where the KPI Hub lives, rather than guessing at a default and quietly reading the wrong thing.

What made it work

Neither server is clever. Both are narrow, and narrow is what made them safe enough to leave running.

The instinct with this technology is to connect everything and see what happens. The better instinct is to decide first what the agent is for, give it exactly that much reach, and make the boundary something you can point at. A charity with a fifty-year archive and a board that needs its numbers on time does not need a general-purpose assistant. It needs two specific doors, and to know precisely what is behind each one.