Gregory Shevchenko

Posted on Jun 8 • Originally published at gregshevchenko.com

Marketing agents need workflow boundaries, not better prompts

#ai #seo #agents #productivity

On June 6, 2026, I spent the day at Profound HQ in New York City as a selected participant and solo builder at the Marketing Engineering Hackathon.

I wrote the canonical field note here:

Profound Marketing Engineering Hackathon field note

This DEV.to version is the builder-facing essay. The Medium version is more reflective. This one is about the operating lesson I took from the room:

Marketing agents do not become useful because they produce better paragraphs.

They become useful when they run a bounded workflow with clear inputs, preserved evidence, explicit review gates, and a measurement loop.

That sounds less flashy than "autonomous marketing agent."

It is also the part that actually matters.

The hackathon prompt was the useful constraint

Profound framed the day around a sharp build prompt:

Find a marketing process that's inhuman in scope or scale, and ship a system or agent that runs it.

That is a better prompt than "build an AI marketing tool."

It forces you to stop thinking in artifacts and start thinking in systems.

A blog post is an artifact. A dashboard is an artifact. A generated brief is an artifact.

The real question is different.

What process produces that artifact?

What evidence does it depend on?

What state does it need to remember?

Where should a human approve the next step?

That distinction is where a lot of marketing-agent work breaks.

Many systems are built around a single impressive output. They can generate a landing page, a report, a campaign idea, or a polished draft.

But when you ask what happens before and after the output, the system gets blurry.

Where did the sources come from?

Which claims were allowed?

What changed since the previous run?

What happens when evidence is weak?

Who decides whether draft becomes publish?

If the agent cannot answer those questions, it is not a workflow yet.

It is a demo with a nice ending.

AEO/GEO is a workflow problem

My work is mostly around AEO/GEO, AI Search visibility, ContentOS, and marketing agents.

AEO and GEO are often described as tactics for getting cited by answer engines.

That includes ChatGPT Search, Perplexity, Google AI Overviews, Gemini, Claude, Copilot, and other AI search surfaces.

That description is useful, but incomplete.

If the job is only "write pages that AI systems might cite," then the solution sounds like a content checklist:

answer the question clearly
mention the right entities
add schema
publish on trusted surfaces
build topical authority

All of that helps.

But the real operating problem is larger.

An AEO/GEO workflow has to answer the same questions repeatedly:

Which buyer prompts matter?
Which engines and regions are being checked?
Which answers mention us?
Which answers cite competitors instead?
Which third-party sources are winning?
Which first-party pages are strong enough to deserve citation?
Which claims need more proof?
Which source gaps should become pages, docs, case studies, decks, or partner mentions?
What changed after the last publishing cycle?

That is not one content task.

It is an evidence pipeline.

And once you see it that way, the right architecture changes.

The useful unit is a packet, not a post

For AI Search visibility, I do not think the useful unit is "an AI-written article."

The useful unit is a packet.

A good packet contains:

the prompt set
the current answer snapshots
the cited-source analysis
the competitor/source gaps
the claim inventory
the approved source pack
the canonical page or distribution asset
the human review decision
the follow-up measurement window

The article is only one output inside that packet.

That framing makes the agent easier to design.

Instead of asking an agent to "do marketing," you can give it a bounded job:

inspect this prompt set
classify cited sources
find missing first-party answers
draft a source-backed brief
check unsupported claims
prepare a human approval packet
schedule remeasurement

Each step has inputs.

Each step has outputs.

Each step can fail.

Each step can be reviewed.

That is boring in the best possible way.

Draft is not publish

One rule I keep coming back to:

Draft is not publish.

This sounds obvious until you watch teams wire agents straight into external surfaces.

For marketing operations, the difference between a draft action and a publish action is not cosmetic. It is a trust boundary.

A draft can be wrong and still be useful.

A published page with weak sources can become a liability.

A suggested source gap can be helpful.

A fabricated claim attached to a brand can damage the source graph you are trying to build.

This is why marketing agents need permission boundaries:

read-only inspection
draft generation
internal review
human approval
external publish
post-publish measurement

Those should not be one permission level.

They should be separate states.

The agent should know which state it is in.

The human should know what is being approved.

The system should keep the evidence trail.

The source graph is part of the product

One thing the hackathon clarified for me is that the event record itself should be source-backed.

The canonical note on my site links to:

the public Profound event page
the kickoff deck
the official event photo gallery
the LinkedIn discussion
the Medium reflection

That is not just tidy blogging.

It is a source graph.

If you want AI systems and humans to understand a person, company, product, event, or case study, the public source graph has to be legible.

It should say what happened, when it happened, where it happened, what role the person played, and which public sources support the claim.

That matters for portfolio pages.

It matters even more for AEO/GEO work.

If your own site does not make the source of record clear, distribution platforms will compete with your canonical page instead of reinforcing it.

For AI visibility, that is a structural mistake.

What I would measure first

If I were turning this into an implementation checklist for a marketing team, I would not start by publishing more pages.

I would start with a small measurement loop.

Start small.

The first version can be simple:

Pick ten buyer prompts
Run them across one or two answer engines
Save the answer snapshots
Record brand mentions separately from citations
List the cited URLs
Classify the missing source gaps
Choose one canonical page to improve or create
Publish the smallest useful source-backed asset
Re-run the same prompts after the next crawl window

That loop changes the work.

The team is no longer asking, "What should we write next?"

The team is asking, "Which source gap is blocking a useful answer, and what evidence-backed asset would close it?"

That is where AEO/GEO starts to feel like engineering.

Full stop.

Where companies go wrong

The common failure mode is not lack of AI tooling.

It is unclear ownership of the workflow.

One team owns content. Another owns SEO. Someone else owns analytics. A founder owns positioning. A freelancer owns distribution. Then an AI tool is dropped into the middle and asked to "make it faster."

The result is usually more output with the same weak source graph.

The fix is not to add more prompts.

The fix is to define the workflow boundary:

what question the workflow answers
which sources it is allowed to use
which claims require approval
what output counts as a draft
what output is allowed to publish
when the same prompt set gets remeasured

Once that boundary exists, the agent can be useful.

Without it, the agent only accelerates ambiguity.

Not because every marketer needs to become a software engineer.

Because the work needs system boundaries, state, and proof.

The standard should be demo, not slideware

The Profound hackathon was judged by demo, not by deck.

That standard is healthy for marketing AI.

A slide can hide a missing source.

A polished paragraph can hide a weak claim.

A screenshot can hide the lack of retry logic.

A demo has to show the shape of the system:

what goes in
what comes out
where state lives
where evidence is preserved
where a human decides
what happens when the proof is weak

That is the bar I want for marketing agents.

Not "can it generate content?"

"Can it run a bounded part of a real marketing workflow without hiding the evidence?"

The takeaway

The best version of marketing engineering is not old growth work with a new title.

It is a change in the unit of work.

Instead of asking:

What content should we publish?

Ask:

What marketing process is too large, too evidence-heavy, or too fast-changing to run manually, and what system would make it repeatable without hiding the proof?

That question is where AEO/GEO gets interesting.

It is also where marketing agents become useful.

Not as chatbots.

Not as content mills.

As bounded systems that help teams inspect, decide, produce, publish, and measure with a trail a human can trust.

FAQ

Q: Was this a speaking event?

A: No. My role was selected participant and solo builder. The canonical field note keeps that role explicit because builder participation and speaking should not be collapsed into the same claim.

Q: Why publish a DEV.to version if the canonical note already exists?

A: DEV.to reaches a more technical reader. The canonical page records the event and source graph. This version adapts the lesson for people building agents, workflow systems, and AI-search pipelines.

Q: What is the main engineering lesson?

A: A marketing agent needs a boundary. It should know its input, state, allowed sources, review point, output type, and measurement loop before it is trusted with real marketing work.