DEV Community: Sophia Castillo

Everlogue: I Built a Book Catalog That Refuses to Trust Its Own Automation

Sophia Castillo — Mon, 05 Oct 2026 00:26:16 +0000

This is a submission for the Sanity Challenge, Path Two: Vibe-Code Something Strange

What I Built

I built Everlogue, a home for everything you read: a shared book catalog, private reading shelves, celebrity book clubs, and Ask Everlogue, a reading companion grounded in structured Sanity content.

But I did not want to build another Goodreads clone with a nicer frontend.

I wanted to answer a harder question:

What if the catalog could grow itself, while Sanity decided what was trusted enough to become shared content?

That led me to build Everlogue around multiple ingestion paths, with Sanity as the editorial control system.

Bulk / historical ingestion

Readers can import their Goodreads library. Everlogue parses the CSV, works through the books in the reader's library, matches or enriches metadata, and places books onto the correct Want to Read, Currently Reading, and Read shelves.

This gives a reader a way to bring an existing reading history into Everlogue instead of rebuilding it book by book.

Reader-grown catalog

Readers can also grow the shared catalog.

If someone searches for a book that Everlogue does not have and tries to add it to a shelf, that missing title becomes a catalog request for review.

Instead of every reader creating their own disconnected version of the same book, Everlogue can review the request and turn it into structured shared catalog content.

Continuous / live ingestion: Book Club Watch

The strangest ingestion path became Book Club Watch.

Everlogue follows Reese's Book Club, GMA Book Club, Read With Jenna, and Oprah's Book Club. Keeping those collections current sounds simple until you realize they do not announce their selections on the same schedule.

I modeled each club separately:

Reese
9 AM ET, days 1–8
Stop once the month's pick is already recorded

GMA
10 AM ET every Tuesday

Read With Jenna
9 AM ET Monday + Tuesday
Only during the early-month window

Oprah
9 AM ET Monday / Wednesday / Friday
Recurring checks because there is no fixed release pattern

A Sanity Blueprint deploys four Scheduled Functions to perform those checks.

But finding a title is not permission to publish it.

When Book Club Watch finds a potential selection, it creates a structured bookClubDiscovery document instead of creating a live book document.

The automation proposes.

The editor decides.

Another Sanity Function reacts to that editorial transition.

That distinction became one of the most important architectural decisions in Everlogue.

The catalog can grow itself without allowing an automated scraper to define shared truth.

The resulting catalog is also what powers the rest of Everlogue, including discovery surfaces and Ask Everlogue. I wanted the reading companion to feel like talking to a thoughtful friend in a bookshop, but its recommendations should come from books Everlogue actually knows about — not an invented shelf.

Demo

https://www.everlogue.app

Rather than a video walkthrough, I documented the workflow with screenshots showing the public app and the Sanity system behind it.

Code

https://github.com/sphcastillo/everlogue

The Book Club Watch infrastructure begins in:

sanity.blueprint.ts

The Blueprint defines:

1 Book Club Watch robot token
4 Scheduled Functions
1 approval-triggered Document Function

The core Watch implementation lives under:

src/lib/book-club-watch/

That code models club schedules, discovery state, source inspection, duplicate protection, approval state, and publishing.

Sanity Studio adds the editorial layer: Review Queue, approved/publication failures, rejected discoveries, published history, run history, and custom actions for the review process.

My Build Process

I built Everlogue with the help of Codex & Cursor, and the most productive prompts were not "build me a Goodreads clone."

They were small jobs with explicit constraints.

Things like:

Parse this Goodreads CSV, preserve the reader's shelf state, and do not create duplicate books we already own.

Check this official book-club source and create a discovery when something changes.

Never create a live book directly from the scheduled function.

Record the Watch run even when nothing changed.

Those constraints mattered because some of my first approaches were wrong.

The first bad assumption: one monthly cron

My first instinct was one Scheduled Function that ran once a month.

That did not survive contact with reality.

The four clubs have different announcement patterns, and Oprah does not have a dependable monthly date at all.

Instead of forcing those sources into one schedule, I modeled the release behavior itself as structured configuration and let each watcher decide whether the current check was meaningful.

The second bad assumption: discovery equals publication

Another early direction collapsed:

"We found the book"

into:

"Create the book"

I did not want that.

A title extracted from a webpage is evidence, not editorial truth.

I split the process into two systems.

Discovery proposes structured content.

Editorial approval publishes structured content.

A discovery moves through states such as:

discovered
↓
needs_review
↓
approved ─────→ published
│
└──────────→ rejected

Studio became the place where the human can inspect the title, authors, source URL, evidence, proposed metadata, existing-book matches, and publication mode.

Only approval allows the publishing function to react.

The publish trigger also checks that the discovery does not already have a catalog book, giving the workflow another layer of duplicate protection.

Going past Studio

The Blueprint became:

Book Club Watch
├── Robot Token
├── Reese Scheduled Function
├── GMA Scheduled Function
├── Read With Jenna Scheduled Function
├── Oprah Scheduled Function
└── Publish Approved Discovery

This is where I hit one of the biggest implementation problems.

My initial Blueprint stack was project-scoped.

The functions passed local tests, the Studio built, and the bundles compiled — but Sanity refused the deployment because Scheduled Functions require an organization-scoped Blueprint stack.

I had to promote the stack from project scope to organization scope before the cron resources could deploy.

That was one of the places where the AI-generated implementation was technically plausible but incomplete. The deployment environment exposed the missing constraint.

Local testing also fooled me

Another confusing moment came after a local test successfully found an Oprah selection.

The terminal showed a real result, but my Studio Review Queue was empty.

The reason was in my own runtime:

if (context.local) {
console.log(await discoverPicks(...))
return
}

Local Function tests intentionally exercised discovery without mutating the dataset.

That forced me to separate two things I had initially treated as the same:

Does source discovery work?

and:

Does the deployed cloud workflow write the correct editorial state?

I then tested the actual deployed cron against a development dataset.

That run discovered Little Wonder by Sophie Chen Keller from an official Oprah source and created a real bookClubDiscovery with:

bookClub
discoveredTitle
discoveredAuthors
selectionMonth
selectionDate
sourceUrl
sourceEvidence
identity
matchExplanation
status

Its status was needs_review, exactly as intended.

Development before production

I eventually standardized Everlogue around two datasets:

development
production

Book Club Watch was first enabled against development.

For testing, I temporarily accelerated the Oprah schedule so I could observe a real cloud execution instead of waiting several days for the normal schedule.

Once I verified the full flow, I restored Oprah's real Monday / Wednesday / Friday schedule.

Before enabling Watch against production, I exported the entire production dataset — 1,644 documents and 327 assets — and added another Blueprint safeguard:

Production cannot run enabled
unless WATCH_PRODUCTION_VALIDATED=true

Only after the development workflow passed did I deploy the production version.

Failure states became part of the product

The final system does not pretend external systems always work.

Book Club Watch records run history and distinguishes outcomes such as:

no change
already recorded
skipped
failed
discovered

Studio keeps rejected discoveries, publication failures, and publishing history instead of hiding them.

One of the live sources returned an HTTP 500 during testing. Google Books enrichment was also unavailable during one discovery.

Neither condition was allowed to silently create bad catalog data.

The result is the part of Everlogue I like most architecturally:

automation can inspect the web and propose structured state, but it does not have unilateral authority over the shared catalog.

The machine proposes.

The editor decides.

Sanity connects the two.

Sanity Project Details

Project ID: 3h0o1unw

Production dataset: production

The production dataset is private because Everlogue contains reader-specific data and internal editorial state.

Book Club Watch was validated against the separate development dataset before production enablement.

Sanity is used for much more than page content in Everlogue. It holds the structured book catalog and editorial content while Studio, Scheduled Functions, Document Functions, Blueprints, and custom document actions form the operational layer around that content.

Everlogue’s Reading Companion - a book recommendation agent grounded in structured Sanity

Sophia Castillo — Sun, 04 Oct 2026 23:27:32 +0000

This is a submission for the Sanity Challenge, Path One: Ship an Agent That Queries Real Content

What I Built

Everlogue is a home for everything you read. It brings together a book catalog, private reading shelves, celebrity book-club selections, and Ask Everlogue, a Reading Companion grounded in structured Sanity content.

The catalog began with selections from four clubs: Reese’s Book Club, Oprah’s Book Club, Read with Jenna, and GMA Book Club. From there, it grows through its readers.

Readers can import their Goodreads CSV files to bring over their Want to Read, Currently Reading, and Read shelves. They can also search for a book and add it to an Everlogue shelf. If that book isn’t already in the catalog, the addition creates a request for review. Once reviewed and approved, the book joins the shared catalog and becomes available for discovery and recommendations.

That growing catalog is the foundation of Everlogue’s Reading Companion. I wanted it to feel like talking to a thoughtful friend in a bookshop—someone who listens to what you want today and helps you find something you’ll enjoy.

When a reader asks, “What should I read next?”, the companion starts with:

What are you in the mood for—or what’s a book you loved and want something similar to?

Their answer guides the search across the full approved Everlogue catalog, including suitable books on their Want to Read shelf. For signed-in readers, books already read or currently being read are excluded. The companion returns three recommendations with short, personal, spoiler-free explanations, grounded in books that actually exist in Everlogue.

For readers who want to explore a book further, I established a Sanity Context Knowledge Base using six website sources containing book-club announcements, summaries, and author interviews. I reviewed the generated entries covering book premises, themes, club selections, and author conversations, checked their citations, and made corrections.

I then configured a dedicated MCP endpoint, Everlogue Book Knowledge, so the companion could retrieve supporting material for questions about books. Its instructions require sources for factual claims, discourage unnecessary spoilers, and keep the conversation warm and natural. I selected OpenAI gpt-5.4-mini as the starting model.

The two sources serve different purposes: the structured catalog determines which books the companion can recommend, while the knowledge base supports deeper, source-backed conversations about them.

As readers contribute more books and those additions are approved, Everlogue’s catalog grows—and the Reading Companion gains more possibilities to help someone find their next read.

Demo

https://www.everlogue.app/

Code

https://github.com/sphcastillo/everlogue

The companion lives in:

src/lib/companion-agent.ts — recommendation path vs Sanity Context MCP path
src/lib/companion-catalog.ts — GROQ catalog search, shelf exclusions, Want to Read
src/lib/companion-selection.ts — interpret the request, pick three supported candidates
src/app/api/companion/route.ts — authenticated shelf context, then the agent
docs/reading-companion.md — how Context and recommendations are wired

How I Used Sanity

Building the Knowledge Base

I added six website sources containing book-club announcements, summaries, and interviews to Sanity Context. The generated entries covered book premises, themes, selections, and author conversations. I reviewed the generated content, investigated citations, and made corrections rather than treating ingestion as the end of the editorial process.

I created a dedicated Everlogue Book Knowledge MCP endpoint. The companion’s instructions emphasize factual support, a warm personal tone, and avoiding unnecessary spoilers.

For Knowledge Base questions, the server connects through an MCP client and gives the model the tools exposed by the endpoint:

initial_context establishes how to navigate the Knowledge Base.
knowledge_base_search finds relevant entries.
knowledge_base_read retrieves supporting content.

The agent must retrieve content before answering. Its instructions require it to ground book facts in that retrieval and cite source titles and URLs it actually used. Responses stream into the existing companion interface. The Context token stays on the server, and the MCP connection closes when the response finishes or is interrupted.

In an end-to-end check, I asked about The Christie Affair. The companion called the Context tools, identified Nina de Gramont, and returned a source-backed answer. I checked tool activity as well as the text of the response.

Connecting knowledge to a reader’s library

The companion uses two complementary content paths. Knowledge Base questions go through Sanity Context MCP. Recommendations query the structured catalog directly with GROQ through @sanity/client.

That distinction matters: a book does not need an ingested article or Knowledge Source link to be recommended. A reader-imported title can qualify through its catalog description and genres. Article-backed answers use retrieved sources; catalog-based recommendations do not invent article citations.

Sanity stores the relationships that make personalization possible: books and genres, reader profiles, shelves and shelf entries, ratings, and reviews. Optional page-count and series information support explicit constraints when that information is available. The authenticated reader’s identity determines which shelf entries and feedback apply.

The recommendation flow interprets the request, retrieves eligible candidates, selects up to three, and writes short explanations from the supplied metadata. It combines the reader’s current mood with structured eligibility checks and their own feedback. Missing metadata is not permission to invent a fact.

What I worked through while building

Much of the work was deciding what “helpful” should mean. We refined rules around low ratings, current preferences, series order, repeated suggestions, and the difference between a contextual book mention and a request for something similar.

I also kept the model and added measurement: per-question token counts, cached input, estimated cost, duration, and outcomes are saved in Sanity. Daily usage limits and smaller, relevant context help prepare the companion for visitors. Two live test questions recorded about $0.015 combined in estimated model cost—a small test sample, not a forecast.

Testing the surrounding experience mattered too. A first-sign-in failure exposed a profile-resolution problem after Clerk authentication. We changed setup to use the profile returned by Sanity’s creation transaction and made retry lookups bypass request memoization. We also moved homepage personalization behind separate loading boundaries and parallelized independent queries, keeping library data fresh.

The final hurdle was to make it clear what circumstances the reader companion should ask the knowledge base over the catalog. Also, we had to make sure source names and URLS are stripped from replies, and strip filler like “the book” from catalog lookups so “Tell me about the book The House in the Pines” searches the real title instead of a phrase that isn’t in the catalog.  

I know I'll still be tinkering with it, but I'm currently really happy with today's Ask Everlogue.

Sanity Project Details

Project ID: 3h0o1unw
Dataset: production (private)
Organization Context endpoint: Everlogue Book Knowledge (everlogue-book-knowledge)

The dataset contains reader information, so I am sharing the project ID rather than making the dataset public. The Context endpoint uses a server-side organization token with Context → Viewer permission.

Agent Session

I worked with Codex & Cursor to turn the reading experience into implementation rules, connect the MCP endpoint, verify retrieval, and test edge cases. The most useful parts of that process were tracing where an answer came from and deciding what the companion should do when information was missing.

Credits

Built with Sanity Content Lake, GROQ, Sanity Studio, Sanity Context, next-sanity, the Vercel AI SDK MCP client, OpenAI gpt-5.4-mini, Clerk, and Next.js.