Colin Sidberry

Writing Agent

An AI pipeline for personalized learning.

The problem

As a software engineer, learning is the name of the game. There's always a new technology to pick up. There's always a best practice to sharpen. There's always some fundamental you've been meaning to actually understand.

However, docs, textbooks, and resources aren't always written in ways that work best for my brain.

It would be great if there was an AI tool that could capture the style I learn best from and consistently translate new material into it, basically a personalized education workflow. That's what this is.

What it does

Writing Agent takes the raw source material for a topic, your lecture notes, a textbook chapter, scattered scratch work, and runs it through a fixed sequence of stages. Each stage is one focused LLM call, and its output is saved before the next stage begins. Nothing is a black box: every intermediate artifact lands in MongoDB, so you can open any step and see exactly what the model produced.

Sourcesingest notes, PDFs, scratch work
Keywordspull out the key terms
Outlinestructure the article
Invariantslock down what must stay true
Analogiesbuild intuitive explanations
Draftwrite the full article
Reviewself-critique and polish
MongoDB
MongoDB
every stage's output is saved as an inspectable artifact
one LLM call raw input persisted to MongoDB

Why a workflow, not a ReAct agent

I opted for an AI workflow because the job has deterministic steps: a fixed order I always want to run, with AI inference at specific points inside it (the pipeline above). The order is mine, not the model's.

A ReAct agent, the pattern where the model decides its own next move in a loop, earns its keep when the task is open-ended and has to be fully autonomous, say a support chat like Zendesk where you can't script the path ahead of time. Here the path is known. Fixing the stage order myself makes the whole thing reproducible, easier to debug, and cheaper, since no tokens are burned deciding what to do.

Architecture

The whole thing is split so the public demo has no backend dependency. The Next.js app on Vercel reads MongoDB directly through API routes, so the Live replay and Database viewer work even when the generation backend is asleep. A FastAPI service in a slim Docker image on Render handles ingestion and live generation runs. MongoDB Atlas stores every artifact, kept warm by a scheduled GitHub Action.

For the models: I run Anthropic locally during development, Groq powers public live runs, and bring-your-own-key support lets anyone point a run at their own provider.

Frontend
Next.js
Next.js
React
React
Tailwind
Tailwind
Backend
FastAPI
FastAPI
Python
Python
Docker
Docker
Data & hosting
MongoDB
MongoDB
Render
Render
Vercel
Vercel
LLM
Anthropic
Anthropic
Groq

What I'd build next

An automated editor loop. It would mine my own edit history, the changes I make to the model's drafts, to critique and revise each draft before I ever see it. Over time those critiques feed back into the earlier stages so the first draft already reads like something I'd ship, pushing the whole pipeline toward one-shot generation.