Leading by design.

Designer, team lead,
AI builder.

I lead applied AI from concept to production, with the teams who run it.

Over twelve years of enterprise UX at companies including Shell, Roche, Philips and ING, through Plat4mation. The last two building AI in production: Memortium, Open Brain and Mono Dash, plus dozens of apps, skills, plug-ins and automations around them. After two years solo, I am reconnecting with like-minded people to shape this AI transformation together.

Everything here runs on one conviction: AI should make people better, not replace them. I build the systems that prove it, and bring the teams along who have to feel it.

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

Available for a permanent leadership role in AI, and for defined interim or project engagements to set up an internal AI team.

Professional profile portrait of Dusty Baars
Built and run myself

What's running.

Four 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.

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

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

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

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

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 retrieval, structure 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

Cases.

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.

I love pace. When I have an idea, I want to build it quickly and see it work. After years of building, that now feels natural: thinking and making happen at once. AI helps with that, but my starting point stays the same. Technology should make people better, not replace them. Honestly: I still find it hard to let go before something is truly done.

I take the work seriously, myself a little less. I like clear agreements and working without drama. If something can be better, I say so. That makes the work sharper, and me too.

Staying still is not for me. I live in Amsterdam with a family that keeps me grounded. Otherwise I am almost always busy with something, especially things I do not yet understand and want to learn.

I keep my fluency current on the AI stack because the work I want to do depends on it. Skills, context, token routing, model selection, agent orchestration, memory architecture, governance design. For me these are not separate disciplines, they are the layers of a single system that has to work. That is why this is the right next step.

Read the longer story →

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

Available for a permanent leadership role in AI, and for defined interim or project engagements to set up an internal AI team.