Leading by design.

AI Product Builder, designer,
team lead.

I take AI from pilot to production.
Forward-deployed or in a leadership role, with the teams who run it.

Getting AI into production is a design challenge as much as a build problem. With twelve years of design, including enterprise UX at Shell, Roche, Philips and ING, and two years building AI systems in production, I work at the intersection of both. I design the retrieval architecture, the guardrails, the evals, and the human-in-the-loop workflows that keep a system honest once it ships. And I design the adoption: the interfaces, the workflows, the organisational logic that brings a team along. The system is half the work. The design around it is what makes it land.

Available for a permanent leadership role in AI, for forward-deployed engagements to build and ship AI products, and for interim roles to set up an internal team.

Two years of AI in production.
Twelve years of design before that.

Professional profile portrait of Dusty Baars
Built and run myself

What's running.

Six systems I designed, built, or made my own, and use every day. Each one in production, born from a problem of its own.

This is a selection. Everything here runs in production, and I am happy to demo it live, by appointment.

These are the systems themselves, live.

Open Brain Peek inside
01 · Open Brain

Memory that lives between my tools.

A memory layer that hangs off all my applications through MCP and records how I work. Every session starts with context instead of from scratch, and after months of use the system suggests its own skills and tasks.

Built with Claude Code · PostgreSQL · MCP · Railway

Read the full case →
Mono Dash Peek inside
02 · Mono Dash

One point of contact, a team that organises itself.

An orchestration layer where you steer a single CEO agent, which assembles a team and splits the work across roles. Each agent tracks its own status and clears blockers itself first, while you watch, step in, and get a ping the moment a decision is needed.

Built with Forked and taken to production · Next.js · Railway

Read the full case →
Panion Peek inside
03 · Panion

A companion with a memory that stays.

A companion app on a lasting memory that gets better the more you use it. Conversations sort themselves into themes you return to, you tune the personality live, and through MCP your companion travels to your other tools.

Built with React · Claude · MCP · Voyage AI

Read the full case →
Consilium Peek inside
04 · Consilium

A debate, two flagship AIs, one tested answer.

Pose a hard question and let two of the strongest AI models fight it out until they agree. What remains is an answer tested from both sides, with conclusions you can export and share straight away.

Built with Claude + Gemini · Hono · SQLite · Railway

Read the full case →
From order to invoice Peek inside
05 · From order to invoice

An order that handles itself, except for my decisions.

An order comes in by email, gets picked up automatically and runs through the whole process to delivery: photos pulled out, folders set up, admin updated, client notified. At the end of the month the invoices sit ready in draft. I only step in at three points: the go up front, the quality check before delivery, and one press of send for the invoices.

Built with Gmail · Make · Google Drive · Notion · Moneybird

Read the full case →
Memo Peek inside
06 · Memo

A help line that gets smarter with every question.

Memo is an agent inside Memortium's app where clients can ask a question or place an order straight away. Memo helps on its own first and connects them to me when needed. Every question that comes in becomes data: I turn it into articles, feed my outreach with it, or sharpen the service. A closed loop that keeps improving itself.

Built with Claude · Next.js · Notion · Railway

Read the full case →

Tools I'm fluent in

Design

Figma · Photoshop · Lightroom · Miro

AI & build

Claude Code · Antigravity · Codex · Google Gemini · Google AI Studio · ChatGPT · Perplexity · Manus · Make · n8n

Deploy & the usual

Railway · Docker · GitHub · Tailscale · Notion · Airtable · Office · Google Workspace

What I solve

Recognisable problems. My approach.

The systems above are the proof. This is how I put them to work on problems you will recognise.

Illustration representing transition from proof-of-concept to production system

I take AI past the pilot, and keep it running.

Most AI implementations stall on the distance between the tool and the daily work. I take a proof of concept to production in contained building blocks with a measurable outcome, start with flows instead of tools, and put the operational backbone in place from day one, including governance and EU AI Act readiness. Memortium has run that way for over a year, with thirty paying clients and two hours of my time a week.

Two things make that possible: my design experience and my AI build skills. Over twelve years of enterprise UX show me where work stalls and how people come to trust a system. The agentic build practice I run every day turns that into working production in days instead of quarters.

Illustration of model routing strategy showing token cost breakdown

Cost discipline lives in the architecture, from the first line.

The token bill often grows faster than the value beneath it, because the heaviest model gets pointed at every task. In production I route each task to the model that fits it: cheap work cheap, the heavier models only where they pay off.

These choices are not made on instinct. I know the shape of the models I use daily and where a lighter one takes over without losing quality. Token economics and FinOps are baked into the architecture, so cost scales with value and not with volume.

Illustration showing multi-agent workflow orchestration with human approval gate

My agents hold up outside the demo, too.

Agents that shine in a demo often fall over in production: a missed edge case, a handoff that breaks, a tool call with no safety net. The multi-agent setups I run hold up, with guardrails and human-in-the-loop where a mistake counts, and Mono Dash handling the orchestration.

The difference is knowing what an agent can credibly do, and where it turns into wishful thinking. I design the orchestration layer underneath: who hands off to whom, where state lives, where the approval gate sits. Evals and guardrails keep an agent fleet honest when it actually counts.

Illustration demonstrating UX confidence factors and user adoption patterns

I design AI that people understand and trust.

Adoption is where most rollouts die. The tool is there, the licences are paid, and still nobody reaches for it. What is missing is a design for how the system fits the workflow, and whether people trust it enough to open it.

That is my foundation. Years of enterprise UX taught me exactly where adoption breaks, and I design for it: confidence indicators, a clear fallback, human-in-the-loop where it counts. I handle adoption and change with training inside the work itself, tied to the flow people just picked up.

A rollout only succeeds when everyone comes along, from Annie at reception to Johan in the boardroom.

Illustration of business requirements mapped to tech architecture

On both sides of the bridge: building, and knowing what a choice costs.

There is a gap between the people who build AI and the people who carry its consequences: engineers who do not speak the business, leaders who do not know what a technical choice costs. I stand on both sides, from years of cross-functional work at Shell, Roche, Philips and ING and two years of 0-1 product ownership on my own ventures.

I translate a business goal into an architecture, and an architecture choice back into what it costs and returns. In a world where building takes days, the split between who advises and who builds disappears. I fill that role myself: designing and building in one motion, with stakeholder management and the team in control.

Illustration showing compliance timeline and governance checkpoints

Governance belongs in the building block, not bolted on after.

The AI Act applies in full from 2 August 2026. Bolt governance on afterwards and you stall on questions no one can answer anymore: who saw which data, where a decision came from.

I build it in from day one. Per agent it is set what may run autonomously and what goes to a person, with logs and an internal owner who signs for exceptions.

Approach

How I work.

Mastering the technology, bringing teams along,
leading by continuing to create.

And one rule I hold myself to: I take on work that has to deliver a result, not hours. If a lighter answer serves you better, that is the advice you get.

Technique

The AI layers I keep sharpest.

  1. Context engineering

    The real work sits a layer below the prompt. I design the RAG layer: retrieval pipelines, chunking strategy and attribution, so an answer stays grounded even as the source set grows from ten documents to ten thousand.

  2. Agent orchestration

    The orchestration layer comes together around handoffs, shared state and approval gates. A fleet of agents turns into a system only once it is clear where a human steps in, and what happens when a single step breaks.

  3. Agent design and limits

    I design an agent from what it can reliably handle. Role, model and guardrails track that limit, so it keeps its promises in production as volume climbs.

  4. Token economics and FinOps for AI

    Cost is a design variable I steer from the start. Model routing, caching and token budgets that move with demand keep the unit economics standing while a feature scales from pilot to real volume.

  5. Model selection

    I choose a model by its shape: Claude for reasoning and writing, Gemini for multimodal and large context, smaller models for orchestration. The architecture is built to switch as the landscape shifts.

  6. Production fluency and LLMOps

    My design starts from the way models actually fail. Confidence indicators, fallback paths, human-in-the-loop boundaries and evals go in from the first version, because an AI error in production is an instant breach of trust.

  7. Memory architecture

    Memory is a first-class part of the design. What is kept, how it decays and who can edit it are deliberate choices, because that is what lets a tool grow with a team.

  8. AI governance and EU AI Act readiness

    Governance is a design problem I take on well before 2 August 2026. Inventory, risk classification, human oversight and audit-grade documentation sit inside the architecture, so compliance grows with the system. Detailed in Case 07.

Coaching

Building the system is half the work.

The people who use it daily are the other half.

Flow first, then the tool.

The same workshops I learned in twelve years of enterprise UX, now with AI in scope. Map the flows, find the seams, align on what humans keep.

The result is a shared picture the whole team stands behind: where AI belongs, where it does not, and what stays human work. Most programmes skip this step. That is where they run into trouble later.

Flow first, then the tool.

The same workshops I learned in twelve years of enterprise UX, now with AI in scope. Map the flows, find the seams, align on what humans keep.

The result is a shared picture the whole team stands behind: where AI belongs, where it does not, and what stays human work. Most programmes skip this step. That is where they run into trouble later.

Leadership

At home in a multidisciplinary team.

A leading role is my preference, but the right team and the right work matter more than the role.

Small and sharp.

My best work happens in small teams of three to six, close to the problem. Small enough to see the whole, sharp enough to move quickly.

Mixed to fit.

The shape depends on the work. Sometimes three engineers and a designer, sometimes a researcher, a designer and two builders, composed around what the problem asks.

Cross-functional by default.

An AI program touches engineering, product, legal, security, GTM and comms. That broad instinct comes from a decade of cross-functional work inside Shell, Roche, Philips and ING.

Leading by building.

Steering and building run together for me. Most of my week stays on the work, the rest on direction, stakeholders and bringing the team along.

The Work

Approach in production.

Systems in production, the playbooks they taught me, and the foundation underneath.

The stories behind the work: what the problem was, what I chose, and what it returned.

  1. Thumbnail of Open Brain architecture diagram
    Case 01

    Memory across tools.

    Vendor memory stops at the platform boundary. What you build with one tool is invisible to the next.

    One open layer under everything. Three agents, six applications, no context loss.

    • AI Agents
    • Tool Use & MCP
    • Context Engineering
    • Production
    • Model Routing
    • Infrastructure
  2. Thumbnail of Memortium order automation pipeline diagram
    Case 02

    Forty orders a week. Two hours of work.

    Thirty paying clients, forty orders a week, in a category where a wrong result is unacceptable.

    One operator, six agents. Two hours of work a week, billing and follow-up automated.

    • AI Agents
    • Tool Use & MCP
    • Model Routing
    • Guardrails
    • Production
    • Automation
  3. Thumbnail of 90-day AI organizational rollout timeline diagram
    Case 03

    How AI lands in an organisation.

    Most AI rollouts fail on adoption. Nobody designed how the tool lives in the organisation.

    A ninety-day plan. Map the flows, ship one pilot, train on real work, govern from day one.

    • Leadership
    • Training
    • Context Engineering
    • Guardrails
    • Evals
    • Playbook
  4. Thumbnail of scale-up problems and matching solutions diagram
    Case 04

    Three problems. Three systems.

    Three problems every scaling team hits: data with no answers, tools that won't talk, customer volume outrunning the team.

    Three production systems purpose-built for each one. The build story, and the path to integrating them in your stack.

    • AI Agents
    • Tool Use & MCP
    • Production
    • Context Engineering
    • Model Routing
    • Building
  5. Thumbnail of AI design system pattern families diagram
    Case 05

    Patterns before components.

    Teams ask for AI components and skip what decides trust: context, handoff, memory.

    The four pattern families to document first. Patterns before components.

    • Context Engineering
    • Guardrails
    • Tool Use & MCP
    • Leadership
    • Design System
  6. Thumbnail of client portfolio timeline diagram
    Case 06

    Twelve years of design, now in AI.

    Twelve years of enterprise UX at Shell, Roche, Philips and ING, embedded through Plat4mation.

    The foundation under everything else here. Now the ideas ship in days.

    • Leadership
    • Training
    • Context Engineering
    • Foundation
  7. Thumbnail of EU AI Act compliance map diagram
    Case 07

    Governance by design.

    The EU AI Act becomes fully applicable on 2 August 2026. Most scale-ups are not ready.

    Inventory, classification, designed oversight, audit-ready. Governance as a design problem.

    • Leadership
    • Guardrails
    • Evals
    • Training
    • Governance
Foundation

Over twelve years of enterprise UX.

Before I built AI, I spent over twelve years designing for large organisations. User research, usability and interaction design, and leading design teams inside the engagement. Through Plat4mation, EMEA's largest pure-play ServiceNow Elite Partner, I worked for Shell, Roche and Philips, and before that at ING. Custom rollouts for thousands of users per client, cross-functional with engineering, product, legal and compliance. This is the foundation under my AI work: where I learned where work stalls, and how to build something people will actually use.

Competencies

  • UX design
  • UI design
  • User research
  • Usability testing
  • Interaction design
  • Information architecture
  • Design systems
  • Design thinking
  • Design leadership
  • Stakeholder management
~1 year

Shell

Complex internal platforms for a global organisation. From business requirements to working interfaces, with stakeholder management at enterprise level. This is where I learned to design for scale and for decision-makers at once.

Designing for scale · Stakeholder management · Winning over decision-makers
~2 years

Roche

A pharmaceutical platform for an international user base. Design thinking workshops on-site in Basel with healthcare professionals, and designing in a strictly regulated environment where a mistake carries direct consequences. Security-first and compliance-aware throughout.

Regulated environment · Security & compliance · Design-thinking workshops
~1 year

Philips

Enterprise tools for internal teams, the full cycle from discovery to a working design system. Worked closely with the development teams on implementation, so the design actually landed in the build.

Discovery to design system · Working with engineering · Implementation
~2 years

ING

Started here guiding startup and innovation teams with UX and UI design. Brought tough banking workflows back to their logical core, with a scalable information architecture and iterative usability testing. This is where I saw how strategic design shapes the direction and decisions of an organisation.

Strategic design · Information architecture · Usability testing · Team lead

Origin

It started with Dumo Media, the studio I set up with a partner right after my degree. We worked for a range of marketing agencies and ran activation campaigns. That is where I learned to switch fast, prioritise sharply, and design work that delivers measurable results: +25% conversion on the UrbanStays booking flow, +40% scheduling efficiency on Planly. From that entrepreneurial start I moved into ING, and later into the enterprise engagements through Plat4mation.

Working together

How I'd land AI with you.

Two tracks under one roof. Building with AI as the signature, lifting the whole floor as the mission.

Track 1: Working with AI

The natural second step after the baseline. Lifts the large middle group to confident daily use, hands-on with their own tasks.

Track 2: Building with AI

From idea to a working thing in hours. The group brings a real idea, we build it live, and they leave with a working prototype and the method to do it again.

Whitepapers & workshops

The thinking behind the work.

Longer-form pieces on how AI actually lands inside an organisation. Sector-agnostic, with cases as the evidence.

Portrait of Dusty Baars hiking in nature
About

Dusty Baars.

Nothing moves me more than making something and watching it work. That has always been the case, and it stays the engine. But what really gets me out of bed now is a responsibility I feel growing heavier. AI is coming into every company one way or another, and how that happens makes all the difference. Whether it makes people stronger, or leaves them behind.

What guides me through it is one conviction. Technology should make people better, not replace them. The difference lies in how you design it and whether you bring people along, from Annie at reception to Johan in the boardroom. That is where I want to be a beacon. Someone who does not do it over people's heads, but with them.

Work I take seriously, myself a little less. Clear agreements and working without fuss, that is what I like, and if something can be better I say so. It makes the work sharper, and me too. I learned this craft by doing it in production every day. Honestly, I was already doing the right things before I knew what they were officially called. Letting go before something is truly finished still stays hard for me. But if that is my worst vice, I think I get away with it.

Outside work, a family in Amsterdam keeps my feet on the ground. In my free time you will find me hiking, travelling, or somewhere enjoying a good meal. Gaming has been with me since the Atari. Easy to work with, and always curious about what is new. Mind and body stay sharp by keeping busy. The day I stop is the day my battery is empty.

Read the longer story →

contact@dustybaars.com · +31 62 0703778 · Amsterdam · 52°22′N · CET

Available for a permanent leadership role in AI, for forward-deployed engagements to build and ship AI products, and for interim roles to set up an internal team.