The game plan for building a portfolio for AI work

I have been thinking more deliberately about what this portfolio needs to prove if I want it to lead to serious AI work.

The goal is not to fill a grid with thirty small demos or put “AI” in front of projects that are really thin wrappers around a model. I already have several different projects in motion. The job now is to make the range visible and explain what each project proves.

Right now, I see five projects forming the core AI-work portfolio.

• Official Lead System — applied AI inside a real business workflow

This is the strongest completed case study in the group. It shows a Rails operations platform that turns marketplace opportunities into a human-reviewed pipeline with AI qualification, source-backed research, outreach drafts, tasks, and sales handoff. The important skill is not simply generating text. It is deciding where AI belongs in an operational system, preserving human review, handling uncertain research, and connecting model output to structured records and actions.

• Life of AI and Dispatch — AI-assisted publishing, ingestion, and editorial systems

This site is also a product. Behind the public journal is a private Studio for capturing ideas, organizing projects, ingesting articles and video transcripts, extracting source-grounded topics, and turning selected ideas into editable drafts. This project demonstrates content pipelines, background jobs, retrieval from long sources, evidence preservation, editorial review, SEO systems, and the discipline to keep generated work separate from personal writing. It also documents the work while I build it.

• Rails React Starter — full-stack and mobile foundations

AI products still need good software around the model. This open-source starter combines Rails with React and React Native so a product can have a web application, API, and mobile path without rebuilding the foundation every time. It can show architecture, authentication, testing, reusable components, developer experience, documentation, and open-source maintenance. That matters because an AI application engineer needs to ship the complete product, not only the prompt.

• Open-source application discovery chatbot — conversational product design

This project explores a questionnaire-style AI consultant that helps someone define the application they actually need. Instead of presenting a rigid form, it would ask useful follow-up questions, clarify constraints, and turn the conversation into a structured application brief. A strong first demo does not need every integration. It needs one excellent discovery conversation that proves adaptive questioning, context management, structured output, and a useful handoff from conversation to product requirements.

• Mirror — long-term memory, identity modeling, and responsible personal AI

Mirror is the most ambitious direction: an evolving personal AI built with the user’s consent. The first version would begin with a guided interview about goals, values, background, communication preferences, and important experiences. Optional personality frameworks could be included as self-described signals, but not treated as objective truth.

The difficult part begins after onboarding. Over time, Mirror would learn from journal entries, conversations, decisions, milestones, and direct corrections such as, “That does not sound like me.” It would separate stable profile facts from preferences, experiences, beliefs, behavioral patterns, and relationship-specific information. Memories would keep their source, date, confidence, and privacy level instead of becoming one giant, unquestioned transcript.

That creates serious engineering questions: How should long-term memory be stored and retrieved? How can the AI show which parts of an answer are known, inferred, uncertain, or outdated? How should changing beliefs be represented? How does a user inspect, edit, export, or delete what the system remembers? How do I prevent a personal model from becoming an impersonation tool?

The strongest interaction may not be the AI getting the user right on the first try. It may be the user saying it got something wrong, explaining why, and seeing that correction improve a later response. That would demonstrate a learning loop instead of another polished chat screen. Voice can make a future demonstration more powerful, but memory, correction, and explainability should come first.

Together, these projects show different layers of the work: operational AI, source-grounded content systems, full-stack and mobile architecture, conversational discovery, and long-term memory. Client projects can add evidence of visual design, delivery, and production responsibility, but these five create the clearest technical story for AI work.

The agenda now is to finish and document the strongest work already in motion, define one convincing demo for each active project, and avoid pretending exploratory ideas are finished products. Every case study should explain the problem, my role, the architecture, the difficult decisions, the result, and what I would improve next. I also want to keep publishing the experiments, failures, tradeoffs, and corrections here, because the path is part of the evidence.

The standard I want for this portfolio is simple: five distinct proofs, fewer unsupported claims.