Skip to content
JC.
All writing

· 3 min read

Building an Admin Instead of Editing the Database

The first version of the admin did one thing. It showed me the documents the website agent knew about. That turned out to be enough to change how I worked.

A simple admin screen on a blueprint grid, with a sidebar where only "Documents" is active and a table listing documents by type - product, policy page, manual and project plan - each with its source. Faded sidebar items below it are labeled "later."

The admin started with one question: what does the agent actually know?

At the end of the last post, I'd decided to stop digging through the database every time I wanted to understand what was going on. I needed somewhere I could open up, take a quick look and get an answer.

What I didn't do was sit down and design the perfect admin. I had a long list of questions I wanted it to answer someday. I started with the first one.

Picking the tools

The website agent itself was built on Node.js and Express, with PostgreSQL behind it. For the admin, I went with React and Vite.

It's the same thinking from the PostgreSQL post. These were tools I already knew how to work with. I wasn't trying to learn a new front end while I was also learning AI. The admin was supposed to make my life easier, not become its own research project.

Just the documents

The first version showed documents. That's it.

Every product page, policy page, manual and project plan the agent had ingested, listed in one place. What kind of document it was. Where it came from. Enough to look at the list and say, "Okay, that's what it knows."

It sounds almost too simple to write about. But I hadn't been able to do that before without writing a query. And the first time I scrolled through that list, I noticed things I'd never have spotted in a terminal. Documents I didn't expect to see. Gaps where I expected something to be. The shape of the whole thing, all at once.

Answering "what does the agent know?" without opening the database felt like a bigger step than it should have.

Instead of editing the database

Before the admin, any change meant going straight to the database. Want to check a document? Query. Want to fix something? Update a row by hand and hope I didn't miss anything connected to it.

That works when you're the only one touching it and you remember how everything fits together. It gets riskier every time the system grows. And it had grown a lot.

Having a screen in front of the data changed how I thought about it. The database stopped being the place where I worked and went back to being the place where things were stored. The admin became the way in.

The rest of the list

The questions from the last post didn't go away just because the first screen existed:

  • What does the agent know?
  • Where did this information come from?
  • Is this document still active?
  • What chunks came out of it?
  • Why did it give that answer?

The first version answered the first one, and part of the second. The rest became the to-do list. And honestly, that's how the admin grew from then on. Every time I caught myself going back to the database to answer a question, that question became the next thing the admin needed to show.

An experiment you can't see inside isn't a system yet.

The next problem

Once I could see everything the agent knew, something else became obvious.

I could also see what it didn't know. And some of what was missing wasn't missing because I'd failed to crawl it. It was never on the website in the first place.