I design agents and skills—not just screens. Here’s what that actually means.

Apparently, I design coworkers now.

Not human ones. The strange text-based kind that can read three hours of research, classify every useful idea, return a perfectly structured JSON file and never complain that the meeting should have been an email.

I have designed several AI agents and skills over the last few years. Some helped a product team turn scattered research into shared knowledge. Some knew an entire SaaS product well enough to advise designers or guide users. Two taught an AI coding tool how I expect motion and atmospheric backgrounds to be built. One watches the market for me so I do not have to turn thirty charts into a morning personality disorder.

They look like prompts.

But the useful ones behave much more like products.

A system prompt is an invisible interface. It defines what the agent notices, what it ignores, how it decides and what the next system can trust.

First: what does it mean to design an agent?

It is not giving a model a confident job title and asking it to “be brilliant.”

If the output matters, the agent needs a designed operating model: a clear job, the right context, explicit inputs, decision rules, boundaries, a predictable output and an honest way to handle uncertainty.

The model provides capability. Design turns that capability into behaviour someone can rely on.

1. The research agent that turned evidence into infrastructure

This is the most important one.

At FounderNest, useful product evidence arrived from everywhere: customer conversations, Customer Success checkpoints, discovery sessions, sales calls, Hotjar observations, heuristic reviews and specific notes written by the design team.

That is a healthy research environment.

It is also an excellent way to create a swamp.

Different formats. Different languages. Different levels of detail. Insights mixed with leading questions. Several ideas hidden inside one paragraph. And every new session adding more evidence before the previous one had been made visible to the team.

I designed an agent to make that knowledge operational without flattening it.

Its job was not to summarise

Summaries feel efficient because they are shorter. They are also very good at deleting the awkward detail that later explains why a product decision was wrong.

The agent used a two-pass process. First, it identified every distinct idea in the source. Then it produced exactly one structured object per idea. No arbitrary sample. No “top five themes.” No quietly merging two comments because they sounded similar.

Spanish insights were translated into clear English. English insights were rewritten for clarity. In both cases, the meaning had to remain intact.

It also looked for bias. If a user’s answer followed a leading question—“Would you like this feature?”—the agent separated the actual statement from the framing and made the potential bias visible.

A taxonomy built around product decisions

Each idea was classified across four dimensions:

• Discovery type: pain point, need, behaviour, feature request, workaround, aha moment or prototype feedback.
• Product journey: from onboarding and Spaces to company discovery, analytics, reports, tracking or team management.
• Mental model: navigation, content generation, discovery, management, collaboration, intelligent assistance and more.
• UX pattern: system visibility, recognition over recall, user control, consistency, error recovery and other relevant principles.

The point was not to create tags for the joy of having tags. It was to let the team move from “we heard something about search once” to a body of evidence that could be filtered, compared and connected to a journey or product principle.

JSON was a product decision

The output followed one exact schema: sequential ID, original insight, processed insight, the four classification dimensions and additional notes. Every object used the same keys. Every run returned one valid JSON array and nothing else.

This sounds technical.

It was mostly about trust.

A stable output meant the agent could hand its work to a larger system. Behind it, n8n processes automated the publication of conclusions, grouped the data and created the tables the wider team used to explore what we were learning.

The agent did not replace research synthesis or product judgment. It removed the repetitive structural work that prevented evidence from reaching those conversations in a useful state.

That distinction matters.

Automation should not make research look more certain than it is. It should make the evidence easier to inspect.

2. A Product Design Advisor that knew the actual product

Generic design advice is easy to generate.

“Reduce cognitive load.”

“Use progressive disclosure.”

“Have you considered user testing?”

All correct. All capable of being completely useless.

I designed a Product Design Advisor for AI-driven SaaS work that used FounderNest’s own product documentation as its foundation. When a question involved the product, the agent had to consult that knowledge first, name the specific feature or flow it was drawing from and explain how that context affected the recommendation.

Its answers followed a designed sequence: recap the problem, recommend concrete steps, explain the product or UX rationale and define the next iteration.

More importantly, it had boundaries. It focused on actionable product design. It could support research or copy when those informed the design decision, but it could not dissolve into a generic startup oracle with an opinion about everything.

The goal was not to simulate a famous Silicon Valley designer.

It was to preserve context so a design conversation could start one level deeper.

3. A product guide designed to say “I don’t know”

The next agent had a simpler job: help people understand and use the product.

Its source of truth was the product manual. It explained features, gave practical steps and adapted the depth of an answer to the person asking.

The most important feature was not the friendly tone.

It was the refusal to invent.

If the manual did not contain the answer, the assistant had to say so and offer the closest documented information. If the question was ambiguous, it asked for clarification. Accuracy beat creativity.

For a product assistant, “I don’t know” is not a failure state. It is often the most trustworthy feature in the whole experience.

4. Two CSS skills that turn taste into repeatable execution

Agents are not the only useful way to package AI behaviour.

I also created two skills for Claude Code: one for CSS animation and one for premium atmospheric backgrounds.

A skill is narrower than an agent. It is a reusable capability triggered by a type of task. Instead of explaining my expectations every time, I encoded the principles, constraints, workflow and quality checks once.

CSS Animations

The animation skill handles transitions, keyframes, loading states, shimmer, hover lifts and microinteractions without adding JavaScript or dependencies.

But the interesting part is not the list of effects. It is the taste encoded in the constraints: animate transform and opacity instead of layout; never use transition: all in production; preserve focus states; keep content visible if motion fails; respect reduced-motion preferences; never delay an error, consent prompt or destructive confirmation for visual theatre.

In other words: motion should explain state and improve perceived quality—not audition for attention.

Atmospheric Backgrounds

The background skill starts with an audit and a visual direction before touching CSS. It builds depth through layered gradients, independent ambient motion and optional grain, with a responsive-safe canvas that does not stretch into a different composition on every viewport.

It also contains the unglamorous rules that make the result usable: stable stacking, pointer-events disabled on decorative layers, foreground contrast protected, motion removed when requested by the system and grain tuned down on small screens.

The skill does not say “make it premium.”

It defines what premium restraint looks like in code.

5. A personal market assistant built around my actual behaviour

The last one is a personal experiment.

I am a long-term investor. I prefer holding, dividends and reinvestment. I do not enjoy selling during volatility and I definitely do not need an agent yelling that every red candle is the end of capitalism.

So I designed a daily market assistant around the decisions I genuinely make.

It monitors four signals—DIX, DXY, credit spreads and volatility—then turns their combination into a short interpretation for my portfolio: whether to reinvest dividends, accumulate selectively, pause new purchases or simply observe.

The rules prioritise caution when indicators conflict. The output stays concise. It does not flood the report with data or pretend every day requires action.

It is not financial advice, and it is not trying to beat the market.

It is a decision interface designed around one user’s goals, biases and tolerance for noise.

What designing these systems taught me

The more agents I build, the less interested I am in the theatrical part of AI.

The useful work is familiar product work:

1. Start with the job. “Be an expert” is a persona. It is not an outcome.
2. Context beats confidence. A grounded answer is more useful than a brilliant generic one.
3. The output is an interface contract. People need clarity. Automations need consistency. Design for whichever receives the result next.
4. Uncertainty needs behaviour. Define when to ask, when to mark something unclear and when to refuse to invent.
5. Automation raises the stakes. Once an output feeds n8n, a table or another system, a small ambiguity can scale quickly.
6. Constraints create personality. The strongest voice does not come from jokes or adjectives. It comes from having a clear point of view about what good work is.

Final thought

I still design screens.

But increasingly, I also design the invisible systems around them: how evidence becomes knowledge, how context survives a handoff, how an AI decides what to say and how a team can reuse good judgment without starting from zero.

That is what agents and skills are to me.

Not artificial coworkers with impressive biographies.

Designed behaviour—made useful, bounded and repeatable.

V.