Integrating Agentic Processes

Integrating Agentic processes into Design.

I’ve designed a lot of AI Agentic features, going back to 2015 when I worked with Twitter to apply ML to news sources.

A lot has changed since then, especially in terms of utilizing AI within the design process itself. As a technique or tool it is, obviously, moving very quickly. But the general thesis I still hold is that AI is based on historical precedence, not on future possibles. It can only learn from what has been done before. It’s also not empathic, cross-contextual or humanist, so by its nature it does not replace design, but rather allows the designer to remove the accruing detritus that was modern Product Design practice.

That detritus was systematic repetitions, basic UX loops, validated mass-behaviours, standardizations, accessibility baselines, dark / light transitions, accurate luminance steps, colour spreads, grids, etc. This detritus is the solved problem foundation on which the human layer needs to operate, and it frees up the designer to focus not on basic usability mapping but on more complex and human level problem solving.

I’ve been slowly incorporating Claude into my Product work over the past year or so with mixed results. I’ve found that in some cases it is productive in removing detritus, but often it applies a heavier cognitive load on non-scaleable processes. In projects where I found setting up Claude processes to deliver accurate or desirable results to be more work that quick execution in Figma, I’ve found myself defaulting to the artboard.

Fixing context drift.

I began deploying Claude Code at scale in the product build process at AOT Technologies in early 2026. One of the immediate problems that began to surface was context drift.

Context drift is where the LLM model will take a prompt, and through process of visual revision, effectively hallucinate with no fall back and slowly become forgetful, regress and eventually breakdown. What this looks like in reality is iterating a design - say a settings page - a known detritus - and the iterative process adhering to designer-led guidance until it begins to regress. The natural action then is to recover the regression, which then accelerates the regression, because the process of recovery involves human suggestion to roll back the logic chain. Effectively the AI forgets the more it iterates, and is then unable to maintain multi-string context over extended durations.

I began working on a fix for contextual drift by engineering Claude Code with GSD frameworks. I asked Claude to render a basic UI that could deploy GSD at scale for projects.

GSD forces Claude to reconcile each step in a prompt thread through external written summary. That summary is verified by the human before it’s re-ingested into the prompt loop, thereby creating milestone progressions from which Claude can recover from using a central indexed iterative log.

Deploying this GSD UI allowed us to begin to leverage Claude Code in a more stable, consistent manner, but deploying it beyond my team was difficult give the lack of central cloud hosting in Claude Code, and the complex nature of Claude Code’s reliance on the Command Line.

It’s definitely the correct approach for lone-designer contextual prompting and it does have legs, but at the time it’s failure to scale cross-team or allow for active collaboration with file merging began to quickly invert the cognitive effort.

Another deciding factor was token burn. While the results were encouraging, the cost of iterative process, including using GSD frameworks became prohibitively expensive for regular workflows. I do think, however, for quick product validation that token cost is probably worth the potential sunk costs in development.

What this process led me to was deciding to move away from the CLI into the UI model and trying to leverage better results using structures projects, skills and better human-in-the-loop interactions. Moving the bulk logic to iterative Figma / Figma MCP removed a large chunk of the regressive issue given that the Figma could be used to recenter the LLM, reducing regressive behaviours.

Leveraging MCP.

Figma MCP is pretty well understood, as is Figma Make. Figma Make is pretty straightforward as an AI enablement and it fits into the Designer workflow quite well, even if it is more than a little affected by contextual drift.

At AOT I had already spend some investment in creating a relatively solid Design System based on components and tokens. Figma MCP was a great first step towards testing automation at scale.

The issue I was dealing with in the Design Team was that the Marketing team was relatively siloed creatively. So this meant that while the Product was designed using one system, the Marketing aspect would try to approximate the Product in their output. And that output was dynamic - multiple use case landing pages, dynamic copy and assets, pages being spun up, spun down, redirected and A/B tested.

Figma MCP allowed the Marketing Team to leverage the Design System in the utilization of their own Product efforts, often unifying the acquisition funnel into the Billing funnel into the Onboarding funnel. This made for a much simpler, linear experience for the user, and it hid the mass-diversity of pages, rerouting and platform variations that each random path introduced.

This was a very successful way of leverage Figma MCP at scale, and I’m interested in trying to closer automate the process using Cursor and Webflow in spinning up pages on demand, and reacting to real time metrics.

From the Designer’s point of view, this MCP execution is ideal - it allows the creative direction to be closely maintained, versioned and iterated, with the Marketing deployment automating downstream of the Figma Point of Truth. It massively cuts down the endless Marketing request cycle, or, depending on your organization, the endless revision loop. This proof-of-concept then allowed the build-out of a more structured design system, annotations and skills with Figma as the core.

Exposing the Design System.

Figma does have some issues however. The primary issue with Figma as a centralized anchor point is it uses proprietary classifications - the core of which revolves around Tokens and Components which need translation. Claude (or any LLM-based AI) does not ‘see’ the token or component, but rather ‘reads’ it, which means that the token or component has to be explained to the LLM with clear indications of use, context and limitation. Claude will then ‘read’ the token or component and decide based on the conversational context if to - and how to - use that token of component.

As an example, if your warning colour is a specific red, you have to annotate that specific red token as a ‘Warning’ red, provide context of when it is used and explain the limitations. So this may read as:

Use: Only in dismissible states on the CTA rollover or active state
Avoid: Any other environment or in conjunction with any other surface colour
Note: Must accompany a written ‘Warning’ tag whenever used

Likewise, components require the same contextual annotations. As the design system becomes more complex, the tokens and components will begin the interact in specific ways - a Warning token will render in a component, after a certain user behaviour. This too needs to be considered and mapped, and often it is better to expand the number of component variants to offset the need for deeper contextual annotations.

This is overhead and it requires ownership. It may require co-authorship and peer review of the design system, or it may (more wisely) require the growing design system to be compartmentalized into like-behaviours or co-dependencies. The design system and its annotations become the foundational layer / root of anything built on top, and this means that it requires a solid early foundation with solid, scaleable logic underpinning it. It also means that it becomes a critical layer for iteration - as new features are built, new tokens added or edited, new components created - the design system must maintain it’s solidity.

Building complimentary skills.

Claude works best in my opinion if you treat the design system as the SPOT (Single Point of Truth) and skills as broader creative direction. If you apply granular-level “Use this token in this component when X happens” it will likely cause logic clashes between the contextual conversation the builder is having, the note on the token and component in the SPOT and the skill itself. I’ve found it more useful to overcompensate at the SPOT level (and tie this to an iterative cycle) then build skills above this layer which are more generalist. Skills should be specific to your organizations context, not generic UX behaviours. You can write skills which are more generalist - and I do - Accessibility is a good example of this, where there may be overrides, trade-offs or strict brand-orientated behaviours that go beyond standard web accessibility norms.

Skills can be written offline or in a central collaboration space (such as Google Docs) rather than directly into Claude. I prefer this approach as it allows for iterative process and peer review. They can then be uploaded as .md files.

For a team who is newly adopting this approach, the best starting point is to list the skills you need based on the standard thought processes you use everyday. Some good early skills to begin with are:

/designsystem
This is defining at a higher level what the design system is, how it works, it’s logic and how to navigate it

/critique
This is about creating baseline critique considerations. They could be data driven, they could be heuristic, they could be use-case orientated

/access
This is defining your accessibility standard. It could be a known accessibility standard, or it could be a more detailed standard based on client requirements, branding considerations or other variables

/copy
This is a useful skill to add around product copy - tone of voice, how buttons are named, how actions are described. It provides a good first-pass that makes product copy considerations easier to critique

/ spec
This turns an outputted design into a handover document / spec providing a report that states all states, error cases, behaviours, unknowns and expected outcomes. It’s a good logic chain piece which helps to improve design system annotation and skill definitions

Skills need to be stabilized. So the creation of your skills on top of your design system will probably cause some very weird edge cases and problems early on. This means you have to iterate and tweak as you go on to align the design system with the skills set. It’s best to judge your design system and skills in terms of raw output from a typical multi-turn conversation, adjusting as you go.

I’ve found skills to be best defined as high-frequency broad thought processes. So not component specific, not edge case or occasional, nor too generic. If a ‘skill’ you require is general or generic, then this can be handled in the prompt, or most likely be inferred as part of the general Claude model already. One way to determine if a skill should be added is to ask ‘do I explain or ask this same thing once or more a week as part of my workflow?’. If the answer is yes, then it’s likely a good skill candidate.

Building advanced skills.

As skill and design system stability grows, it can be worth increasing the skill set in line with team workflows. I’ve found some success in implementing a range of complimentary skills that can target detritus, but they may not be applicable for everyone - every team realistically should find a consensus on what to leverage and how.

(a) a skill which lists every state a screen, flow or component needs (i.e a loading state, and error state), checks if they are present and flags anything missing or incomplete

(b) a skill which can review a flow and test it for dead ends, missing states or inconsistent patterns

(d) a skill which checks proposed components or patterns against what already exists. This is particularly interesting as a means to aid in the simplicity of the design system - more of a meta-skill that reviews most used patterns, and suggests if proposed changes are truly variants or simply a new component type

(e) a skill which can turn a sales or other leadership request into a executable brief with suggested constraints and unknowns - this can be useful if the org has an ‘idea ingestion funnel’ which can generate bias in the consideration of the proposed features

(f) a skill which can quickly present a report on a piece of design work for easier communication - this is particularly useful in asynchronous environments

(g) a skill which handles better handoff to development. I’ve created these before in CLI and Web, CLI often being the most effective but the most overhead. I see this as an unsolved skill, but one which, obviously, largely depends on the design to development interface. It could be a written report, a change log - but it could also be an integrated change agent between the SPOT and the code base.

Handoff skills are really the biggest fish to catch and they can be handled in the Claude design process through skills, or they can be handled in the CLI as a process. Another option is to take the concept of handover as it’s own agentic brief, generating an independent agent working on a tightly controlled ruleset and skillset that works independently to verify the handover and optimize the required communication.

Largely though, advanced skills are build on the foundation of the baseline skills, which in turn are built upon the SPOT (Figma design system). With this in mind I find that by the time the skills are being written for handovers (either in CLI or Web) there is enough defined process to suggested the preferred path.