Claude-Powered Portfolio Assistant

A portfolio can show projects and experience, but it still asks the visitor to navigate everything themselves.

I wanted to explore whether conversational AI could make that experience more useful by letting a recruiter ask direct questions about my background, projects, and technical skills without turning the site into a generic chatbot demo.

The challenge became: how do you build an assistant that is useful, accurate, secure, and grounded in a limited set of facts about one person?

I built and iterated the assistant across three architectures, then implemented the current Claude-powered version with a bounded system prompt, session context and a Cloudflare Worker protecting the API credential.

The primary user is a recruiter, hiring manager, or portfolio visitor who wants a quick answer without reading every page.

That user needs concise, trustworthy information about experience, projects, skills, and links. They do not need the assistant to speculate, invent achievements, or behave like a general-purpose chatbot.

That constraint shaped both the system prompt and the architecture.

Conversational UX is only useful if the information is trustworthy. A smooth answer is not enough if the model can invent details.

The API integration is part of the product. Where the key lives, how requests are routed, and how errors are handled matter just as much as the model response.

Different AI approaches create different maintenance costs. Intent-based systems require predefined flows, while an LLM reduces intent maintenance but increases the importance of prompt boundaries and grounding.

Why move away from intent-based conversational AI?
The portfolio use case has a wide variety of natural-language questions but a relatively small factual domain. Maintaining many explicit intents added complexity without improving the visitor experience.

Why put the portfolio facts in the system prompt?
The goal was not open-ended knowledge. The assistant needed a defined source of truth and clear boundaries around what it should and should not answer.

Why use a Cloudflare Worker?
The API key could not safely live in the browser. A serverless proxy created a clean boundary between the public client and the private credential.

Why tell the model to admit when it does not know?
For a portfolio assistant, an invented answer is worse than no answer. The fallback behaviour is part of the product design, not an error state to hide.

The project evolved through three distinct approaches: IBM Watson, Dialogflow CX, and finally a Claude-powered assistant secured by Cloudflare Workers.

The production version can answer portfolio questions in natural language, preserve conversation context during a session, stay grounded in a bounded set of facts, and keep the Anthropic credential off the client.

The most important outcome was the architecture shift. What began as a chatbot experiment became a practical lesson in how AI features depend on security, prompt design, scope control, and fallback behaviour.

If I were measuring it as a real product, I would track:

I initially treated the chatbot as a learning project about conversational AI. The biggest lessons ended up being less about the model itself and more about the system around it.

Moving from Dialogflow to Claude reduced one kind of complexity, but introduced a different set of responsibilities around grounding, security, and prompt boundaries.

If I continued the project, I would separate portfolio data from the system prompt and load it from a maintained structured source so updates to experience and projects do not require editing the assistant logic itself. I would also add lightweight evaluation cases for factual accuracy and fallback behaviour.