Building Groundwork: A reference agent in 2026
I’ve been building AI agents in traditional web apps for a while now. They come with their own set of challenges that anyone building a local application gets to waltz right past. Now that I’ve shipped them to production on two teams - I have lessons I’d like to share.
The problem is where those lessons live. Most of them are locked inside code that could never be shared. I have ideas across the entire stack - and nowhere to test them.
So that’s what I’m building.
What are you talking about?
Groundwork is an opinionated, working reference implementation for an AI agent hosted in a traditional web application. It has a typical React SPA interface, a standard REST API, and a common authentication model.
It will serve as my playground moving forward. I want to build it from the ground up - from a basic chat completion to a sophisticated harness - and write about what I learn along the way.
No slideware. No “left as an exercise for the reader.” No hello-world bullshit that barely translates to your work.
Why a data agent?
Integrating with data is an interesting niche that tracks alongside my day job. I am, after all, hoping to learn something new to take back to work 🙂. So the first iteration will be simple: accessing and querying a database efficiently.
The largest and most familiar open-source dataset I found was deps.dev - Google’s map of open-source packages and their dependencies, sitting in BigQuery with generous free-tier limits. This may change later - but it’s a great starting point.
The bar I’m reaching for looks something like OpenAI’s write-up on their in-house data agent. I’m not there. Not even close. That’s kind of the point 🙂
What I want it to demonstrate
Advanced backend and data techniques. Grounding answers in actual query results. Giving the agent context. Handling failures like an adult.
Real-world evaluation. I’ve spent weeks studying this - working in the dark - and I have opinions coming out of it. (A few of them already made it into LLM Evals Are Just Integration Tests.) Every improvement in Groundwork gets measured against where it started. You get to see how I structure the tests - and where it fails.
Advanced agent user experiences. Like sophisticated tool calling and grouping. You’ve seen the patterns in popular interfaces - but nobody has demonstrated a fool-proof approach yet, because at the time of writing this, it isn’t a native feature. I scratched the surface of why this is hard in Your Team Wants to Copy ChatGPT.
The possibilities are endless
- An MCP client - hooking in outside data/integrations and handling the complexities with authentication.
- An MCP server - exposing its own API to outside clients (and again, handling the authentication fun).
- Evaluating RAG techniques with real-world data - showing them side-by-side.
- I’ve tried a dozen different things. I get a little triggered when people just want to toss the whole knowledge corpus into a vector database and check the box. Let’s prove why that does/doesn’t work.
- Evaluating harness design decisions:
- AI SDK today - but what happens if I change later? How do they compare?
- Durability and conversation storage.
- Sandboxed (remote execution) vs. traditional agents.
I’ll be honest - this list makes my inner Grug a little nervous. Not all of it will get built. But every item is a question I actually want answered, with evidence instead of vibes.
How I’m going to write about it
This isn’t going to be a polished, ten-part series. Some posts will be tidy. Some will be notes. This one is the root - and I’ll come back and tend it as my thinking changes.