The Hard Part of AI Agents for Marketing Platforms Isn’t the Model. It’s Everything Around It
When you put AI agents inside a product that serves many marketing clients, most of the work goes into integrations, tenant isolation, and human approval, not prompts. We structure these systems in five layers: channels
- When you put AI agents inside a product that serves many marketing clients, most of the work goes into integrations, tenant isolation, and human approval, not prompts.
- We structure these systems in five layers: channels → agents with guardrails → approval queue → escalation routing → per-client data store.
- Results from production builds: review response time cut from 18 hours to 4 minutes across 1,200 locations (6-week build), and 62% of first-touch tenant enquiries handled without a human (14-week build).
The problem: agents that speak for someone else
An internal chatbot answers your own team's questions. An agent inside an agency or marketing platform does something riskier: it writes review replies, ad variations, and lead messages on behalf of your clients, in public.
That changes the engineering requirements:
- Many tenants. Every client has its own brand voice, banned phrases, channels, and escalation rules.
- Public output. A bad reply sits under a client's Google listing, not in a Slack thread.
- Mixed data sources. Review sites, ad platforms, CRMs, property management systems, and inboxes, each with its own auth, limits, and quirks.
Seven agent shapes, one pattern
Across marketing products, we keep building the same seven shapes:
| Agent | What it does |
|---|---|
| Response | Drafts on-brand replies, escalates sensitive ones |
| Qualification | Scores leads, answers first-touch questions |
| Research | Gathers prospect context for sales |
| Creative adaptation | Reshapes assets per placement |
| Assembly | Builds a draft campaign from a brief |
| Insight | Answers performance questions in plain language |
| Orchestration | Decides which agent runs and when a human steps in |
In code, the first six are mostly the same thing: a goal, a set of tools, and a policy for when to stop and ask a person. The seventh is the coordination layer. That's where AI agent orchestration does most of its work: routing, shared state, and handoffs.
The 5 layers
- Channel integrations. Review platforms, ad networks, CRMs, PMS, email, SMS.
- Agent layer with guardrails. Generation plus checks for tone, banned content, and confidence.
- Human approval queue. Drafts waiting for a person.
- Escalation routing. Sensitive cases go to the right human, fast.
- Client data store. Per-tenant context, examples, and history.
Layer 1 is usually the biggest share of the effort. Webhooks versus polling, rate limits, token refresh, and normalizing ten different "review" objects into one schema is where weeks go. If you're scoping a project, scope the API and integration work first.
Per-tenant policy
Every decision the agent makes should read from a tenant policy, never from hardcoded defaults.
// Simplified illustration of the pattern, not production code
interface TenantPolicy {
tenantId: string;
brandVoice: {
tone: string; // e.g. "warm, concise, no exclamation marks"
bannedPhrases: string[];
examples: string[]; // approved past replies used as few-shot context
};
channels: Array<"google_reviews" | "facebook" | "email" | "sms">;
autoPublish: {
enabled: boolean;
minConfidence: number; // below this, a human approves
minSourceRating?: number; // e.g. only auto-reply to 4–5 star reviews
};
escalateOn: string[]; // e.g. ["legal_threat", "safety", "refund_request"]
}
The approval gate
Every draft goes through one routing function, so "publish, approve, or escalate" is a single, testable decision:
type Draft = {
tenantId: string;
channel: string;
text: string;
confidence: number;
flags: string[]; // produced by classifiers/guardrails
sourceRating?: number;
};
type Route = "publish" | "approve" | "escalate";
function routeDraft(draft: Draft, policy: TenantPolicy): Route {
if (draft.flags.some((f) => policy.escalateOn.includes(f))) return "escalate";
const { enabled, minConfidence, minSourceRating } = policy.autoPublish;
if (!enabled) return "approve";
if (draft.confidence < minConfidence) return "approve";
if (minSourceRating !== undefined && (draft.sourceRating ?? 0) < minSourceRating) {
return "approve";
}
return "publish";
}
Start every tenant with autoPublish.enabled = false. Turn it on per channel once the approval data shows humans rarely edit the drafts.
Tenant isolation in retrieval
The quickest way to lose a client is to quote another client's data in their reply. Scope every read by tenant at the data layer, not in the prompt:
async function getContext(tenantId: string, query: string) {
// The tenant filter is enforced here, never left to the model
return vectorStore.search(query, { filter: { tenantId }, topK: 5 });
}
What this delivered
- Review management, 1,200 locations. Response time went from 18 hours to 4 minutes. It was a 6-week build with a team of about two and a half people, and it paid for itself within 3 months. This ran on top of the reputation management platform we had modernized.
- Leasing assistant for apartment marketing. It handles 62% of first-touch tenant enquiries without a human. It was a 14-week build with a team of five, multi-tenant, and integrated with property management systems.
- Acquisition engine for a multifamily marketing agency. It cut manual prospect research by 73% and raised outbound capacity 3.2x without new sales hires.
Trade-offs and gotchas
- Integrations dominate the estimate. Count channels before you count agents.
- Brand voice fidelity has a cost. You need per-tenant examples and an evaluation set for each voice, not one global prompt.
- Volume decides payback. The review project worked because it replaced about 1,100 hours of monthly admin triage. Low-volume workflows may never pay back a custom build.
- Don't automate an unstable workflow. If the manual process changes every month, fix it first.
- Decide on data and IP ownership up front. That covers prompts, evaluation sets, logs, and any fine-tuning data.
- Pick the metric before the model. Response time, enquiries handled, research hours saved. Without one, you can't tell if it works.
How the delivery usually runs
These projects take 6–14 weeks:
- Discovery and feasibility
- Architecture and data access
- Build with guardrails
- Validation and production
Wrapping up
The model is the easy part. What makes these agents safe to ship is the plumbing around them: integrations, per-tenant policy, an approval gate, escalation, and strict data isolation.
This article was drafted with AI assistance and reviewed by the InterCode team.
Originally published by Dev.to AI. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.