The Hidden Complexity of AI Orchestration (And Why Everyone Gets It Wrong)

The Request That Sounds Simple

Not long ago, a client came to me with what they described as a straightforward ask:

“We want to set up an automated system that generates our email campaigns. It should write the copy, create the graphics, and have everything ready in draft for one person to review and schedule.”

My answer: yes, this is possible.

But before we wrote a single line of code, I asked one question: on what basis should it generate the content?

The answer? “Based on the customer type.”

Okay — have you defined your customer types? No.

And that was the beginning of a much longer conversation.

Key Takeaways

• In AI automation the model is often the easiest part. What decides whether the system works is the architecture around it: how input is structured, what rules govern output, how output is validated, and what happens when the model is wrong.
• “Just connect X to Y” requests assume the AI already has everything it needs. In most enterprise workflows, what it’s given is badly underspecified.
• Automating email campaigns needs five things in place: defined customer segments, accessible product context, content rules, a separate image-generation system, and an orchestrator that has to be designed and built. Remove any one and the system produces garbage or doesn’t run.
• Structured, JSON-first inputs make AI output predictable, auditable and reusable. A visual validation layer makes quality a system property instead of a manual review step.
• AI doesn’t replace thinking. It executes thinking. Define the logic before you automate, map the data before you integrate, and validate the output before you ship.

The “Just Connect X to Y” Illusion

There’s a pattern that shows up constantly in conversations about AI automation:

“Can’t you just connect Claude to our CRM and have it auto-generate campaigns?” “Can’t you just use GPT-4 to read the form responses and generate a design?” “Can’t you just wire the chatbot to our database and let it answer questions automatically?”

The word “just” is doing a lot of heavy lifting in all of these.

Each of these requests assumes that the AI already has — or can figure out — everything it needs to produce a useful output. In reality, AI models are extraordinarily capable pattern-matchers. But they can only work with what they’re given. And in most enterprise workflows, what they’re given is severely underspecified.

Breaking Down What “Automate Everything” Actually Requires

Let’s take the email generation example and pull it apart properly.

The ask: AI generates email content automatically for an e-commerce store using a marketing automation platform.

What needs to be true for this to work:

1. Customer segments must be defined — the AI needs to know who it’s writing for. Without defined customer types (new buyers, repeat customers, high-value churned, etc.), it has no basis for personalization. AI didn’t solve the personalization problem; it exposed it.
2. Product context must be accessible — the CRM needs to expose what products a customer has bought, when they bought them, and what they might need next. Most marketing automation platforms don’t surface this contextually, which is one of the most common reasons marketing automation stops working.
3. Content rules must exist — what tone, what length, what offers apply to which segments? If a human copywriter doesn’t know this, the AI certainly won’t invent it correctly.
4. Graphic generation needs its own system — LLMs generate text. Image generation requires a diffusion model or similar. These are separate tools that need to be coordinated.
5. An orchestrator is required — something has to coordinate the LLM, the image generator, the CRM data pull, the content rules, and the draft staging. That orchestrator is not free. It has to be designed and built. When it is, the payoff is real: here’s how one content team got 6x the output with the same headcount.

Remove any one of these and the “automated system” either produces garbage or doesn’t run at all.

At a Glance: What “Automate Our Email Campaigns” Actually Requires

The Orchestration Problem Nobody Talks About

This is the gap that consistently surprises people who are new to AI product development: the model is often the easiest part.

Choosing between GPT-4, Claude, or Gemini is a decision you can revisit. (Debating model versions is one of the four failure modes in my C.L.E.A.R. framework for pragmatic AI adoption.) What’s harder to change — and what determines whether the whole system works — is the architecture around the model:

• How is input structured before it reaches the model?
• What rules govern what the model can and can’t produce?
• How is output validated before it reaches the user?
• What happens when the model is wrong — and it will be, sometimes?

A JSON-first approach addresses many of these. Rather than sending freeform prompts and hoping for consistent outputs, you build structured JSON that captures exactly what the model needs to know. For an interior-design image generator, that might be room type, user preferences, constraints, inclusions and exclusions. The model works within that structure. The output is predictable, auditable, and reusable.

This is the difference between AI as a feature and AI as a reliable system.

Visual Validation: The Step Most Teams Skip

Let’s say you’ve built an AI image generator for interior design. User fills a form. System generates a prompt. Image comes back. Done?

Not quite.

How do you know the image doesn’t violate design rules — a mirror facing a bed, poor lighting placement, a color scheme that contradicts the brief?

This is where a visual validation layer comes in. A separate vision model reviews the generated image against a defined rule set. If the confidence score is below a threshold — say, 0.75 — the system regenerates rather than showing the user a flawed output.

Most teams skip this step. They trust the model. They show whatever comes back. It’s the same trap as vibe coding: treating AI output as finished work instead of a draft that still needs engineering discipline.

The result is inconsistent quality that erodes user trust gradually, until someone complains loudly enough to get it fixed.

Build the validation layer. Store your rules centrally. Make quality a system property, not a manual review step.

What This Means for Anyone Building with AI

If you’re leading an AI product — whether you’re technical or not — here’s the mindset shift that matters:

AI doesn’t replace thinking. It executes thinking.

The quality of your AI system is a direct reflection of the quality of the rules, structure, and architecture you’ve built around it. A powerful model in a poorly designed system produces poor results. A modest model in a well-designed system can be remarkably effective.

Before you automate, define the logic. Before you integrate, map the data. Before you ship, validate the output.

The machine can only follow what you’ve already figured out.

The Bottom Line

AI orchestration is a discipline. It requires product thinking, systems design, and engineering rigour — not just a good prompt and an API key.

The teams that get this right don’t just pick the best model. They design the system that makes the model trustworthy.

That’s where the real work is. And it’s worth doing properly.

I’m currently open to AI product and architecture roles where this kind of systems thinking is valued. If you’re building something serious with AI, let’s talk.