Ask Archive: an AI advocate with boundaries
OVERVIEW
Overview
Ask Archive is the AI assistant on my portfolio site. Visitors can ask about my experience, work, and design decisions in plain language; it answers from a curated knowledge base and points to the most relevant case study, article, or a way to reach me.
The project started from rethinking how a portfolio is read.
A traditional portfolio is one-way reading: visitors browse the site's structure and piece together their own picture of the designer. But every recruiter cares about something different, some look at AI ability first, some at product experience, some at research background. I wanted an entry point you can just ask, where the site delivers information by question and lowers the cost of hunting for it.
At the same time, I wanted clear boundaries: it only answers public information about me, does not make things up, and does not pretend to know what it doesn't. The whole system is bilingual and uses context stuffing: because the corpus is small, the hand-authored knowledge goes into the model's context as a whole (no vector retrieval), together with page-aware conversation, persona design, and security and cost controls.
- Role
- Design & build (solo)
- Time
- Ongoing personal project
- Stack
- Next.js · Vercel AI SDK · Gemini · Upstash
- Scope
- Content architecture
Conversation UX
Security · cost
MOTIVATION
Turning a portfolio from reading into exploring
Recruiters rarely have time to read a whole portfolio. Skimming quickly, they might look at a few key pages and decide whether it is worth going deeper. If every piece of information has to be searched for and pieced together, the reading cost adds up.
I wanted to change that flow.
When a visitor wants to understand a direction, they can just ask; the site answers by question and surfaces the most relevant case. The portfolio stops being only a display and becomes something you can explore.
CONVERSATION
Conversation design: tone, context, and language
A site guide, in the third person
The assistant introduces Joseph in the third person, saying “Joseph worked on...” rather than “I worked on...”. That makes it read more like a site guide than a digital clone of me talking to you, and it sets an honest boundary. The third person also keeps the tone objective: it can lay out work and design decisions and quote named colleague endorsements, with less of the self-promotional edge. For out-of-scope questions, it states the limit clearly and points the visitor to reach me directly.
Understanding questions by the current page
Visitors are usually reading a specific case. When someone on the Praxis page asks “what problem does this project solve,” the system needs to know “this project” means the Praxis they are reading, not something mentioned earlier. So each turn is bound to the current page, and every message keeps the page it was asked on, so the assistant understands questions in the context of what the visitor is reading, without them restating the background.
Written separately in each language
The two languages each have their own knowledge base and persona settings, written separately rather than machine translated, so each version keeps a natural reading habit: the Chinese stays more narrative, the English more direct.
ARCHITECTURE
Turning a person's information into a content system
The most time-consuming part of this project was structuring the knowledge. At first I fed the portfolio content straight to the model and hoped it would understand my background and work. But as the content grew, I found that simply adding more data does not guarantee answer quality: the model needs to know the relationships between different pieces of information, and which content answers which questions.
So I designed the knowledge as a few kinds: a core intro, per-page detail, work cards, and photos. These, together with the persona and tone rules, go into the model, which recomposes them into a third-person, low-key answer; a final “no making things up” rule keeps it honest.
Core intro: the base that is always there
This is the base knowledge that stays in every conversation, carrying the assistant's overall understanding of me: personal background, work experience, design methods, technical skills, and case studies. Whatever a visitor asks, it is there. When organizing it, I split it by the angles recruiters care about, rather than one blob of text.
Per-page detail: added only for the page you're on
These are added only when a visitor is reading a specific page. On the Praxis page, for example, beyond the basic case intro it adds project background, design decisions, technical concepts, and screen descriptions, so the assistant answers deeper than the static page, without stuffing every detail into every conversation.
Work cards: reusing the site's own list
This is the part visitors see and click: case cards, articles, images, and video. It reuses the site's own list directly, so titles, covers, and links come from the same source. When the site updates, the assistant stays in sync, with no two copies to maintain and no contradictions.
No making things up: answering only from grounded content
The last layer is the “no making things up” rule. The assistant can only answer from the knowledge, the current page, and the persona rules; when a question is out of scope, it plainly says there is no relevant information rather than filling the gap. This layer is what keeps a generative model trustworthy when it faces the public.
SECURITY & COST
Define what you're defending against, then layer the protection
Designing an outward-facing AI assistant, I first thought clearly about what to defend against. Mainly three kinds: jailbreak and abuse (getting it out of character or off-task), injection attacks (overriding its instructions through input), and traffic abuse (flooding it with requests and running up cost). For these three I built matching protections, and rather than relying on a single line, I layered them.
Jailbreak and injection: prompt hardening
For jailbreak and injection, the main defense is role locking. The assistant has no “other modes,” will not reveal its setup, output its prompt, dump the full knowledge base, or switch to another role, and does not answer questions unrelated to me. Paired with pre-model checks (input length, abnormal keywords, conversation-history length), obviously out-of-context requests are blocked first, without spending model resources.
Traffic abuse: limits and data protection
For traffic abuse, there is a daily per-visitor cap. When identifying a visitor, it does not trust client-forgeable information and stores only a hashed IP. The whole thing is fail-open: if the backing service is temporarily unavailable, the site stays usable rather than the assistant going down.
Base: minimizing the impact of any breach
The bottom layer, and the most important: the entire knowledge base holds only information that was meant to be public.
So even if someone breaks through some limits, what they can reach is still what the site would show anyway. That puts the design focus on controlling abuse and cost, not protecting a secret that does not exist. I do not assume any single line holds forever; layering keeps the possible impact as small as possible.
Cost: reusing the fixed content
AI cost mostly comes from each model request, so I reuse the fixed content as much as possible. The unchanging parts of every request (persona rules, base knowledge, page detail) sit at the front of the prompt, so the model can use caching to cut repeated computation; the only parts that really need recomputing are the visitor's question, recent turns, and the current page.
Answer cache and preset questions
On top of that, I added an answer cache, keyed by “language + page + question.” When a question is exactly the same, it returns the stored answer without calling the model, and a hit produces no new token cost.
To make the cache more effective, I also designed preset questions (suggested prompts). They help visitors quickly realize what they can ask, lowering the barrier of not knowing where to start; and because preset questions are fixed strings shared across visitors, they hit the same cache heavily. One design that improves both experience and cost.
RESULTS & FUTURE
Results, observations, and what's next
So far, Ask Archive has accumulated about 100 sessions since launch; roughly 20% of visitors have opened the conversation, and interactions average under two questions. On the numbers alone the depth is not high, but the data points to a few directions to adjust.
Rereading the low usage
Seeing that only about 20% opened the assistant, I first thought the entry needed improvement. But after watching the full reading flow, I saw another angle: the assistant has not replaced the original portfolio reading. Visitors still browse their own way, and only use the conversation when they hit a question or want to go deeper into a case.
That matches the original design goal: it is a progressive-disclosure tool, present when needed and quiet when not.
Where it stands
~100
Sessions
Since launch, still early data.
~20%
Opened the chat
The rest read the static pages, uninterrupted.
The entry needs to be clearer
From the usage logs, some visitors may not have noticed the assistant exists. The next stage will test a better entry design, so those who want to explore deeper can find it more easily.
Shorter answers that keep the reading flow intact
Microsoft Clarity session replays showed engagement staying shallow: most visitors did not read far past the first answer. Watching the replays, the pattern pointed to reading cost. Answers ran long, and each new one pushed the rest of the page down as it arrived, so every reply landed as more to get through, and the reading position kept shifting.
I shipped two changes in response. The persona now answers more concisely, staying close to the question asked instead of volunteering everything at once. And a new answer no longer pushes the existing content down as it renders; the reading position holds still, so following up costs less attention rather than more.
Next: extending into a product pattern
After finishing this project, I started thinking about where this architecture could go in other products. Many products still rely on an FAQ or a docs center for users to search themselves; as information grows, finding the right answer becomes a problem in itself. The same architecture could become a knowledge entry inside a product, where AI answers from organized material and lowers the search cost. For enterprise use, it would also need finer permission control, scope control over information, terms and a disclaimer, and answer-source tracing, so the AI stays helpful while keeping a clear boundary of responsibility.
What I took away
The portfolio's information used to be scattered across different pages, articles, and cases. Building the assistant meant organizing a person's background, ability, and design perspective into a content system that can be understood, queried, and maintained.
In the end, this is an information-architecture problem: turning scattered content into a clear, queryable structure, only this time the subject is a person. The most direct way to see how the system actually works is to ask Ask Archive itself; it can also answer questions about this case study.