It started the same way many of my engineering mistakes begin: with a beautifully over-designed document. I had spent hours writing a lengthy, thoughtful Product Requirements Document (PRD) for our Model Context Protocol (MCP) integration, pages of flows, diagrams, UI sketches, phased rollouts, failure cases, subsystems, and even a multi-stage "extraction theater" where users would watch agents reason in real-time.
Having already been in situations where I jumped into projects with no clear idea of what I was supposed to do, I wanted this time to get everything right upfront. As a first-year AI Engineer juggling both backend and frontend work, I overcompensated: I tried to plan the entire system at once, designing multiple flows and features before even knowing what users actually needed.
The PRD was impressive. It was also completely disconnected from what anyone actually needed.
I realized this during a design review when someone on the team asked, "Wait, why do we need conversation memory for this?" I started explaining the elegant multi-turn agent system I'd planned, and halfway through my answer, I heard how ridiculous it sounded. Users weren't asking for a conversational AI experience. They just wanted to grab a Notion page, pull it into our test generation tool, and move on with their day. That was it.
That question punctured the whole thing. I'd built an elaborate solution to a problem that didn't exist.
Before I shifted my mindset, the first design looked like a control room for the agent. I was chasing “perfect context” because, in theory, the richer the knowledge we provide the model, the better the test cases it can generate. Without enough context, outputs can be shallow or inaccurate. (For readers curious about the work we are doing at Rhesis, the docs are a great resource: rhesis.ai/docs.)
Part of that push for perfect context came from the technical side too. We chose MCP mostly because it was easier to implement than building a bunch of custom APIs, and because it gave us room to grow. With MCPs, we could pull in Notion pages and GitHub files right away, but we could also imagine future actions like creating Jira tickets or updating docs, all through the same interface. That flexibility made the system feel more ambitious than it needed to be at the MVP stage.
And ambitious it was. The plan included a React-style agent that would reason, act, and observe iteratively across multiple LLM calls. The frontend would be split-screen, showing live agent reasoning on the left and a Markdown preview on the right, complete with streaming updates and execution history. Users could start a conversation with the agent, refine queries in multiple steps, stage multiple sources, and save them selectively.
The system required multiple endpoints, custom SDK methods, Pydantic schemas, database updates, and separate Agent classes per server. On paper, it looked smart and elegant, but it was solving problems that didn't exist yet.
The MVP was a single, simple modal where users could search for a Notion page or GitHub file, enter a query, extract it, and save it as a source. No conversation memory. No streaming. No multi-source staging. Only the bare minimum endpoints.
Users loved it.
That contrast was humbling. I'd spent days planning features nobody asked for, when what they actually wanted could be built in an afternoon.
Here's what surprised me most: stripping away the complexity didn't just make the project faster, it made me more confident. With the simpler version, I knew exactly what I was building and why. Every line of code had a clear purpose. There was no guessing about whether users would want "agent conversation persistence" or "multi-stage extraction workflows." I was building exactly what they'd asked for.
The lesson wasn't "don't build complex things." It was "earn your complexity." Ship the simple thing first. Let real usage show you where the friction is. Then and only then add the sophistication that actually matters.
Complexity can always be added later. But unnecessary complexity? Nearly impossible to remove once it's baked in.
With the core MCP integration in place, the next steps involve thoughtful, measured improvements, making extraction more reliable, adding support for additional sources, and streamlining the workflow. Every change comes from a real need, not a hypothetical one.
Eventually, we might explore richer agent insights or advanced batching, but only when users ask for it.
For now, I'm asking a different question before I write my next PRD: "What's the smallest thing that could possibly work?" It's not as exciting as designing the perfect system. But it ships faster, works better, and saves me from my own cleverness.
And that's worth more than any elegant architecture diagram.
Want to see what we're building? Check out the simple MCP integration (and the rest of our test generation platform) on GitHub: github.com/rhesis-ai/rhesis. We're focused on shipping things that work, one small feature at a time.
Rhesis AI
Collaborative Gen AI testing.