Building a Portfolio with an AI Agent
A living system: capture private work, transform it with a constrained agent, publish under a safety charter.
What problem existed?
Designers are told to keep a portfolio current. The work that proves senior ability is often the least shareable: enterprise systems, internal tooling, AI features under NDA. Writing case studies from memory months later loses the decisions that mattered.
I had the same problem with my own work. The strongest evidence sat behind confidentiality, and generalizing it safely was slow enough that it kept not happening. The temptation was to either over-share proprietary detail or publish work so generic it argued nothing.
Why did it matter?
A portfolio is the main artifact senior design roles are evaluated on. For people doing enterprise and AI work, the best material is the hardest to publish.
Without a repeatable way to transform private work into portfolio-safe writing, the portfolio either exposes the company or undersells the designer. Both are real costs, and both compound the longer the work stays uncaptured.
What constraints existed?
- Confidentiality is absolute. No source, internal screenshots, non-public metrics, roadmaps, or customer names.
- Capture has to be cheap. If recording a decision takes more than a minute, it will not happen during real work.
- Consistency over time. Across many entries, language drifts toward company specifics unless something holds the line.
- Generalized still has to be true. Abstraction cannot become fiction. The work has to stay accurate.
What role did I play?
I designed and built the system, and I am its only reviewer.
I treated my own portfolio as a product. I defined the architecture, wrote the rules, built the site, and set up the agent workflow. The agent did the drafting and the mechanical checks, and the judgment stayed with me.
What options were explored?
- A portfolio builder or CMS. Fast to start, but it adds a subscription, offers no way to enforce abstraction, and keeps the content somewhere I do not control.
- Writing each case study by hand when needed. Honest, but it does not scale, it loses detail, and nothing prevents drift.
- A governed pipeline. Private capture, a constrained agent that transforms one entry at a time, and a static site. This is what I built.
What tradeoffs were considered?
The central tradeoff was automation versus judgment. I kept the agent on the safe side of the line. It drafts, generalizes, and flags, and I make the decisions.
A small deterministic check runs on every publish to catch obvious leaks, and a review step raises anything on the line for me to rule on. I review for one distinction: public or non-public. Company-specific detail is welcome when it is already public, because real references are what make the work read as credible.
How did UX, engineering feasibility, and business strategy intersect?
The site is a normal, fast static site with a two-page resume, and it holds to WCAG 2.2 AA and works on mobile. Nothing exotic.
The engineering is a git repository, a static build, and a pre-push check, so there is no platform to maintain and the system survives without upkeep. The strategy is plain: this is my career surface, the running cost is near zero, and the governance is what lets me work from the real record instead of from memory.
How was AI used in the process?
The agent, Claude running in Conductor, does three jobs. It turns private capture into a portfolio-safe draft. It generates the diagrams as code, so there are no exported internal images. It runs the review that raises borderline items for me.
A voice guide built from my own published writing loads alongside the charter on each drafting pass. When a draft comes back sounding generic, the fix is a rule addition to that document: a construction to avoid, a sentence pattern that fits, the right register. The rules accumulate with use, and the output gets progressively more accurate.
It never invents metrics and never reconstructs a proprietary system. The charter forbids both, and the automated check enforces the clearest cases. The loop from finished work to a reviewed draft now takes minutes. This case study, both diagrams included, was drafted in under eight minutes, and it is itself an output of the process it describes.
~2 hrs
Standing up the system
Charter, site, review, and the first case studies.
under 8 min
Average per case study
First draft, both diagrams included, reviewed.
What was learned?
- Write the rules down. A charter plus an automated gate keeps abstraction consistent across dozens of entries. Good intentions alone do not.
- Separate capture from transform. Record honestly in private, then generalize once, at the boundary, where a single review can catch problems.
- Let the agent raise; you decide. The useful division of labor is the agent surfacing judgment calls and the human making them.
- Do not over-abstract. Public product names and public documentation are fair to use, and keeping them makes generalized work read as real.
- Codify the quality bar, do not re-audit it. The same pre-push gate that enforces the charter also blocks accessibility and mobile-responsiveness regressions, so WCAG 2.2 AA and a working mobile layout hold by default instead of needing periodic sweeps.
- Codify your voice in writing. Start with examples from your own published work and extract what makes the prose yours: what to avoid, what register fits, what constructions you actually use. Add a rule each time a draft sounds generic. A few passes in, the output stops reading as generated.
Specific · private
Generalized · public
- “Project Atlas” an internal platform initiative
- “Northwind Bank” an enterprise customer
- cut p95 latency 42% a meaningful performance gain
- the Q3 Helios launch a major quarterly release
- screenshot: checkout-v7 a recreated conceptual sketch
What was the outcome?
A working system, with this site as its proof. It has four parts: a capture layer that stays private, a constrained agent that transforms one entry at a time, a static site, and a charter enforced by a pre-push check and a review step. New case studies now start from real notes and reach a safe draft in a single sitting.
Standing up the whole system, the charter, the site, the review step, and the first case studies, took a couple of hours rather than the weekend I had budgeted. At that cost, keeping the portfolio current fits inside normal weeks instead of needing a dedicated block of time.
Playbook: set this up yourself
A version other designers can copy. None of it requires more than a text editor, a git repository, and an AI agent.
- Write a one-page charter and a voice guide. The charter lists what never ships and one transform rule: specific becomes general. The voice guide extracts what makes your writing yours from examples of your own published work: constructions to avoid, the register you actually use, patterns that fit. Load both on every drafting pass. Add a rule to the voice guide each time a draft sounds generic. Keep both short enough to reread every time.
- Capture privately and honestly. Keep rough notes, prompts, and decisions in a private space. Do not censor here; the honest detail is what later makes a draft accurate.
- Transform at one boundary. Use the agent to draft a case study from the notes, generalized per the charter. Generate visuals as code rather than exporting real screens.
- Review against public versus non-public. Have the agent raise every borderline item, then decide each one yourself. Keep the references that are already public.
- Publish from a static repo. A git repository plus a pre-push check gives you a durable site and an automatic last line of defense.
The voice guide improves through use. Each time a draft trips a rule, the rule gets written down, and the next draft inherits it. A pass looks like this: the draft line, the rule it trips, and the rewrite.
Voice pass · draft → rule → fix
- Draft The interesting thing was how fast the loop collapsed. Rule No manufactured suspense Fix The loop collapsed from days to hours.
- Draft AI worked like a tireless analyst. Rule No metaphor in case studies Fix AI read the system and listed its dependencies.
- Draft Code is the source of truth; Figma is the display. Rule No aphorisms Fix The code defines the system, and the design tool reads from it.
Two snippets to start from. Both are generic and safe to copy. Adapt the placeholders to your own work.
A charter the agent loads on every pass:
# Portfolio charter (excerpt)
Never publish: source code, internal screenshots, non-public
metrics, roadmaps, customer or employee names, internal docs.
Transform rule (specific becomes general):
"Project Atlas" -> "an internal platform initiative"
"cut latency 42%" -> "a meaningful performance gain"
a real screenshot -> a recreated conceptual sketch
Public Test: would my manager, legal, a future employer, and
the original company all agree this shows my contribution
without exposing IP? If unsure: generalize, abstract, or cut.A drafting prompt that keeps the agent inside the rules:
You are a portfolio editor working under the charter above.
Input: my private notes for one project.
Draft a case study answering, in order: problem, why it
mattered, constraints, my role, options, tradeoffs, how
UX/engineering/business intersected, how AI was used, what I
learned, the outcome.
Rules:
- Generalize every specific per the transform rule.
- Invent no metrics. Use relative outcomes only.
- Generate diagrams as code; never describe a real screen.
- Raise anything you are unsure about for my review. Do not
decide it yourself.