The Real Barrier to AI Marketing Agents: A Five-Layer Architecture Beyond the Model

When a team uses a chatbot internally, it's answering questions from its own people. But when an AI agent is embedded into a product serving many marketing clients, it's doing something far more dangerous: speaking publicly on the client's behalf—writing review replies, ad variants, and prospect messages. This completely changes the engineering requirements.

The InterCode team's production experience shows that the model itself is actually the easiest part. What truly determines a project's success is the "plumbing engineering" surrounding the model: integration, tenant isolation, human approval, and so on.

Why Public-Facing Scenarios Complicate Agent Engineering

There's a fundamental difference between internal knowledge base Q&A and marketing platform agents. In the former, a wrong answer is at worst an internal joke; in the latter, it might leave a bad reply on a client's Google Business page for all potential consumers to see.

Specifically, marketing platform agents face three layers of complexity:

• Multi-tenancy: Every client has its own brand voice, banned words, channel mix, and escalation rules. The agent can't rely on hardcoded defaults.
• Public output: Generated content appears directly on the client's public pages, so the cost of errors is extremely high.
• Mixed data sources: Review sites, ad platforms, CRMs, property management systems, inboxes—each system has different authentication, rate limits, and data structures.

This means the core challenge isn't getting the model to write good copy, but ensuring it says the right thing, in the right context, with the right constraints, to the right people.

Seven Agent Archetypes, One Common Pattern

Agents that repeatedly appear in marketing products can be grouped into seven categories:

Agent Type	Function
Reply Agent	Drafts replies matching brand voice, escalates sensitive content
Qualification Agent	Scores prospects, answers first-time inquiries
Research Agent	Gathers background on prospects for the sales team
Creative Adaptation Agent	Reshapes assets for the placement
Assembly Agent	Builds draft campaigns from a brief
Insights Agent	Answers performance data questions in natural language
Orchestrator Agent	Decides which agent runs and when human intervention is needed

The first six are highly similar at the code level: one goal, one set of tools, one "when to stop and ask a human" policy. The seventh is the coordination layer, and it's also where most AI agent orchestration work concentrates—routing, shared state, and handoff logic.

The Orchestrator Agent is the only one of the seven that doesn't directly produce client-facing content. Its job is to decide when other agents run, in what order, and when to hand control back to a human. In a typical implementation, the orchestration layer maintains a shared conversation or task state, receives events from the channel layer, and then decides—based on rules or a lightweight model—which downstream agent to invoke. The key difference from ordinary agents is that the orchestrator doesn't hold its own toolset, but rather a routing table to other agents. This also makes the orchestration layer the part that most needs observability—once routing logic goes wrong, problems surface simultaneously across multiple agents' outputs, making debugging far harder than a single agent's failure. In production practice, orchestration logic is usually merged with approval gating functions in one place, ensuring all handoffs and human interventions go through the same testable path.

Five-Layer Architecture: From Integration to Isolation

A real production system is organized into five layers:

1. Channel Integration Layer: Review platforms, ad networks, CRMs, PMS, email, SMS
2. Agent Layer with Guardrails: Generation plus tone checks, banned content filtering, and confidence assessment
3. Human Approval Queue: Drafts awaiting human review
4. Escalation Routing Layer: Sensitive cases quickly routed to the right human handler
5. Client Data Store: Context, examples, and history isolated per tenant

The Integration Layer Consumes the Most Work

The first layer is usually where the bulk of the work lies. Webhooks vs. polling, rate limits, token refresh, normalizing ten different "review" objects into a unified schema—these are what eat up weeks. If you're scoping a project, estimate API and integration work first.

Per-Tenant Policy Drives Every Decision

Every agent decision should read tenant policy rather than hardcoded defaults. In the TypeScript example, the TenantPolicy interface defines brandVoice (tone, banned phrases, approved historical reply examples), the channels list, autoPublish conditions (whether enabled, minimum confidence, minimum source rating), and escalateOn triggers (such as legal threats, safety issues, refund requests).

Key practice: Every tenant starts with autoPublish.enabled = false—wait until approval data shows humans rarely edit drafts, then gradually enable it per channel.

Multi-tenancy refers to a single software instance serving multiple clients simultaneously, where each client's data, configuration, and behavior must be isolated from the others. In the SaaS context, this typically comes in three forms: a shared database with a tenant ID column, a separate schema per tenant, or a separate deployment per tenant, with cost and isolation strength increasing in that order. For marketing agents, the additional constraint multi-tenancy brings is that isolation can't apply only to data—it must also apply to the behavior layer. The same model must read different brand voices, banned words, and auto-publish thresholds under different tenants. So TenantPolicy effectively serves as a "runtime configuration center," and every agent decision must look it up. If isolation is done only at the storage layer while ignoring the policy layer, the agent could still reply to Client B's review using Client A's tone—a failure mode more insidious and harder to audit than a data leak.

Approval Gating Is a Testable Routing Function

All drafts go through the same routing function, making "publish, approve, or escalate" a single, testable decision. The routeDraft function first checks whether escalation triggers apply, then whether auto-publish is enabled, whether confidence meets the threshold, and whether the source rating meets the minimum. The value of this design is that the decision logic lives in one place, making it easy to test and audit.

Tenant Isolation Must Be Enforced at the Data Layer

The fastest way to lose a client is to reference another client's data in a reply. The safest approach is to enforce tenant filtering at the data layer rather than leaving it to the model. In the retrieval function, isolation is achieved at the vector search stage via filter: { tenantId }, so the model never sees other tenants' data.

Tenant filtering in vector retrieval is the most easily overlooked security boundary in these systems. When an agent uses retrieval-augmented generation (RAG) to reference historical replies or brand examples, the vector database typically returns results by semantic similarity. Without filtering, it's easy to recall similar content from other tenants into the current agent's context. The correct approach is to pass tenantId as a metadata filter into the query before executing the similarity search, so the database only computes distances within the vector subset belonging to that tenant. This not only prevents data leaks but also improves retrieval quality—because different tenants' tone examples shouldn't interfere with each other anyway. The anti-pattern is "retrieve first, filter later"—that is, pulling results and then filtering out non-tenant entries in code. This approach is worse in both latency and security, and is prone to breaking during code changes.

Production Deliverables

Outcomes from a few real projects:

• Review management, 1,200 locations: Response time dropped from 18 hours to 4 minutes. Built in 6 weeks, team of about 2.5 people, paid back within 3 months.
• Apartment marketing leasing assistant: 62% of first-time renter inquiries handled without human intervention. Built in 14 weeks, 5-person team, multi-tenant, integrated with property management systems.
• Multifamily marketing agency lead generation engine: 73% reduction in manual prospect research, 3.2x outbound capacity, without adding sales headcount.

Trade-offs and Pitfalls

A few lessons from the field:

• Integration dominates estimates: Count channels first, then count agents.
• Brand voice fidelity has a cost: You need per-tenant examples and eval sets for each tone, not one global prompt.
• Volume determines payback period: The review project worked because it replaced about 1,100 hours of manual triage per month. Low-volume workflows may never cover the cost of custom development.
• Don't automate unstable processes: If the manual process changes every month, stabilize it first.
• Data and IP ownership must be settled upfront: Covers prompts, eval sets, logs, and any fine-tuning data.
• Pick metrics before picking a model: Response time, inquiries handled, research hours saved. Without metrics, you can't tell if it's working.

Delivery Cadence

These projects typically take 6 to 14 weeks, split into four phases: discovery and feasibility assessment, architecture and data access, build with guardrails, and validation and launch.

Key Takeaway

The model is the easy part. What makes these agents safe to ship is the plumbing around it: integration, per-tenant policy, approval gating, escalation routing, and strict data isolation. When a marketing platform considers adopting AI agents, it should focus its budget and schedule on this "beyond the model" work, rather than agonizing over which foundation model to choose.