Agentic Orchestration for Branding
Updated: Aug 10
Creating an agentic workflow with LangGraph
After creating a few AI agents, orchestration is the obvious next step; you get those agents talking with each other and working collaboratively, you go from having an assistant to having a team at your disposal.
This requires an orchestration framework to connect the agents - I opted for LangGraph for this project due to it working on a state-machine basis, allowing cycles and loops where the agents could get into critique and refine loops with each other.
Summary
Objective: Create a productive branding team via agentic orchestration
Stack: LangGraph, Gemini-1.5-flash, Python
Results: Success - agents conversing before agreeing and creating an output doc
Outcome: Gemini custom Gem not as effective as Claude for vibe-coding
GitHub: agentic-branding-orchestration
Set-up of the AI development and toolchain
Rather than use my usual Claude set-up for this one, I decided to try out Gemini and see how its latest LLM (3.1 Pro) compares. First step was to create a Gem with instructions and guardrails for coding ('don't expose keys, always create full new files to avoid merge issues, generate specs and Readme files along the way...' etc).
A brief point here on LLM choices. At project start, I usually ask whichever AI assistant I'm using (Claude, Gemini, ChatGPT, Le Chat etc) to list their current models and capabilities, and to recommend which LLM we should use.
This has several benefits:
AI moves fast: this is an effective way to systemically keep on top of releases and features
It allows me to pick the best tool for the job based on model capabilities
Adding sustainability instructions to your agent means they'll also point out the most eco-friendly LLM to use for a task. For lighter projects, you can often use a greener LLM rather than a Frontier model and prevent wasting energy and cooling water.
For this project Gemini 3.1 Pro was the best choice when balancing capability versus efficiency. No need to burn excess carbon using DeepThink for this type of vibe-coded experiment, however we could switch to the greener Gemini 3 Flash model for any follow-up documentation or test plan work if required later.
Subject matter for the agentic workflow orchestration
Set-up phase completed, we need a workflow for the agents to complete. Rather than work in the same few subject areas as usual, I asked Gemini to propose a few options instead. The most interesting looking was a branding workflow, where the agents would simulate a marketing team tasked with creating a brand identity. Given how subjective this type of work could be, it felt like a good one to throw at AI to see how it would handle things.
The workflow I settled on with Gemini was based on a team of 3 agents and a loop:
The Creative Lead Agent: Generates naming conventions, brand personas, and visual style guides (colour palettes, typography, and mood) based on user input.
The Prototyper: Interfaces with image generation models to create visual representations of the branding (logos, landing page hero sections, or business cards).
The "Design Critic" (The Orchestrator): The star of the show. This agent analyses the generated assets against attributes including:
UI/UX Heuristics: Accessibility and legibility.
Competitive Analysis: Ensures the brand stands out in its specific niche (e.g., Fintech vs. Horology).
Psychological Impact: Evaluates colour psychology and font weight based on the intended brand "vibe."
An Iterative Refinement Loop: A structured workflow where the Critic sends specific "Change Orders" back to the Creative Lead for a second pass.
Asset Export: Final generation of a "Brand Bible" and a suite of visual assets
The project goals of the workflow were:
Showcase Agentic Logic: Move beyond simple prompts into a state-managed workflow where agents work with each other autonomously.
Demonstrate Design Literacy: Prove that it's possible to encode subjective design principles (Psychology, UI/UX) into objective AI prompts and evaluation frameworks.
Full-Stack Integration: Build an interface where a user can watch the agents "think" and "critique" in real-time.
At this point I instruct my Gem to create a Readme.md for the project repo in GitHub, outlining all of the above.
Architecture and Design concept for the workflow
The project uses a "Supervisor-Worker" pattern within LangGraph - this utilises:
Supervisor: the agent which is aware of project context, user goals, and can assign tasks to other agents
Worker sub-agents: specialised agents tasked with performing specific objectives
State management: allows the Supervisor to keep track of the overall workflow progress
Edges (aka Hand-offs): mechanism where supervisor and sub-agents transfer control and information to each other
This manifests as our basic architectural concept:
Directed Acyclic Graph with Cyclic loops: to ensure no infinite loops
The State: A shared Python dictionary that stores the current brand name, the "mood board" description, the Critic's notes, and the version number.
The Nodes (The "Agents"):
research_node: Analyzes the industry (e.g., Finance or Automotive).
creative_node: Generates names and visual descriptions.
critic_node: The "Grumpy Senior Designer" who looks for flaws.
image_gen_node: Calls the image API.
The Edges (The "Rules"): Conditional logic that says: If the Critic gives a score < 8/10, go back to the creative_node. Else, proceed to final assets.
And our stack is as follows:
Orchestration: LangGraph
Reasoning Engine: Gemini 1.5 Flash (selected as it's free tier)
In terms of dependencies, this is Python-based project with the following libraries installed:
langgraph, google-generativeai, langchain-openai, python-dotenv, streamlitGood practice here is to instruct the agent(s) you're using to create an ADR to summarise the architecture, stack, logic flows etc. This allows you to keep an eye on what it's doing, monitor for hallucinations and catch issues early. If there's no mention of .env files, check those API keys.
Here's what a section of Gem-generated ADR looked like:
Key Design Decisions (ADR)
ADR 001: Use of Graph-Based Orchestration
Context: We need a way to handle multi-turn refinements.
Decision: Use LangGraph over a simple while loop.
Consequence: Better observability. Each "node" in the graph can be logged and debugged independently.
ADR 002: Separating Critique from Generation
Context: LLMs struggle to be self-critical in a single pass (Self-Bias).
Decision: We define a specific "Critic" persona with a separate system prompt focused strictly on "Negative Construction" and "Heuristics."
Consequence: Higher quality output and more realistic "Agentic" behavior.
ADR 003: Safety Guardrails (Iteration Cap)
Context: Agents could theoretically argue forever (Infinite Loop).
Decision: Implement a hard cap of 3 iterations in the Graph state.
Consequence: Ensures API cost control and predictable user experience.
Note that the stack, ADR and dependencies were updated throughout the project, mainly as a result of troubleshooting. For up to date complete versions, see the accompanying GitHub repo.
BrandTuna
Gemini had suggested the predictably bland 'Brand Bot' for the project name. Other than being dull as dishwater, it's also generic enough for anyone to pick up and use. And since I assume the random followers I get on my vibe-code Github account are lifting code and passing it off as their own (how lazy is that in the age of AI?) it's always worth throwing some nonsense into the repos in the hope they'll submit at as their university coursework and have to explain it to a professor. So I renamed the project BrandTuna at this point and inserted lots of references to Tuna fish throughout the repo.
The downside of this ruse was that Gemini started making lots of hackneyed fish jokes (referring to VS code as 'the canning factory' for example). Small price to pay though.
Let the vibe coding commence
Armed with an OpenAI API key, I tell Gemini to make a start on the code. Encouraging to see was the Gem following my instructions and telling me to create the requisite .env and gitignore files to keep the API key away from the public and any repo-scouring crawlers.
Gemini loses points to Claude during the build phase, as it has a tendency to jump ahead and assume the user is following. Several times I have to interject to bring it back up on oversights - telling me to copy code into a file we don't have in the project structure, not specifying which tool it's talking about during a task, jumping into .venv as if we'd already created it, generating code for terminal before we'd cd'd to the correct directory.
For engineers or tech-oriented Product people that's just annoying, but they'll figure it out or spot where something's been missed. For non-tech people though, it's a path to frustration and rage-quitting a project. The best mitigation here is to update the Gem instructions when you see it acting up, and to question everything along the way.
Troubleshooting the development issues
Another misconception of AI among many is that it creates great code straight off the bat. It doesn't. You have to be prepared to troubleshoot any number of bugs, ranging from spelling or format errors, through to environment set-up and on to more complex problems with the code itself. And the LLM will often panic and re-architect a section of a project rather than tenaciously work to diagnose an issue. This is where a battle-hardened human is necessary; you have to force the agent to diagnose and stick to a path until the issue is resolved.
What AI does really well of course is churn out generally good code very fast. It's been trained on public repos and developer documentation after all. This means it's great for prototyping, bringing junior developers nearer to the speed of their senior colleagues, and making the fast guys even faster. But you still need to know what you're doing and why.
Bug-fixing in vibe-coded projects can be incredibly frustrating, because often neither you nor the AI really know what's been generated and in what context. This has it must be said improved a lot in the last 6 months (I ran many vibe-code projects in 2023 and 2024 where the proverbial controller got launched at the screen due to how bad troubleshooting was back then). Claude is currently the best of the crop at this, and I expect it's high-up the roadmap priorities for AI Product teams.
Examples of issues faced during this project included:
Gemini not realising 3.14 was the latest installed Python version, meaning a load of libraries were throwing out warnings for the code it had created referencing older versions
The google-generativeai package Gemini wanted to use (referenced in the project set-up phase) had actually been deprecated. We needed to update to the newer google-genai library.
The LLM API my Gem had recommended and coded for was gemini-1-5-flash. However that had been superseded by Gemini 2 and 3 models, resulting in a load of 404s. Even more frustrating was that Gemini told me it hadn't realised that they'd been released. Self-product knowledge not a strong point.
Further frustration when it then realises that those newer models have a 24-hour hold window where no calls can be made (to avoid spam). So we revert back to Gemini 1.5 Flash, although this time using the correct model-ID 'gemini-flash-latest' which should have been used the first time. For a Google product to make this type of error when referencing models from it's own product family is disappointing.
Test run of the agentic workflow
Finally we get to a stage where the agents talk to each other - the output shows the 'Critic' agent rejecting the 'Strategist' agent twice before approving the proposal. This is the 'Agentic Loop' in action—it proves the system isn't just a chatbot; it's a reasoning engine that can self-correct.
One final error in this test run however. In iteration 3, the Critic actually said 'Approved' at the very top, but the code printed 'Rejected'. After another short round of troubleshooting, this turned out to be a logic bug in the way the word 'Approved' was being checked for.
At this point Gemini suggests we add a third agent - a copywriter to create a welcome mail for whichever fictional brand is the subject. I like to see AI showing some ambition, so why not, let's go for it.
Predictably that creates another load of errors, when it turns out that the Gemini Flash LLM can't handle this number of agent requests and times out. My Gem blames me as usual ('it was your code, definitely nothing to do with me') before adding some pauses and retry sections into the code.
Working code with three agents in the workflow
Finally we reach bug-zero with 3 agents. Full terminal output in swipe-gallery below:
Ignoring the branding element (which can be improved by use of libraries and more refined agent instructions) it's actually quite impressive to see the agents making proposals, critiquing them and producing an output as part of one workflow. This takes around a minute to run, and with some improvements such as reference libraries and closely-defined instructions, could viably become a prototyping tool for an agency or marketer.
The efficiency advantage of an AI agentic workflow
Seeing Gemini-powered agents argue in real-time in the terminal looks impressive. With the aforementioned instruction refinements and addition of a library of reference material, this type of workflow could be genuinely useful and productive, especially for smaller teams (and lower barrier-to-entry costs and profit margins in the process).
The marketing/branding content here isn't particularly good it has to be said - in fact I'd say it's quite derivative stuff - but that's not really the point.
Being able to orchestrate agents is a huge time save, and has clear use-cases where prototyping or ideation are concerned. Being able to do that via an hour session of vibe-coding is frankly pretty amazing. Armed with an internet connection and some tenacity, you can knock off a project like this pretty easily, even with fairly basic technical knowledge. Not so long ago that would have been unthinkable.
Admittedly this is a simple project and would benefit from a frontend UI, more advanced configuration options and some further exploration of LangGraph capability. A Gem with increased instruction and memory would solve that fairly easily though.
In AI terms, Gemini was ok, but frustrating. Even cleaning up the ADR doc at project end resulted in a round of hallucinations (updating the app.py file instead) and repeated answers (talking me through how to push this to GitHub at least 3 times).
The lack of knowledge Gemini has about Gemini products is very annoying. That alone has probably put me off returning to Gemini for the foreseeable future.
All in all: orchestration at a simple level is very cool to watch and much easier to build than you realise. And Gemini's not as good as Claude (which is where I'll be returning for future projects).
David Turner is the founder of Kói, an independent strategic consultancy advising senior leaders and investors on high-value decisions across technology and adjacent creative fields.
You can reach him at: enquiries@dkoi.design
© Kói Holdings Ltd 2026. All Rights Reserved.
