I have worked in AI for the last few years, but AI is not where my work started.
I started by making things. Design, motion, production, advertising, learning experiences, software, websites and the messy operational work required to get creative ideas through production and into the world. Over time, the problems got larger. The work moved from making individual artifacts to designing the systems, standards and experiences that helped other people make better work.
That progression is the reason I approach AI differently than someone whose career began with the tools.
I learned the work from the inside out
Early in my career, I spent years close to production. That matters more than it might sound. Strategy behaves differently when you know what happens after the presentation is approved. A beautiful idea can collapse because the process cannot support it, the system is too difficult to use or the people responsible for delivery were never considered when the decision was made.
I learned to care about whether the work survives implementation.
Later, at Lions Clubs International, the scale changed. I worked on global digital experiences serving a membership operating across 203 countries and 13 languages. Designing something for that environment forces you to think beyond the ideal user sitting in the room with you. The system has to work across contexts, constraints and very different people.
At Meta, the problem became systems
My work at Meta changed the question again. I had already spent years making things. Now the challenge was helping a large organization make things consistently and well.
I worked across creative production, learning, experience strategy, design systems, product strategy and change management in an environment serving roughly 50,000 employees. I built visual identity systems, helped redesign production approaches and worked on tools and experiences that had to be adopted by people beyond the team that created them.
The lesson I carried forward was simple: building the thing is only part of the job. The system around the thing determines whether it becomes useful.
AI changed the speed, not the responsibility
When generative AI became capable enough to change production, I did not see it primarily as a writing tool or a faster way to create images. I saw an opportunity to compress the distance between an ambiguous problem and a working system.
Since leaving Meta, I have spent the last three years applying that idea through client work and original AI products. I built BNA72, a 72-archetype identity system designed to create much higher-resolution profiles than conventional personality categories. I built AskSociety, a decision-research product that uses psychologically distinct digital residents to expose support, resistance and disagreement before a decision is made. Around that work, I have built systems for content, brand, research, outreach, production and internal AI workflows.
The important part is not the number of tools. It is the pattern behind them.
Find the real problem. Understand the people and context around it. Decide what deserves to exist. Build enough of the system to make it useful. Test it against reality. Keep the parts that work. Improve the infrastructure so the next problem starts further ahead.
What that means when I work with a company
If you bring me a vague business need, I am comfortable before the answer is obvious. That is usually where I am most useful.
I can move between strategy and implementation because my career has required both. I can talk about positioning and then build the page. I can map an operating problem and then prototype the internal tool. I can research an audience, develop the message, create the production system and help the team use it. I can also tell you when the answer should be a specialist rather than pretending one person can responsibly own every technical problem.
That range is not an argument that I should do everything. It is what allows me to see the connections between things that companies often buy separately.
The goal is capability, not dependency
The best version of this work does not leave a company permanently dependent on me for repetitive tasks. If something can become a system the team can operate, I want to build the system. If knowledge about the company can be captured once and reused across future AI work, I want the company to own that knowledge. If the first 90 days reveal that a permanent role is needed, I want the company to understand that role more clearly because we worked together.
That is what See Kirk Work is designed around.
The tools will keep changing. They should. What I expect to remain valuable is the ability to understand an unclear problem, make complexity usable, build the right system around it and stay close enough to the work to know whether it actually worked.
That is the job I have been doing for more than 20 years. AI simply gives me more leverage to do it now.