How a Marketing Agent Knows When to Act—and When to Ask

At 8:00 on a Monday morning, a merchant’s marketing agent wakes up.

Or, rather, something wakes it up. That distinction sounds fussy until the agent is asked to do real work. The task is familiar: look at the weekend’s sales and find products that are running low. Draft a promotion for items with healthy stock. Alert the merchant if a campaign would make a shortage worse.

“Run this every morning” seems like a complete instruction. It is not. It is only a time.

By 8:00, the questions that matter have only begun. What if the previous morning’s review is still running? What if the scheduler fires twice? What if the inventory system is temporarily unavailable? Who decides whether to inspect advertising performance or supplier lead times first? And if the agent decides a campaign should be paused, who is allowed to press the button?

The answer is not “use an agent.” It is a small cast of different systems, each with a particular job. A trigger says when work may begin. A workflow says how known work proceeds. An agent loop says who chooses the next move when the path is not known yet.

Most confusion in agent architecture comes from asking one of these things to play all three roles.

First, what actually happened at 8:00?

The clock did not perform a marketing review. It merely made an attempt to start one.

That is what cron is: a recurring time rule. At 8:00 every weekday, the rule matches, and a scheduler tries to create an invocation. The scheduler is a doorbell, not the person who answers the door. It does not know whether the merchant is on holiday or whether the inventory data is fresh. It cannot tell whether a budget increase would be wise.

This matters because clocks are imperfect in the ordinary, distributed-systems sense. A scheduler can be late. It can miss a run. It can create two. Kubernetes’ guidance for scheduled jobs makes the same point. Jobs should be idempotent: a duplicate attempt should not create a duplicate business outcome. A reliable daily review therefore needs an identity such as daily-inventory-review + 2026-09-15T08:00+08:00. That identity tells the rest of the system: this is one logical occurrence, even if it knocks more than once.

The clock answers one question: is this run eligible to begin now? Everything after that belongs elsewhere.

An event answers a different question. “Inventory changed” is a fact about the world. It may be carried from one system to another, but the fact is not the delivery method. A webhook is one such delivery method: a system sends an HTTP request to an endpoint and asks it to accept the news. A queue is another boundary: it holds durable work until a worker is ready.

These terms are often piled into one vague category called “triggers.” It is more useful to separate them. Cron is a clock. An event is meaning. A webhook is a push delivery. A queue is a waiting room.

In our merchant example, the inventory platform may emit inventory.changed after a large wholesale order. It might push that event through a webhook. The receiving service should verify the signature, save the delivery, assign it a deduplication key, and acknowledge receipt quickly. Only then should it place a normalized job on a queue.

Why such ceremony? Because “we received the request” and “we successfully changed the business” are different facts. A chat platform or commerce platform may time out while the underlying work is still happening. A queue gives the worker room to recover from that uncertainty. It also absorbs the rush of events after a flash sale. The marketing agent does not have to reason about fifty inventory changes at once.

So where does the workflow begin?

Picture the agent discovering that a popular rain jacket has only 14 units left. There is a predictable part of the response:

1. Check the current stock and open orders.
2. Check whether replenishment is already in transit.
3. Check whether active ads mention the jacket.
4. If stock is below the merchant’s threshold, draft a recommendation.
5. If a change is approved, make it once, record it, and verify the result.

That sequence is a workflow. It is a contract for the legal path through a piece of work. It defines what happens first, what may retry, when to wait, and what counts as complete. It holds its place when the inventory API returns a rate-limit error. It can pause for a merchant’s approval and resume tomorrow without pretending that a new run is the old one.

The word “workflow” sometimes sounds like an insult in conversations about AI, as though a fixed path were evidence of limited ambition. In a business system, it is often the opposite. The workflow is where the system makes promises it can keep.

Take a campaign pause. The request may fail because the advertising platform is busy. The worker may crash after the pause succeeds but before it records success. If it blindly tries again, the platform must be able to recognize the same idempotency key and return the original result rather than treating the retry as a second command. The workflow owns that discipline: retries, time limits, audit history, approval states, and the distinction between a proposed action and a committed one.

An LLM can sit inside this workflow without turning the whole affair into an agent. If the fixed sequence is extract data → validate fields → request approval → update campaign, it remains a workflow even when the extraction step uses a model. The ordering still belongs to code.

Then what, exactly, is the agent doing?

The agent enters where the answer is not a checklist.

The rain jacket problem may not be simple. Perhaps sales rose because a creator posted a video on Saturday. Perhaps stock is split across two warehouses. Perhaps a competitor is out of stock, making a modest discount unusually costly. Perhaps the merchant’s policy says to protect repeat buyers before chasing new customers.

No one can sensibly pre-draw every branch of that investigation. Here, the agent is useful because it can choose the next question in response to what it finds. It may first inspect sales velocity, then query the fulfillment system, then read the campaign brief, then ask for the supplier’s next available delivery date. Each tool result becomes an observation. The model reassesses, chooses another action, and stops when it has a recommendation, an escalation, or a reason to admit it is blocked.

That feedback cycle is an agent loop.

It is not a magical personality. It is a bounded form of control flow: model chooses an action; a tool returns evidence; model chooses again. The boundaries are crucial. The agent needs a maximum number of steps, a time budget, a limited set of tools, and clear stop conditions. It should be able to read sales data automatically; it should not be able to send a five-figure purchase order merely because the sentence it just generated sounds confident.

This is why the cleanest production design is neither a giant flowchart nor an unbounded autonomous loop. It is a deterministic spine with agentic edges.

The spine handles the things the business already understands: authenticate the request, remember the run, prevent duplicates, apply retries, wait for an approval, make idempotent writes, and log the outcome. The agent handles interpretation at the edges: investigate an anomaly, decide which evidence matters, explain trade-offs, and propose a next move when the environment refuses to be neat.

When should a clever agent become a boring workflow?

This is the most useful question for a team that has moved beyond demos.

Suppose the marketing agent has now handled two hundred low-stock cases. In 170 of them, it uses the same four tools in the same order, reaches the same threshold, and recommends the same action: reduce the campaign budget, notify the merchant, and reassess after replenishment. The original agent was doing valuable discovery. Repeating that discovery forever is expensive theater.

Freeze the common path into a workflow.

That does not mean firing the agent. It means moving it to the place where judgment still earns its keep. The workflow can handle the ordinary case cheaply and reliably. It can call the agent when the supplier data conflicts, when a promotion has unusual brand implications, or when the merchant asks a question that cannot be answered from a threshold.

A practical test is to ask seven questions of a stretch of agent behavior:

• Given the same inputs and observations, should the same steps happen?
• Can the allowed states and exits be named without creating a monstrous diagram?
• Is there a transition the model must never improvise?
• Does the work need to survive a crash, a deployment, or a two-day wait for approval?
• Does this path recur often enough to justify building it properly?
• Do evaluations show that the agent keeps choosing the same route?
• Can rare exceptions be sent back to an agent while the common path stays fixed?

When most answers are yes, the path wants to be a workflow. The mature system does not celebrate uncertainty where certainty is available.

Who is allowed to act?

There is another distinction that gets lost in the excitement around tools. A tool is not permission.

MCP and ordinary APIs make capabilities available: retrieve campaign performance, fetch a catalog, draft an email, update a bid. A skill provides procedural knowledge: how to investigate a stockout, how to write a campaign brief, how to compare audience segments. Neither one answers whether a particular action is allowed right now.

That is a policy question.

In the merchant system, the agent may have a skill called “inventory remediation.” It teaches a sensible method: establish the shortage, check replenishment, estimate the demand impact, and present options in plain language. It may have a tool that can pause a campaign. But the policy layer decides what happens next. Reading inventory may be automatic. Reducing a daily budget by 5 percent may be permitted within guardrails. Pausing a flagship campaign, changing a price, contacting a supplier, or spending money should usually create a saved approval request for the merchant.

The approval should occur before the effect, not after a cheerful notification that the effect has already happened. And it should survive the wait. If the merchant replies from Telegram three hours later, the workflow resumes the exact paused run with the exact proposal, not an improvised reconstruction of what someone probably meant.

Can the same agent behave the same way everywhere?

The reasoning core can be shared. The operating contract cannot.

On Telegram, a merchant expects a quick acknowledgement and a concise follow-up. On a command line, a developer expects detailed progress, local context, and the ability to interrupt. Through an API, another system expects a stable schema—perhaps an immediate operation ID while the work continues in the background. On cron, there is no present human to clarify an ambiguous instruction, so the safe default is to pause, report, or escalate.

The difference is not cosmetic. Each channel has its own identity, permissions, retry behavior, latency expectation, and reply route. A command-line process may inherit broad local access that a chat bot should never possess. A webhook may be delivered more than once. A scheduled run must carry both the time it was intended to run and the time it actually began, otherwise a late 8:00 review looks exactly like an ad hoc 10:00 one.

The architecture should normalize those entries into a single invocation envelope—who requested this, for which merchant, with which dedupe key, policy profile, and reply route—then let channel adapters handle the peculiarities at either end. The core agent should not have to care about message-length limits, HTTP status codes, or terminal progress bars. It should never lose the initiating identity while the payload is being normalized.

The point is not autonomy. It is accountability.

By lunchtime, our merchant receives a short message: the rain-jacket campaign has been capped rather than paused; replenishment is due Wednesday; projected stockout risk has fallen; a fuller report is available. Behind that calm message, the system may have handled a late schedule, a duplicate webhook, a queue retry, a rate-limited API, a model-led investigation, and a human approval.

None of those mechanisms is the “agent.” Together, they make an agent useful in a business where mistakes have names, customers, and invoices.

That is the durable way to think about the landscape. A trigger opens the door. Delivery gets the request safely inside. A workflow remembers the route. An agent chooses when the route becomes uncertain. Skills explain how to work. Tools make action possible. Policy and people decide which actions may become real.

Once those roles are clear, the design becomes less mystical and more powerful. You can point to every decision, every handoff, every retry, and every moment when the system chose restraint. That is what turns a scheduled prompt into an architecture—and an architecture into something a merchant can trust.

This is Week 4 of a 26-week series on agent systems from first principles: capability maps, skills vs. tools, memory and context, loops, harnesses, and the patterns that separate a demo from production.