Inside eMarketing AI: a supervisor and a team of specialist AI agents

In our overview article we've already covered what eMarketing AI can do: it writes posts, articles, emails, and landing pages, runs campaigns, newsletters, and analytics — all in one place. That was the user's-eye view. Now let's come at it from the implementation side and see how the AI is put together here.

Marketing is a lot of dissimilar work: writing a social post, assembling a launch checklist, running an SEO audit, laying out a report on real numbers. One «smart» button for all of it tends to be mediocre at each. So inside eMarketing AI there isn't a single do-everything bot but a team of narrow specialists under a supervisor — and around them the same engineering discipline that made the whole thing worth building: the project's real data instead of invented figures, a cost counted for every run, and one engine tuned carefully per task.

One idea runs through the whole text: the value here isn't the size of the model but how the work around it is organised. Let's go in order — from the overall map of the system to which model handles which task.

How the whole system is built

Before diving into details, it helps to see the map. All the «smart» part is split off into a separate service: it lives next to the main application but runs independently. The marketer's dashboard doesn't call the model directly: it creates a run record (what needs doing, and for which project), drops the job into a queue, and frees the user. The AI service then picks the job up.

flowchart TB
  subgraph Client["How a task arrives"]
    UI["Marketer's web dashboard"]
    CRON["Schedule (cron)"]
  end
  subgraph App["Main application"]
    API["Server (API)<br/>creates a run record"]
    Q["Job queue<br/>(on Redis)"]
  end
  subgraph AI["AI service (separate)"]
    SUP["Supervisor<br/>(router)"]
    AG["Specialist agents"]
  end
  LLM["OpenAI GPT-4o"]
  DB[("Database<br/>content · campaigns · metrics")]
  UI --> API
  CRON --> API
  API --> Q
  Q --> SUP
  SUP --> AG
  AG --> LLM
  AG --> DB
  API --> DB

Why a queue rather than a direct call? Generating an article or a report takes tens of seconds — holding a connection open all that time is awkward and unreliable. A queue gives three things at once: the user doesn't wait on a spinner, every run is visible and its status can be tracked, and the jobs are easy to retry and to schedule. We'll come back to scheduling.

A supervisor and a team of specialists

Inside the AI service there isn't one jack-of-all-trades agent. A task is met by a supervisor: it looks at what kind of work has come in and hands it to the right specialist. Each agent is an expert at one job, with its own prompt, its own output format, and its own «temperature» (how much creative freedom the model is given).

flowchart TB
  SUP(["The supervisor picks the right specialist"])
  subgraph Team["The team of agents"]
    direction TB
    C["Content<br/>posts · articles · emails · landing pages"]
    CH["Checklists<br/>launch · campaign · SEO"]
    D["Documents<br/>plan · report · competitor analysis"]
    S["SEO<br/>page audit + SERP breakdown"]
    ST["Strategy<br/>go-to-market · positioning"]
    E["Email<br/>subject lines · emails · sequences"]
    A["Analytics<br/>insights over real metrics"]
  end
  CHAT["Chat assistant"]
  SUP --> Team
  CHAT -. "hands off a job" .-> SUP

The team goes like this: content writes posts, articles, emails, newsletters, ad copy, landing pages, and SEO articles; checklists assembles detailed task lists for a launch or a campaign; documents produces a marketing plan, a report, a competitor analysis, or brand guidelines; SEO audits a page and breaks down competitors in search; strategy owns go-to-market and positioning; email handles subject lines with A/B variants and drip sequences; analytics turns the project's real metrics into insights.

Why not one agent for everything? Because the tasks differ not in topic but in the shape of the result: a post is free text, a landing page is structured blocks, a report is Markdown over real data, an SEO audit is a prioritized list of fixes. A narrow specialist with a focused prompt does its job better than one prompt trying to please everyone at once. And a system like this is easier to debug: each agent owns a clear slice.

The life of a single run

Every task in the system is a run with a clear lifecycle. The record is first created as «pending», then goes into the queue, an agent picks it up from there, and in the end the result is saved and the run is marked «completed» (or «failed», if something went wrong).

stateDiagram-v2
  state "Pending" as P
  state "Queued" as Q
  state "Running" as R
  state "Completed" as D
  state "Failed" as F
  [*] --> P: task created
  P --> Q: put in the queue
  Q --> R: an agent picks it up
  R --> D: result saved
  R --> F: error
  D --> [*]
  F --> [*]
  note right of R
    Time, tokens spent
    and cost in dollars
    are measured;
    a debug trace is stored
  end note

While the agent works, the supervisor measures the time, counts the tokens spent, and converts them into a cost in dollars, and a debug trace can be attached to the run. It sounds mundane, but this is exactly what makes spending transparent: you always know what a particular piece of content or report cost, and you can keep the budget in check — especially when there are many generations.

The content engine: one request, three languages

The busiest specialist is the content agent. It handles nine formats (from a social post to a landing page and an SEO article), for the chosen platform, tone, and length. But it doesn't start with generation — it starts by loading the project context: brand voice, audience, industry. Without that the text would be smooth but faceless.

flowchart TB
  IN["Request: type · platform · topic ·<br/>tone · length · languages"] --> CTX["Load project context<br/>brand voice · audience · industry"]
  CTX --> GEN["Generate the text<br/>(GPT-4o, temperature 0.8)"]
  GEN --> REV["Quality review"]
  REV --> SAVE["Save as a separate record<br/>with a shared group ID"]
  SAVE --> MORE{"More languages?"}
  MORE -->|yes| NEXT["Next language"]
  NEXT --> GEN
  MORE -->|no| DONE["Done: one record per language,<br/>grouped together"]

Multilingual output deserves a separate word. Ask for text in several languages at once (say en, pl, ru) and the agent doesn't translate one version — it runs the loop for each language: generates, reviews quality, saves as a separate record — and all versions are tied by a shared group identifier so they sit together in the dashboard. The «temperature» here is high (0.8): content needs a measure of creativity. For an SEO article the agent additionally analyses the search results and outputs a meta title, description, and slug, while a landing page comes back already broken into sections.

Answers on real data, not on invented numbers

Here lies the key difference from a «smart but hallucinating» helper. When it comes to a report or analytics, the agent leans not on general reasoning but on your project's real data.

flowchart LR
  Q["Request: a report<br/>or an analytics question"] --> AGENT["Document / analytics agent"]
  AGENT --> DATA["Read-only, the project's real data<br/>content · campaigns · subscribers ·<br/>socials · metrics · checklists"]
  DATA --> CHECK{"Is there data?"}
  CHECK -->|yes| ANS["Report and insights<br/>on real figures"]
  CHECK -->|no| HONEST["«No data» +<br/>what to set up"]

For a report, the document agent loads the actual state of the project: how much content and in what statuses, which campaigns, how many subscribers, which social accounts are connected, how the checklists are progressing. And it is explicitly instructed to use only real data: if something is missing, it says so — «no data available» — and recommends what to set up, rather than painting in a plausible but invented metric. The analytics agent works the same way: it reads metrics and events (read-only) and answers a free-form question like «why did traffic drop last week» in plain language.

The chat assistant as a dispatcher

The chat in the dashboard isn't just «talking about marketing». Under the hood it's an agent that can call tools: it either answers with text or, if you ask it to do something, hands the job to the right specialist straight from the conversation.

stateDiagram-v2
  state "Chat" as C
  state Decide <<choice>>
  state "Tool" as T
  [*] --> C: user message
  C --> Decide: model response
  Decide --> [*]: text answer (no action)
  Decide --> T: an action is needed
  T --> C: specialist finished, a link is ready
  note right of T
    From the conversation you can
    hand a job to any specialist:
    checklist, content, report, SEO…
  end note

Say «put together a checklist for the product launch» and the chat will queue the task for the checklist agent itself, then send back a link to the finished result. That way a single window ties the whole team together: you don't have to remember which agent does what — you just explain what you need. The chat knows the project context, remembers the conversation history, and answers in three languages (English, Polish, Russian). Its «temperature» is moderate (0.7) — lively, but to the point.

SEO audits and work on a schedule

Another specialist is the SEO agent, and it's built as a small step-by-step machine: fetch the page, run an on-page audit, break down competitors in search, and produce prioritized recommendations.

stateDiagram-v2
  state "Fetch" as S1
  state "Audit" as S2
  state "SERP" as S3
  state "Recommendations" as S4
  [*] --> S1: fetch the page
  S1 --> S2: on-page audit
  S2 --> S3: competitor breakdown
  S3 --> S4: prioritized fixes
  S4 --> [*]
  note right of S2
    Headings, meta tags,
    keyword density
  end note
  note right of S4
    Plus meta title, description
    and slug for a new page
  end note

It isn't limited to «knowledge off the top of its head»: the agent actually fetches the page and reaches out to live web search, so the recommendations rest on the current results, not on the model's memory.

And since every task is a tracked run, it's easy to put one on a schedule. Via cron you can, for instance, assemble an analytics digest once a week or prepare a batch of content on a regular cadence — the system will run it by itself, with no button to press.

One model, many specialists

An important detail of the whole architecture: behind all of this stands a single model — GPT-4o. No «zoo» of models: one provider, one key, one engine for every task. What changes isn't the model but how it's tuned for a given job.

The main «lever» here is temperature, the model's measure of freedom. For checklists it's low (0.3): there you want discipline and predictability. For documents a touch higher (0.4). For chat, moderate (0.7). For content, high (0.8) — that's exactly where a bit of creativity is called for. On top of that, each agent has its own ceiling on answer length. One model, carefully tuned per task, is simpler to maintain and cheaper to debug than a set of different ones.

Conclusion

Put it all together and a familiar thought emerges: value comes not from «a bigger model» but from careful engineering around it. A team of narrow specialists instead of one generalist. The project's real data instead of invented metrics. A queue and a clear lifecycle instead of «press and wait». Every run counted in tokens and money. And one model, tuned separately for each task.

It's exactly this discipline that turns a talkative model into a working tool for marketing you can trust with the routine. You can try eMarketing AI at eMarketingAI.pl or build it yourself from the sources on GitHub. And if you need a similar set of agents embedded into your own product and data, write to us: [email protected].

Which model does what

Finally — a summary of which model handles which task. Here it's one model for everything, so the table really shows something else — what work it's tuned for and at what «temperature».