One agent, many channels: designing AI marketing you can still be accountable for

The demo version of an AI marketing tool is easy. It writes a post, you say yes, it publishes. The product version has to answer a harder question: when this thing is running every day across every channel your customers use, who is accountable for what it said?

Kaj is built so that the answer is always a person. That constraint shaped more of the system than any model choice did.

Approval has to be structural, not a checkbox

If approval is a setting, it will be switched off — by someone in a hurry, during a campaign, probably on a Thursday. We treat an approved item and a drafted item as genuinely different objects in the system. A draft has no path to a channel API. There is no flag that promotes it; something a person did has to produce the approved version.

This sounds pedantic until the first time an account would otherwise have published something wrong at 2am.

Every channel is its own product

"Post everywhere" reads like one feature and is really ten. Each channel has its own API, its own review process before you are allowed to use it, its own rate limits, its own idea of what a post is, and its own rules about what an automated system may do on a user's behalf. A messaging platform that permits a reply inside a 24-hour window and forbids it afterwards is not a detail you can abstract away — it changes what the product can promise.

What we learned to do early:

• Use each platform's official API, and go through its review. Anything else is a product that works until the day it is noticed.
• Model the channel's limits as first-class rules, not as error handling. The agent should know it cannot send, before it tries.
• Expect approval to take time, and build the product so a channel that is still in review is visibly "not connected yet" rather than quietly broken.

Two languages, one voice

Kaj works in Bangla and English, frequently in the same thread, because that is how customers write. The mistake to avoid is treating the second language as a translation of the first. A reply that is correct Bangla but reads like a translated English sentence lands worse than a plain English reply — it sounds like a machine wearing a costume.

The agent detects the language of the incoming message and answers in it, and the tone guidance is authored separately per language rather than translated.

Follow-up is where the value is, and where the risk is

Publishing is the visible part. The part that earns its keep is what happens after: a comment that is a question, a message that is a lead, a lead that needs a second contact three days later. Automating that sequence is genuinely useful and genuinely dangerous, because an automated follow-up to the wrong person at the wrong time is how a brand becomes a nuisance.

Our rule is that the agent may always draft and may always schedule, but anything that contacts a person a second time passes a person first — at least until the business has run it long enough to trust the pattern.

What we would tell someone building this

• Decide who is accountable for a published sentence before you write any code. Every other decision follows from it.
• Build for the channel review processes from day one; they are the long pole, not the model work.
• Keep an audit trail of what was drafted, what was approved, by whom, and what went out. The day you need it, you will need all of it.
• Let people turn it off per channel without turning off the product.