Mini-me
Personal Assist AI Agent
I designed and built Mini‑Jasper, a live portfolio and recruiting MVP that combines structured knowledge, retrieval, safe answer behavior, and lightweight analytics.
It tests the broader Mini‑Me vision: a bounded personal AI agent that handles repetitive first-contact questions, provides trustworthy information, and helps people decide whether to begin a real conversation.
My Role
Lead AI Product Designer & Builder
Status
Live Product
Stack
Next.js, React, TypeScript, LLM, Retrieval, Structured Knowledge, Analytics
Ownership
Product Strategy, AI UX, Knowledge Architecture, System Design, Implementation, Validation
01 Defining the Role of a Personal AI Agent
Overview：Mini‑Me started from a product question: where should a personal AI agent participate, and where should it step aside? This section defines the communication gap Mini‑Me is designed for: repetitive first-contact questions that need trustworthy answers, but not deep human judgment.
01-1 The Communication Gap
Meaningful professional relationships require human conversation. Yet reaching that conversation often begins with repetitive, factual exchange. Mini‑Me handles this first layer so people can spend their time on questions that require context, judgment, and human connection.
01-2 Where a Personal AI Agent Should Participate
Mini‑Me leads when information is repeatable and verifiable, supports relevance exploration, and hands off when context, judgment, or relationship-building becomes central. ⬆
01-3 A Bounded Personal Agent
A personal AI agent becomes useful not by doing everything, but by clearly defining what it can answer, what it can support, and when it should step aside. The following chart outlines the principles that guide Mini‑Jasper’s behavior and define its boundaries.
Product Definition: Mini‑Me is a bounded personal AI agent that handles repetitive first contact, provides trustworthy information, and helps people decide whether to begin a real conversation.
From Vision to MVP: To test this idea in a focused, real-world context, I built Mini‑Jasper—the portfolio and recruiting MVP of the broader Mini‑Me vision.
One persona. One verified knowledge base. One specific moment before human contact.
02 From Vision to Focused MVP
Overview: To make the broader Mini‑Me idea testable, I narrowed it into one concrete use case: Mini‑Jasper, a portfolio and recruiting agent. The MVP focused on helping recruiters and hiring managers quickly understand Jasper’s background, work, capabilities, and evidence before deciding whether to start a real conversation.
02-1 A Focused First-Contact Use Case
Recruiters and hiring managers often need to understand a candidate’s background, capabilities, and relevant work before deciding whether to begin a conversation. Traditional portfolios contain this information, but leave visitors to find, connect, and interpret it on their own.
Mini‑Jasper transforms that first layer of portfolio exploration into a guided conversation.
Help recruiters, hiring managers and collaborators understand Jasper’s work, evaluate its relevance, and decide whether to begin a real conversation.
02-2 My Role and MVP Goal
I led Mini‑Jasper from product definition and interaction design to knowledge architecture, agent behavior, implementation, testing, and deployment.
The goal was not to maximize conversation length, but to make first contact more informed, trustworthy, and likely to continue with a person.
03 Designing a Reliable RAG System
Overview: Once the MVP scope was clear, the core challenge became trust: Mini‑Jasper needed to retrieve the right knowledge, preserve evidence, and answer within scope. Before diving into the strategy and techniques behind Mini‑Me’s RAG system, it is important to first understand how the system is structured. This section explains the overall architecture: how knowledge is organized, how retrieval is layered, and how the agent is constrained to produce grounded, reliable answers.
Human-Readable Portfolio
The original portfolio was written for human reading. It worked as a linear narrative: visitors could scroll through project pages, follow the story, and interpret context on their own.
But a RAG system does not read like a person. It cannot rely on intuition, memory, layout, or visual context in the same way a human visitor can. A sentence that feels clear on a portfolio page may become incomplete when retrieved on its own.
Agent-Readable Knowledge
Before designing the retrieval strategy, I first clarified Mini‑Jasper’s role. It was not meant to replace a real conversation or make decisions on Jasper’s behalf. Its purpose was to support the first round of introduction: helping recruiters, hiring managers, and collaborators quickly understand Jasper’s background, work, capabilities, and evidence.
That role defined the boundary of the knowledge system. Mini‑Jasper did not need to know everything. It needed to know the right things: who Jasper is, what she has built, what role she played, what capabilities she demonstrates, what evidence supports those claims, and how it should communicate within scope.
So the core challenge was not simply building a database. It was redesigning a human-facing portfolio into an agent-readable knowledge system.
To make retrieval reliable, I separated the portfolio into distinct knowledge objects. Each object had a clear purpose, so the system could retrieve from defined knowledge areas instead of asking the model to infer meaning from long-form pages.
03-1 Designing Knowledge for Retrieval
Chunk Strategy
Once the knowledge sources were scoped and organized, the next challenge was preparing them for retrieval. In an embedding-based system, the retrievable unit is not the full portfolio page or even the full source file. It is the chunk. After defining the knowledge objects, I designed the content into embedding-ready chunks.
The goal was not to split text by length alone. A chunk needed to work as a self-contained answerable unit. If a retrieved chunk only said “task success increased by 35%,” the metric would exist, but the project, role, and context would be missing.
A stronger chunk preserves the meaning needed for retrieval: the entity, topic, project context, Jasper’s role, supporting evidence, and metadata.
This made chunking part of the information architecture. Each chunk had to be specific enough to retrieve accurately and complete enough to support the next layers of the system.
Strategy of designing a reliable RAG System ⬆ ⬇
- -Project is missing
- -Jasper's role is missing
- -Work area is missing
- -Evidence can be misused
- +Meaning stands alone
- +Retrieval has context
- +Metric stays attached to source
- +Ready for grounded answer
Embedding-ready Chunk Strategy ⬆ ⬇
Knowledge Object Map ⬆ ⬇
The Knowledge Object Map defined the conceptual structure of the knowledge layer. I then translated that structure into maintainable source files, giving each retrieval area a clear source of truth: identity, capabilities, project evidence, conversation boundaries, and context assembly rules.
The slides below show how this structure appeared in the actual knowledge files behind Mini‑Jasper.
03-2 Designing Layered Retrieval
Semantic Search Was Not Enough
After the knowledge layer was structured, the next challenge was retrieval: deciding which knowledge should be used for a specific user question.
I did not want Mini‑Jasper to rely on semantic similarity alone. Portfolio questions are often short, ambiguous, and context-dependent. A recruiter might ask “What did Jasper do?”, “Does she have AI experience?”, or “Tell me about Mini‑Me.” These questions may look simple, but they require different retrieval paths: identity, capability, project evidence, role contribution, or logistics.
Semantic search is useful, but it is not enough on its own. A short question may not contain enough signal. A broad question may match multiple knowledge areas. A project name may need evidence, while a capability question may need both a capability model and supporting project examples. If the system retrieves only by similarity, it can return content that is related but not actually appropriate for the user’s intent.
Retrieval as an Intent Flow
So I designed retrieval as a layered intent flow. Mini‑Jasper first protects the boundary, then understands what the user is asking, then decides where to search. Layered matching happens only after the question has been scoped, parsed, and routed.
The diagram below shows how Mini‑Jasper moves from a user question to a retrieval target. Each layer has a specific function: preventing out-of-scope use, clarifying the question, extracting intent, routing to the right knowledge area, matching by confidence, and selecting usable context for grounded answers.
Query Walkthrough
To make the retrieval logic easier to inspect, I used one real query as a walk-through. The example below shows how Mini‑Jasper handles a capability question step by step: it first checks whether the question is safe and in scope, then identifies the user’s intent, routes the query to the right knowledge area, and finally retrieves supporting evidence before answer generation.
Real Query walkthrough ai-product Experience ⬆ ⬇
03-3 Designing for Reliable Answers
Retrieval Is Not the End
After Mini‑Jasper retrieved the right context, the next risk was answer behavior. Relevant context does not automatically produce a reliable answer. The system still needed to avoid over claiming, mixing evidence across projects, exposing internal retrieval logic, or answering beyond what Jasper’s portfolio actually supported.
So I treated answer generation as a product design layer, not just a model output step.
Three Answer Principles
I used this Three Answer Principles to guide the design of answering system. This was important because Mini‑Jasper was not designed to replace Jasper or make decisions for her. It was designed to support early understanding: answer grounded questions, point to evidence, and then guide the user toward the next appropriate step.
Three Answer Principles ⬆ ⬇
Designing Layered Retrieval Strategy ⬆ ⬇
04 Making RAG Safe and Effective
Overview: After retrieval worked, the next challenge came from real user input. Open chat does not only produce clean questions. It can produce unsafe prompts, irrelevant requests, or vague but valid intent. I designed Mini‑Jasper to treat these differently instead of sending every query into retrieval.
04-1 Three Query Risks
Once Mini‑Jasper could retrieve portfolio knowledge, the next challenge was controlling what kind of questions it should respond to. In an open chat interface, not every user query is equally answerable. Some questions are unsafe, some are irrelevant, and some are simply too vague to retrieve accurately.
Problematic Query Types ⬆ ⬇
04-2 Turning Query Risk into Product Behavior
I treated safety as part of retrieval design, not only as a response-generation rule. Before Mini‑Jasper searched the knowledge base, it first needed to decide whether the question was answerable within its product role. This led to three design decisions:
Block unsafe questions before retrieval - Malicious or boundary-breaking queries should not enter retrieval at all. If the question tries to override instructions, ask for private information, or push Mini‑Jasper outside its role, the system returns a scoped refusal.
Redirect irrelevant questions instead of pretending to answer - Mini‑Jasper is not a general assistant. When a query is unrelated to Jasper’s background, projects, capabilities, or logistics, the system should explain its scope and guide the user back to portfolio-relevant questions.
Clarify or route vague questions instead of guessing blindly - Some vague questions are still valid. For example, “What can Jasper do?” should not be blocked. Instead, Mini‑Jasper treats it as a broad capability intent and retrieves from structured capability knowledge plus supporting project evidence.
Safe Retrieval Process Flow ⬆ ⬇
04-3 Product-Facing Safety Schema
Query Decision Schema ⬆ ⬇
This made Mini‑Jasper safer without making it feel rigid. The system did not treat every imperfect question as a failure. Instead, it separated harmful queries from irrelevant ones, and separated irrelevant questions from vague but valid user intent. That distinction made the agent more useful: it could protect boundaries, avoid unsupported answers, and still help users move from a broad question to grounded portfolio evidence.
05. Building the Feedback Loop
Overview: A reliable answer was not enough. To make Mini‑Jasper a live product rather than a demo, I needed a lightweight way to understand whether visitors were engaging, asking useful questions, and moving toward next-step actions.
I designed the feedback loop around product signals rather than personal data. The system tracked lightweight events such as answered questions, related-question clicks, next-step moments, and CTA actions, making the product measurable without turning the portfolio into a surveillance system.
Event Schema Card ⬆
End-to-end Analytics Pipeline ⬆
This turned Mini‑Jasper from a functional AI interaction into a measurable product system.
These events flowed from the frontend into an analytics API, then into Google Sheets and hourly metrics. This gave me a simple way to observe usage, evaluate engagement, and guide future iteration.
06 Validation and Reflection
Overview: After launch, Mini‑Jasper became a live product system with measurable signals. I used lightweight analytics to understand whether visitors were engaging with the agent, asking questions about Jasper’s work, and moving toward next-step actions.
The live impact panel below shows early usage since the public MVP launch, updated hourly. Rather than treating the MVP as finished, this feedback loop gives me a way to evaluate behavior and guide future iteration.
Live Product Impact
Live usage since MVP launch · Updated hourly
Live metrics are temporarily unavailable.
