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 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 discovery 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. 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.
Leveraging MCP.
One successful AI integration which did solve significant problems in cross-team collaboration was Figma MCP. But probably not in the way you’d think.
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 Marketing automation.
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.