Forem: Luis Vargas

How I Used AI ~MultiAgent~ Simulation to Fix My Ad Messaging

Luis Vargas — Fri, 17 Apr 2026 23:47:44 +0000

From Guessing to Knowing: How I Used AI Agent Simulation to Fix My Ad Messaging

A UX researcher's experiment in synthetic audience intelligence — and what it taught me about my own product.

The Honest Problem

I had ads. Good ads, I thought.

They were clean. They hit the features. They explained what Waco3.io does — proposal intelligence for freelancers and small service businesses. Intelligent tracking. Client engagement. Automated follow-ups.

But something wasn't landing.

The messaging felt like it was about the product instead of for the person reading it. I knew the pain points. I had ICP docs. I had personas. But I was still solving my customers' problems through my own lens — and that's a blind spot every designer and builder eventually hits.

The typical fix? User research. Interviews, surveys, usability tests, qual data. All of which I believe in deeply.

But here's the real-world constraint: I was solo, no time, moving fast, and needed directional signal now — not in three weeks after, scout participants, recruiting and scheduling fifteen interviews.

So I tried something different.

Enter MiroFish

"From a single document, MiroFish extracts reality seeds to auto-generate a parallel world with up to million-scale Agents."

MiroFish is an open-source multi-agent swarm simulation engine. The premise is deceptively simple: upload your documents, define your context, and let the system generate a populated simulation of your target world — complete with agents that think, disagree, post, follow, and react to each other in real time.

It's v0.1-Preview. Rough around the edges. ~$5/sim. And genuinely one of the more interesting UX research shortcuts I've found.

I don't call it a replacement for real research. I call it a matrix of opinions — a fast, structured way to expose your idea to perspectives you didn't know you were missing.

What I Fed the System

My input was three files:

waco3_ideal_customer_persona.md — my ICP document
waco3_pain_points.md — documented emotional and practical frustrations of my target users
ads_waco_v1.txt — my current set of ad copies

The goal: not just "does this ad perform?" — but how do different types of people within my audience actually interpret this message? What do they feel? What do they reject? Where does the copy fail them emotionally?

That's a UX question, not a marketing question.

Step 1: Ontology Generation — Building the World's Structure

The first thing MiroFish does is analyze your documents and auto-generate an ontology: a structured map of the entity types and relationships that matter in your world.

For my simulation, it extracted:

Entity Types: Freelancer · MicroAgency · ClientEntity · SaaScompany · IndustryInfluencer · MediaOutlet · ProfessionalAssociation · PublicFigure · Person · Organization

Relation Types: USES_PRODUCT · PROPOSES_TO · COMMENTS_ON · REPORTS_ON · FOLLOWS · COMPETES_WITH · ADVISES · ENDORSE_PRODUCT · REVIEWS_PRODUCT · PARTNERS_WITH

This isn't just taxonomy. It's the system defining how things in this world connect to each other. The GraphRAG Build then took all of this — auto-chunking the documents, extracting entities and relations, forming temporal memory and community summaries — producing 158 entity nodes and 378 relation edges across 10 schema types.

From a UX research standpoint, this is like mapping your ecosystem before running a study. You're not asking one user one question. You're first understanding the full relational context of everyone in the room.

Step 2: Generated Agent Personas — A Population, Not a Sample

Here's where it gets interesting.

MiroFish didn't just generate a few personas. It generated a diverse, contextually-grounded population — each agent with their own role, narrative, topic interests, and behavioral tendencies.

What struck me wasn't just the volume — it was the specificity. Each agent had a coherent professional identity:

behavioral_psychologist_438 — "I dissect ad messaging using deep psychological principles and emotional triggers."
microagencies_917 — focused on "proposal mastery and sustainable client acquisition."
freelancers_927 — "the unified voice for independent professionals."
small_service_business_622 — "navigating manual proposals, awkward follow-ups, and fragmented workflows."

These aren't made-up archetypes. They're synthesized from the reality seeds in my documents. The system found the people in my data and brought them to life.

Step 3: The Graph — Seeing the Relationships

Once the agents existed, MiroFish built the relationship web between them.

[Image: Full Graph Relationship Visualization — the interconnected node map with entity type legend]

Every node. Every edge. Every connection between a freelancer's frustration and a SaaS product's promise. Between a behavioral psychologist's framing of fear-of-rejection and a micro-agency's experience of ghosted proposals.

This visualization is the "matrix of opinions" I mentioned — a literal map of how these ideas intersect across different contexts, platforms, languages, time zones, and professional identities.

As a UXer, this is your affinity diagram. Except instead of Post-its, it's a knowledge graph built from your own source material, at a scale no sprint session could produce.

Step 4: Simulation Environment — How the World Runs

Before the agents start interacting, the simulation needs rules: when are people active? How often do they post? How strong are their community echo chambers?

Key parameters for my run:

72-hour simulation across 72 rounds (60 minutes each)
41 configured agents with activity levels, sentiment biases, and response delays
Peak hours: 17:00–20:00 (×1.5 activity multiplier)
Two platform types: Plaza/Feed and Topic/Community, each with different recency, popularity, and relevance weighting

This matters for UX research framing: you're not just testing what people think — you're testing when and where and how they encounter your message. Context changes interpretation.

Step 5: Narrative Direction — The System's Verdict on My Ads

This is the output that stopped me cold.

After the initial activation orchestration, MiroFish surfaced a Narrative Direction — a summary of what was working, what wasn't, and where the messaging needed to go:

"The current ad narrative is too generic and feature-focused, failing to connect with the deep emotional and practical pain points of freelancers and small service businesses. The desired narrative direction is to shift towards intensely emotional, pain-point-driven messaging that highlights the high cost of uncertainty and inaction (lost deals, mental overload, feeling unprofessional). The discourse should move from 'what Waco3 does' to 'what Waco3 solves for me', emphasizing clarity, control, and increased income by addressing the core psychology drivers of decision-making."

That's not a prompt I wrote. That's the system's synthesis after running my documents, personas, and ads through 158 entities and 378 relationships.

And it was right.

I was talking about features. My users were feeling fear.

Step 6: The Agents Talk — And They're Honest

The simulation also generated an Initial Activation Sequence: the first organic interactions between agents in response to the ads.

Three agents, three reactions:

FREELANCER (marketing_freelancer_529):

"Ever send a proposal and hear… crickets? That deafening silence is costing me deals and sleep. I just need to know if they even saw it, if they're interested. This uncertainty is brutal for my business."

SAAS COMPANY (waco3_953):

"Stop letting 'ghosted' deals cost you income. Waco3 reveals exactly what happens after you hit send, so you can revive stalled conversations and close the deals you deserve."

FREELANCER (automation_freelancer_315):

"Blindly chasing clients feels desperate and unprofessional. I need data to follow up with precision and authority. To know when to engage, what they've reviewed, and what to say next. I want to be an expert, not a chaser."

The gap between what my ad said and what the freelancer felt became undeniable. These agents weren't echoing my copy back to me — they were telling me what they actually needed to hear.

Step 7: Deep Insight — 44 Facts from Temporal Memory

After the simulation ran, I queried the knowledge graph directly using the Deep Insight tool.

Query: "How do freelancers and small service businesses currently struggle after sending proposals?"

Result: 44 key facts, 31 core entities, 39 relation chains — 33.9k characters of synthesized insight.

Top facts surfaced:

A marketing freelancer expresses frustration about proposals being ignored — which Waco3 addresses.
Uncertainty and motivation loss after sending a proposal suggests a need for a solution like Waco3.
Freelancers face emotional bottlenecks in sales — the fear of sounding pushy, the fear of hearing no.
Small service businesses advise gaining buyer intent insights before sending proposals.
The pain of "sending into a void" without visibility is the exact problem Waco3 claims to solve.

This is the triangulation moment. The data wasn't just directional — it was specific enough to rewrite copy around.

What Changed in My Messaging

Before this simulation, my ads were describing what Waco3 does.

After it, I understood what my audience feels before they even know Waco3 exists.

Before	After
"Proposal intelligence for freelancers"	"Stop sending proposals into silence"
"Track client engagement"	"Know the moment they open it. Know if they care."
"Automated follow-ups"	"Follow up with authority, not anxiety"
"Optimize your close rate"	"You're losing deals you don't even know you lost"

The emotional vocabulary changed completely. Not because I invented it — but because I listened to 41 agents argue about it for 72 simulated hours.

The UX Research Framework Behind This

Let me be direct about what this method is — and isn't.

What it is:

A fast, low-cost way to stress-test messaging against a simulated population
A structured method to surface perspectives outside your own bubble
A knowledge graph of how your users' world is interconnected
A directional signal that points you toward the right research questions

What it isn't:

A substitute for real qualitative research
Validated behavioral data
A predictor of statistical outcomes

Think of it as sitting between intuition and research in your workflow:

Simulate fast → Validate direction → Measure in production
  (AI agents)     (real users)         (experiments)

MiroFish collapses the first stage from weeks to hours. It doesn't replace what comes after — it makes what comes after sharper and more focused.

Why This Matters for UX Practitioners

We've been trained to say "it depends on the user." But we've also been put in rooms where the budget is gone, the sprint ends Friday, and nobody has time for research.

Tools like MiroFish don't solve that tension — but they change the math.

Instead of zero data versus three weeks of research, you now have a third option: synthetic signal in a day, derived from your own source material, structured around your specific problem.

As a UXer, what I find most promising isn't the ad-testing use case. It's the broader implications:

Accessibility simulation: How would users with different abilities interpret this flow?
Localization testing: How does the message land across different cultural contexts?
Feature reception: Before building, how do different user types react to a proposed change?
Onboarding stress-test: Where does comprehension break down across different personas?

We're at v0.1 of this category. But the direction is clear.

Final Thought

I started this experiment trying to fix my ads.

What I actually found was a mirror.

MiroFish didn't tell me something I didn't know. It told me something I should have known — and showed me exactly why my current framing was getting in the way of my users recognizing themselves in my product.

That's the real value of a matrix of opinions.

Not prediction. Not magic. Just a structured way to ask:

"How many perspectives am I missing right now?"

The answer, usually, is more than you think.

Tools used: MiroFish · Product: Waco3.io · Stack: Customer persona docs + pain point mapping + ad copy variants

Have you tried multi-agent simulation for research? Drop your experience in the comments — I'd love to compare notes.

Procedural Design: The Moment Design Became Code

Luis Vargas — Sun, 22 Mar 2026 16:59:13 +0000

Procedural Design: The Moment Design Became Code

There's a shift happening in the design industry that we haven't fully named yet. I want to try.

For most of my 15+ years in this field, design has been inseparable
from the tools you use — Photoshop, Illustrator, Sketch, Figma. The
artifact is the design. You open a file, you push pixels, you export.
Repeat.

But something is changing. And I think the best word for it is
procedural.

Design Has Always Been a Communication Problem

Before we get to the "procedural" part, let's step back.

There's a tension design has always carried: aesthetics versus
communication. A beautifully crafted visual with no clear message is
art — it can hang on your wall and make you feel something. That's
valid. But in UX and product design, we've made a deliberate choice:
we're not making wall art. We're building interfaces that help real
people accomplish real tasks.

That shift — from aesthetics toward communication — brought us things
like hierarchy, color contrast, layout systems, and consistent
typography. It turns out that when you strip design down to how well
does this communicate, you get something surprisingly mathematical.
Hierarchy becomes a formula. Contrast becomes a ratio. Spacing becomes
a scale.

That's the seed of what comes next.

Enter Terraform. Enter Houdini. Enter Procedural Design.

If you work in development, you know Terraform. You describe your
infrastructure in code — servers, networks, databases — and you can
spin it all up, tear it down, reproduce it exactly, anywhere. The
artifact is not a running server. The artifact is the code that
describes a running server.

If you work in 3D, you know Houdini. Instead of sculpting a mountain by hand, you write a procedural graph — noise functions, erosion parameters, height rules — and the software generates the mountain for you. Change one variable, regenerate. The geometry is an output, not a source file.

I believe design is entering the same moment.

The Four Buckets

Here's how I've started thinking about it. Any design can be described
as the intersection of four distinct layers:

Styling — colors, typography, spacing, shadows, mood
Content — copy, messaging, hierarchy, information architecture
Inspiration — brand references, visual context, competitive landscape
Technical — target device, breakpoints, component library, accessibility requirements

Right now, when a designer opens Figma, all four of these live inside
their head and inside their hands. The output is a .fig file — a
snapshot of one particular set of decisions.

What if instead, you could feed all four of these buckets into a
system — with natural language — and get a design back? Not as a
replacement for judgment, but as a starting point you can always
reproduce.

This Is Already Possible

With the Figma API and modern AI, this is not a hypothetical.

You can already write a plugin — or interact with the API directly —
to describe a layout in natural language, separate the content layer
from the styling layer, pass in a design token library, specify a
target device and breakpoint, and generate shapes, text, and layout
from those inputs.

The result is non-destructive by nature. You're not editing a file.
You're executing a spec. Change the styling bucket, re-run. Change
the target device, re-run. The design is reproducible because it's
a description, not an artifact.

This is procedural design.

What This Changes (and What It Doesn't)

Let's be honest about what gets disrupted here.

The ability to operate tools — to use Figma, Illustrator, Sketch —
has never been the actual skill. It's been a proxy for the skill. The
real skill is the critical eye: knowing whether a hierarchy is working,
whether the visual weight is off, whether the message lands. That
judgment doesn't come from the software. It comes from years of
training your eye.

Procedural design doesn't replace that. It replaces the hours you
spend translating decisions into pixels.

What it does change: volume. When the mechanical barrier goes down,
more design gets produced. Much more. Some of it will be good. A lot
of it won't be. The ability to distinguish between the two — to look
at a generated layout and say "the hierarchy is broken here, the
contrast fails here, this doesn't communicate the thing it needs to
communicate" — becomes the rare and valuable thing.

A New Opportunity for Designers

Here's the part I want you to hold onto.

Every major tool transition in design history — from physical paste-up
to desktop publishing, from print to web, from handcoding to visual
tools — felt like a threat before it became an opportunity. In every
case, the designers who came out ahead were the ones who understood
the underlying principles well enough to use the new tools
intentionally instead of reactively.

Procedural design is that next transition.

And if you're reading this, you're early. You have time to ask: what
are the inputs that produce great design? How do you describe a
strong hierarchy in words? How do you articulate a color mood before
a pixel is placed? How do you separate what a design needs to
say from how it needs to look?

These are the skills that turn a designer into a design author —
someone who can write the recipe, not just cook the meal.

The tools are arriving. The question is whether you'll be the person
who defines how they're used.

I think you will.

I'm building a lot of this thinking into real projects — design
systems, AI tooling, and a few experiments with the Figma API. If
this resonates, drop a comment or follow along. I'd love to compare
notes.

I got tired of bloated React libraries, so I built two tiny ones

Luis Vargas — Sat, 21 Mar 2026 13:30:15 +0000

I've been building React apps for years, and two things kept frustrating me:

Every animation library I tried was either too heavy, caused unnecessary re-renders, or was painful to sequence. And every date picker pulled in date-fns or moment.js just to format a date.
So I stopped looking and started building. The result is ReactZero — a family of zero-dependency React primitives that are tiny, accessible, and easy to drop in.

Here's what I've shipped so far:

@reactzero/flow — animation orchestration for React

Most animation libraries in React drive animations through state, which means every frame triggers a re-render. @reactzero/flow skips all of that by running animations directly on the browser's compositor thread via the Web Animations API.

The API is built around composable primitives:

import { useSequence, animate } from "@reactzero/flow";

function Card() {
  const box = useRef(null);

  const { play } = useSequence([
    () => animate(box.current, [{ opacity: 0 }, { opacity: 1 }], { duration: 300 }),
    () => animate(box.current, [{ transform: "translateY(8px)" }, { transform: "translateY(0)" }], { duration: 200 }),
  ]);

  return <div ref={box} onClick={play}>Click me</div>;
}

A few things I haven't seen done well elsewhere:

Adaptive degradation: automatically slows or skips animations based on device capability and frame rate
True cancellation: finished always resolves, never rejects. No try/catch needed
Scroll-driven animations: uses native ScrollTimeline when available, with a clean fallback
Reduced motion: provider-level policy system (skip, reduce, crossfade, respect)

npm install @reactzero/flow

🔗 GitHub · Docs

@reactzero/datepicker — accessible date picker, no date library required

12KB gzipped. Zero dependencies. WCAG 2.1 AA.
I tried every popular React date picker and they all shared the same problems: heavy dependencies, hard to customize, and accessibility treated as an afterthought.

@reactzero/datepicker uses only native Intl and Date APIs — no date-fns, no moment, nothing extra.

import { DatePicker } from '@reactzero/datepicker';
import '@reactzero/datepicker/styles';

function App() {
  const [date, setDate] = useState(null);
  return <DatePicker value={date} onChange={setDate} placeholder="Select date..." />;
}

If you want full control over the UI, the headless hooks give you complete ARIA compliance without any of the default styles:

import { useDatePicker } from '@reactzero/datepicker';

function MyDatePicker() {
  const { state, isOpen, getGridProps, getCellProps, getTriggerProps } =
    useDatePicker({ locale: 'en-US' });

  // Build whatever UI you want
}

Ships with 10 built-in themes, 3 density modes, range picker, datetime picker, RTL support, and keyboard navigation out of the box.

npm install @reactzero/datepicker

🔗 GitHub · Live Demo

The idea behind ReactZero

Both packages share the same philosophy: zero runtime dependencies, small bundle, accessible by default, easy to style.

I'm planning to keep adding primitives to the family under that same promise.

If either of these solves a problem you've had, a ⭐ on GitHub goes a long way — it helps other developers find them.

And if you run into anything broken, unexpected, or just have feedback — issues and PRs are very welcome. This is early and I genuinely want to know how it holds up in real projects.

Thanks for reading 🙏

motiondesignlv (Luis Vargas) · GitHub

Sr .Product Designer / Ux Engineer. motiondesignlv has 34 repositories available. Follow their code on GitHub.

github.com