Forem: 고광웅

Your AI's Persona Is a String. A New Paper Argues It Should Be a Steering Vector.

고광웅 — Sun, 19 Apr 2026 14:08:10 +0000

The Mismatch Most Persona Products Live With

If you've built any kind of AI agent product in the last two years, you've probably shipped a "persona" feature. Usually it looks like this: a text field where the user (or the product) writes "You are a witty, slightly sarcastic assistant who loves climbing," and that string gets stitched into a system prompt. Done. Persona complete.

The thing is, nobody who has ever worked with real people thinks of personality that way. Actual humans don't have a single mode. The friendly coworker is different at 2am on a deadline. The patient teacher is different when a student is being deliberately obtuse. Situation changes behavior, and most of the time it changes it a lot.

A paper that went up on arXiv this week formalizes that mismatch and proposes something interesting about how to fix it. It's not the kind of paper that'll get quoted in keynote slides — there are no dramatic benchmarks in the abstract — but the conceptual move is, I think, more important than the specific method.

The paper is Beyond Static Personas: Situational Personality Steering for Large Language Models (Wei, Li, Wang, Deng, April 15). Short version: instead of treating personality as a string you define once, treat it as a runtime steering signal over the model's neurons — one that shifts with the situation.

What the Paper Actually Argues

The technical contribution is a framework the authors call IRIS — Identify, Retrieve, Steer. It's training-free and operates at the neuron level. Three parts:

Situational persona neuron identification — find the specific neurons whose activation patterns correspond to personality traits in context.
Situation-aware neuron retrieval — given a new situation, retrieve the relevant neuron set for the desired persona expression under that situation.
Similarity-weighted steering — apply a steering vector to those neurons at inference time, weighted by how similar the current situation is to the retrieved references.

What I find more interesting than the method is the empirical claim underneath it: the authors argue (and their analysis attempts to demonstrate) that situation-dependency and situation-behavior patterns already exist inside LLM personalities, at the neuron level. Personality isn't just an artifact of the system prompt — it's something the model has internalized structurally, and that structure is responsive to context.

If that holds up under replication, the implication is bigger than IRIS itself. It means the right abstraction for "persona" in an LLM might not be a description you write but a manifold you steer.

I'm hedging because the abstract doesn't give specific win margins and I haven't dug into the full paper. The method could under-perform cleaner approaches in practice. But the framing is worth thinking about regardless of whether IRIS turns out to be the method that wins.

Why This Is a Design Problem, Not Just a Method Problem

Here's the thing I keep coming back to. Most of the persona code I've written — and most of what I see shipped in agent products — treats persona as a compile-time primitive. You write it once, it goes into the system prompt, and from that point forward the agent's "character" is whatever that text produces in combination with whatever comes after.

What this paper is pointing at is that persona is arguably a runtime primitive. It's not a fixed definition. It's a behavior modulation that should respond to context — and the model already has the internal machinery to do that if you know where to apply the signal.

Those are two different things, and I don't think the industry has fully reckoned with the difference. We're selling "custom AI personas" while implementing static strings. The user-facing story is "you can make this agent sarcastic" but the implementation is a shim that barely survives contact with an adversarial user.

What Game Designers Have Been Saying For Decades

I spent a decade designing games before I started building AI agents. The paper's framing feels very familiar to me — it's arriving, through a different path, at something the game AI community has treated as common knowledge for a long time.

Static NPC personalities get old in a session. A guard who always says the same thing in the same tone at the same time regardless of what the player has been doing is immediately legible as a set piece, not a character. The guards players remember are the ones that modulated — the ones whose threat level shifted with how many times you'd returned to the same area, the ones whose dialogue tree branched based on tension state.

The vocabulary was different. We didn't say "steering vectors." We said mood systems, faction relationships, dynamic difficulty, dialog branching by tension. But the underlying insight is the same: behavior is a function of state × situation × character, not just character.

The novelty of a paper like IRIS, from a game designer's lens, isn't the idea. It's the discovery that the scaffolding for this kind of behavior is already latent in LLM weights and can be activated without retraining. That part is genuinely new.

Three Questions to Ask About Your Own Persona Implementation

If you ship a product where users can define or tune an AI's personality, it's worth auditing what you actually built against what you probably told users you built. Some specific questions:

1. What happens to your persona when the user asks something hostile?

Static-string personas tend to collapse under adversarial pressure. The "patient teacher" prompt starts talking like a base model the moment someone pushes hard. If your persona is a product promise, you need a mechanism beyond a string — otherwise the promise is broken the first time someone tests it.

2. Does your persona change register with conversation length?

Real teachers get firmer as a session drags on. Real assistants get more efficient as trust is established. If your agent sounds the same in message 1 and message 40, you've got a behavior rigidity that will eventually feel wrong to users.

3. What does your persona do when the topic shifts to something the "character" wouldn't know about?

This is the case where static personas fail most visibly. A persona designed around "warm emotional support" doesn't gracefully handle a user suddenly asking for tax advice. A situational model would know to shift register without dropping character. A string-based model can only either stay in character and refuse, or break character and help. Neither is right.

These aren't theoretical. They're the three places where persona products routinely fail in ways that erode user trust.

The Part That Matters for Builders

I don't think the takeaway from this paper is that everyone should rewrite their agents to do neuron-level steering next week. The infrastructure to do that at production scale doesn't really exist outside research labs yet.

The takeaway is more structural. The "persona" primitive most of us are using is probably a UI convenience over a more correct runtime mechanism. The more correct mechanism isn't accessible yet, but the mismatch is worth being honest about in how we design around persona features today.

Some implications I'm thinking through:

Treat persona as a layered system rather than a single string. Core traits at one level, situational modifiers at another, tone adjustments at a third. This is messier in the UX but closer to what's actually happening.
Build instrumentation for persona drift. How does your agent's tone change across a long conversation? Across different user emotional states? You probably don't measure this and should.
Be wary of "custom persona" as a feature promise. If your implementation is a text field and the model is doing the rest, you're selling something the mechanism can't reliably deliver. Setting user expectations honestly is better than overselling.

What This Paper Doesn't Settle

I want to name a few things the paper, as I understand it from the abstract, does not resolve:

The specific benchmarks (PersonalityBench and the authors' new SPBench) aren't standard in the field yet. Situational personality benchmarks are hard to construct well, and it's possible a different benchmark would tell a different story.
Training-free methods are appealing for deployment but sometimes undersell what you'd get from even a small amount of targeted fine-tuning. IRIS may be the right research contribution but not the right engineering choice for a given product.
Neuron-level steering is interpretability-adjacent territory, and that field has been notably humble about what its findings mean. Identifying "persona neurons" is a strong claim that deserves scrutiny before anyone builds on it as foundational.

I'm flagging these not to pick fights with the paper but because conceptual takeaways are more portable than methodological ones, and conflating them is how builders end up chasing implementations that don't actually help their products.

The Close

What I'm sitting with, after reading this paper alongside the last few days of working on agent products, is that a lot of the primitives we use are shaped by what was easy to build rather than what is actually the right model of the thing we're building.

Persona-as-string is easy. Persona-as-neural-steering-signal is hard. So we shipped the easy one. That's fair — you ship what works today. But it's worth occasionally asking whether the abstraction you shipped is actually the right abstraction, or just the one that was available.

For persona specifically, my current guess is that the right abstraction is situational and runtime, not descriptive and static. The paper arrives at that conclusion through empirical analysis of neuron activations. Game designers arrived there through twenty years of making NPCs that didn't suck. Different paths, convergent answer.

Whether IRIS is the specific mechanism that ends up winning is almost beside the point. What matters is the reframe: behavior is a function of situation, and persona is a steering problem, not a description problem.

If you're building in this space, it's worth checking which one your product actually implements.

Claude Design Looks Like AI Magic. Reading the Source, It's Four Engineering Patterns.

고광웅 — Sun, 19 Apr 2026 04:34:45 +0000

Before the Hype Settles

Anthropic shipped Claude Design on April 17, and most of the discussion has framed it as a Figma-challenging AI design tool. I used it differently. Instead of treating it as a design tool, I treated it as a specimen — generated a handful of skill bundles, exported the output, then spent more time reading the source than tweaking the design. I was more interested in how the product works than in what it can design.

What I found is more interesting than "AI can design now." The product appears to be mostly four discrete engineering patterns that happen to have a model at the entry point. The model doesn't feel like the magic — it's writing into a carefully structured runtime that almost any team could build.

This post walks through those four patterns, what they actually do, and what I'm taking into my own stack. Caveat up front: these are observations from a source read of a small number of bundles, not a rigorous evaluation of the product's full behavior. I'll flag assumptions as I go.

What I Inspected

A Claude Design skill bundle we looked at contained:

Wireframes.html — a 72KB single-file wireframe document with five navigation variations across three screens each, plus a live Tweaks engine.
IR Deck - Hi-fi.html and IR Deck - Wireframes.html — 1920×1080 slide decks wrapped in a custom Web Component.
deck-stage.js — a 621-line Web Component that provides the slide runtime.
colors_and_type.css — a 160-line design token sheet organized into seven categories.
SKILL.md — a 20-line skill manifest with frontmatter.
README.md — a 223-line brand and voice guide.
preview/ — twelve single-file "at-a-glance" cards, one per token category.
ui_kits/web/ — a React 19 UMD clickable prototype.

The total footprint is small. What's striking is how the pieces fit together — and how few moving parts there actually are.

Pattern 1 — Tweaks: `data-*` Attributes with CSS Variables

The Tweaks panel is what makes the output feel interactive: click "dusk" and the whole design shifts to a warm dark palette. Click "compact" and the layout tightens. No regeneration. No API round-trip.

The mechanism is mundane. Every theme, accent, layout, and density option is a :root CSS variable override keyed to a data-* attribute on the root element:

:root, [data-theme="paper"] { --ink:#1a1a1a; --paper:#f4efe6; --accent:#c53b1e; }
[data-theme="dusk"]         { --ink:#eae3d2; --paper:#2a2620; --accent:#e77c5f; }
[data-theme="midnight"]     { --ink:#f0ebde; --paper:#14110d; --accent:#ff8a6a; }
[data-accent="gold"]        { --accent:#d4a017; }
[data-layout="stack"] .flow { grid-template-columns: 1fr !important; }
[data-density="compact"] main { padding: 14px 18px; }

A click handler sets document.documentElement.dataset.theme = "dusk", persists to localStorage, and postMessages the host window so it can save the selection against the artifact. That's the entire switching layer.

Four axes, three-to-four options each, roughly 144 combinations available without regenerating anything. The design-system work is done at token definition time, not at runtime.

The takeaway I'm sitting with: what feels like "AI variant generation" in interactive design tools may be mostly static CSS token switching. The AI wrote the tokens once. The switching is attribute swapping.

Pattern 2 — `deck-stage.js`: A 621-Line Web Component That Replaces a Slide Tool

The decks in the output aren't Reveal.js or a bespoke React app. They're a custom Web Component, <deck-stage>, containing plain <section> children as slides.

What the component does:

Fits a design-size canvas (default 1920×1080) to whatever viewport it's rendered in, using transform: scale().
Handles keyboard navigation (arrows, PgUp/PgDn, Space, Home, End, 0–9, R).
Adds mobile tap zones (left third / right third).
Persists the current slide to localStorage, keyed by document path, so a refresh restores position.
Renders a floating overlay with previous/next/reset controls and a slide counter.
Injects a <style> tag into document.head with @page { size: 1920px 1080px; margin: 0; } so the browser's native "Print to PDF" produces one page per slide.
Emits a slidechange CustomEvent with bubbles: true, composed: true and a reason field (init/keyboard/click/tap/api) — listenable cleanly from outside the shadow DOM.
Reads a <script type="application/json"> block of speaker notes and posts them to the host window.
Honors a noscale attribute for PPTX export cases where the CSS transform is undesirable.

Two implementation details stood out:

The @page rule has to be injected into the outer document because shadow DOM ignores @page. So the component walks up and writes into document.head during connectedCallback. This is the kind of detail that gets no documentation credit but separates "works in print" from "falls apart at export time."

Slides are hidden, not unmounted, with visibility: hidden; opacity: 0. That preserves the state of videos, iframes, form inputs, and React subtrees across navigation. If you're building a slide system in React with conditional rendering, you're quietly discarding state every time the user hits the arrow key. A cheap fix with meaningful UX consequences.

Pattern 3 — `SKILL.md`: A Manifest Format, Not a System Prompt

The skill manifest is smaller than I expected. Three frontmatter fields:

---
name: <skill-kebab-case>
description: "Use this skill to generate well-branded interfaces and assets for <domain>. Contains <key files> for <style context>."
user-invocable: true
---

The body reads like a protocol, not a persona:

"Read README.md within this skill first."
"Then look at colors_and_type.css."
"If creating visual artifacts (slides, mocks): copy assets out, produce static HTML."
"If working on production code: treat <path>/frontend/app/ as canonical."
"If invoked with no other guidance: ask 3–5 questions about scope and audience, then act as an expert designer."
"Always flag: font substitutions, chart color choices, and any deviation from the documented color contract."

Three things about this format stood out:

Description is the routing signal. The orchestrator decides when to invoke the skill by reading the description alone. So the description has to encode domain, output type, and stylistic signal in one paragraph — different from how most agent frameworks define a role.

The body is a branched protocol. "If A, do X. If B, do Y." Not a soft persona, not a goal statement. Concrete execution paths keyed to invocation context.

"Always flag" is mandatory self-reporting at the manifest level. Fonts were substituted? Flag it. Deviated from the color contract? Flag it. It's an anti-hallucination pattern written into the skill definition rather than left to the model to remember.

I don't think the manifest format itself is novel — it's structurally close to how Claude Code's existing SKILL.md works. But its use as an agent interface for a consumer-facing design product is a concrete shape I haven't seen written down this cleanly before.

Pattern 4 — Output = Self-Contained HTML Bundle

The artifact isn't stored in a proprietary database. It's a folder:

IR/
├── assets/
│   └── colors_and_type.css
├── IR Deck - Hi-fi.html
└── deck-stage.js

The HTML references the CSS by relative path and the JS by relative path. Everything is physically co-located.

Zip it, upload to any static host, it works. No build step. No framework runtime. No server-side rendering required.

There's a small interesting trick: the same colors_and_type.css file appears as copies in multiple subfolders — one for the deck, one for the UI kit, one for the preview cards. The bundle is optimized for survival, not deduplication. If a user downloads just the deck folder, they don't lose styling.

More bytes, no broken links. For a consumer product where users will definitely cut-and-paste the wrong subset of files, that tradeoff probably earns itself back quickly.

Why This Shape Is Interesting

Going in, my mental model was roughly: "Claude Design is a big AI system that generates design output."

What I came away with is closer to: "It looks like a thin AI orchestration layer over a carefully engineered runtime and manifest format, and the interesting work is in the runtime."

The model writes HTML, CSS, and SKILL.md files into this system. The system is what makes the output interactive, exportable, and robust across environments. If Anthropic swapped the model tomorrow for a comparable one, my guess is the user experience would barely change — because the experience is mostly the runtime.

That reframes the build-vs-buy question for anyone working in this space. You may not need a design-specialized model to get most of the user-facing value. What seems to matter more is:

A token CSS file with tight, opinionated choices.
A data-* attribute theming layer.
A Web Component (or equivalent) that handles presentation concerns: scale, navigation, print.
A manifest format for the skills that generate into the runtime.
A bundle format that survives being zipped and sent around.

Build that scaffold, then any capable LLM plausibly becomes your design engine. If this read is right, the hard work isn't the AI — it's the runtime the AI writes into. I'm hedging because one bundle inspection isn't enough to generalize.

What I'm Taking

Four patterns I'm adapting into our own stack:

Four-axis Tweaks (theme / accent / layout / density). Roughly fifty lines of CSS and JavaScript for a meaningful UX upgrade. Low risk, high visibility.
@page dynamic injection for PDF export. Potentially removes the need for a separate PDF library in slide-style outputs.
SKILL.md manifest format for our agents. Three-field frontmatter, branched body, mandatory "Always flag" section. Structural improvement on how we currently define agent behavior.
Self-contained HTML bundles as the default artifact. No server dependency, zippable, survives cut-and-paste. Lowers the support surface dramatically for client-facing deliverables.

I'm leaving aside porting the slide Web Component for now, because we already have a working runtime and the license review cost isn't obviously worth the marginal gain. The patterns above are portable with a day or two of work each.

The Open Question

The specific shape I'm describing — four patterns around a model — isn't obviously unique to design. It's roughly the shape of a lot of AI-labeled products right now. The product does something useful and the model is the visible new thing, but most of what makes it work seems to be conventional engineering inside a well-thought-out structure.

If that holds, a lot of "AI products" are really platform products where the AI is the entry point rather than the engine. The scarce skill in that world isn't prompting. It's designing the runtime the prompts write into.

I'm not sure whether that's a durable observation or a snapshot of where we are in this early phase of AI product maturity. But it's the one I came away from this source read with, and it's shifted how I'm thinking about our own architecture.

If you're building in this space, reading the bundles your tools produce might teach you more than reading the marketing. That's the part I'd put the most confidence on.