Faster client work at a brand studio, with AI in the workflow

What it is

Feely is a brand and web design studio. Client projects run from a first inquiry through research, strategy, messaging, website copy, and a final case study. I worked with the studio to put AI inside that flow.

AI was already there when I started, just in the loose way most people first reach for it. The studio worked inside a ChatGPT project with its own custom instructions, so some context carried from chat to chat. But the real materials still lived elsewhere, and a lot of each task was pasting documents in, re-explaining the client, and reminding it where the project stood.

So the work was not about adding AI. It was about making it operational, so that context stayed in place, workflows could be reused, and each step of a client project produced something the next step could build on.

This was not a one-off automation project. The workflow came together through repeated work on real studio tasks, tool choices, context structure, templates, internal tools, and day-to-day AI use across client projects.

Why a browser chat was the bottleneck

The ChatGPT project helped, but only so far. Its memory was a set of custom instructions plus whatever you had pasted into the thread, not the studio's actual files. Each new chat still started mostly cold. You brought the documents again, described the client again, and reconstructed where the project stood.

The studio's own work, meanwhile, produces context at every step. An inquiry is context. A call transcript is a large piece of context. A proposal is context. A signed contract is context. In a chat workflow most of that lived in scattered files and people's heads, and it had to be fed back in by hand every time you wanted help.

The model was capable enough. The problem was that the context never gathered in one place, so most of it had to be rebuilt by hand while the work kept generating more of it.

The shift that mattered

We moved the studio to a file-based workflow in Codex, and the point was the structure, not the application. Context now lives in one place, organized by the studio's areas of work, clients, finance, marketing, SEO, the Feely site, and inside that, by client.

Each client has a folder that holds everything the project produces. Brief, meeting transcripts, proposal, contract, research, strategy, website copy, and the material that later becomes a case study.

Because each artifact lands and stays, context compounds instead of resetting. By the time the team writes the case study, the agent already holds the whole history of the project. Both the agent and the person directing it work against one growing context instead of rebuilding it from nothing each time.

The studio did not arrive at Codex by theory. It started on Claude in the CLI, which worked but was awkward day to day, then moved to the Codex app when it came out because it fit daily work better.

What it looks like across a project

A new client now moves through the same path. An inquiry comes in, and Codex pulls together first research on the company, its product, market, and competitors, then drafts the questions worth asking before the first call. After the call it works from the transcript and the studio's template to draft the proposal. That used to take about three hours and now takes twenty to thirty minutes. Once terms are agreed, it helps fill the contract from the scope, timeline, and price.

The project itself opens with a FigJam workshop. From there the agent has the workshop file, the recording, and the client's materials as context, and it helps assemble the competitive analysis, structure the market patterns, and draft the first positioning hypotheses. A brand strategist takes that and builds the real strategy. The agent does not replace that judgment, but preparing the research and the base for strategy dropped from about five days to one. The same context then carries into tone of voice, core messages, and website copy.

A separate SEO agent inside Codex prepares page metadata, the title, description, and basic fields, for both client sites and Feely's own. And when a project closes, the case study draft comes together from context the agent already holds plus examples of past cases, so the first draft takes about two hours instead of eight.

None of those numbers come from a faster model. They come from the context already being there.

The tools I built

Two parts of the work became internal products rather than workflows, because the studio needed software around a process, not just another prompt.

The first was an asset generator for a project that needed a large volume of photo and video assets. I built it from scratch, with a real interface for the designers, generation settings, per-designer budgets, and live cost tracking against each designer. It was a small production tool, built for that project and reusable if a similar one comes up.

The second was a LinkedIn workflow. The founder dictates the core thought of a post and Codex shapes it in her voice, working from examples of her past posts and a LinkedIn export.

What stuck and what didn't

Part of the work was deciding what not to keep.

We scoped a wider SEO program early on, with keyword gap analysis against a competitor, a technical SEO backlog, new service and sector pages, schema, and internal linking. It was useful as direction, but it never fit the studio's regular rhythm, so I did not force it. What earned its place is the narrow metadata agent, now used on every site launch.

The asset generator did its job and now sits idle, because there has not been another project at that volume. It was built for a specific need and stays reusable, rather than propped up to look active. The LinkedIn idea tool, which turned a YouTube video or article into post ideas, I let go for a better reason. The founder writes from her own projects now, so generating ideas from outside material stopped matching how she actually works.

The pattern is the useful part. The tools tied to a specific recurring step stuck. The ones tied to an occasional need, or to a habit that never formed, fell away, and I let them. Knowing which is which is most of what keeps a system like this from filling up with things nobody uses.

What I actually did

My role was to build the AI layer around the studio's creative work. I decided what was worth automating, designed the workflow and context structure, and built specific tools where a general agent was not enough.

The founder put it in her own words:

AI stopped being a separate chat and became part of Feely's operating system.

In practice that means less routine, faster turnaround on materials, and more of the team's time going to the work that needs a person.

Why this case is different from my other projects

Unlike my product experiments, this work lived inside an operating business and changed how client work gets done. It is embedded in how a working studio runs its projects, the founder wrote about the change publicly and credited the work, and the time it saves is hers to feel rather than mine to claim.

This case is also a starting point for something more deliberate, helping small studios turn scattered AI use into repeatable client workflows. Feely is the clearest version of that work so far, and the next step is turning it into a focused service for studios starting from their own messy, real workflows.