Home / Work / Agentic content engine

EMB Global · Rayo AI platform · 2025

Compliance
built into
generation

An AI SEO platform can produce a thousand drafts an hour. That is only useful if a human does not have to read all thousand to find the two that put the brand at risk.

Role
SDE II, Backend & Generative AI
Domain
Content operations at scale
Outcome
≈60% fewer manual steps
Stack
FastAPI · LangChain · n8n · GPT-4 / Claude · Azure · PostgreSQL

The constraint

The platform's promise was volume: research a topic, draft against it, optimise for search, publish. The bottleneck was never generation. It was the review queue behind it — a person checking every draft for brand voice, for claims the client could not legally make, for the tone that works in one market and lands badly in another.

Scaling generation without scaling review just moves the bottleneck. So the design question was not "how do we generate more" but "what has to be true at generation time so that review becomes an exception rather than a stage".

Anything you check after generation, you will check forever. Anything you constrain during generation, you check once.

How it was built

Agents split by responsibility, not by prompt length

Three agent roles rather than one long prompt: a research agent that gathered and cited source material, a drafting agent that worked only from what research had returned, and an optimisation agent that shaped the result for search intent without being allowed to introduce new claims. Splitting them meant each could be evaluated — and fixed — on its own terms.

Brand voice and compliance as generation-time constraints

Voice and compliance rules were injected into the generating context and enforced by a checking pass inside the pipeline, before a draft ever surfaced to a human. A violation sent the job back around the loop with the specific rule it had broken, rather than into a queue. Reviewers went from reading everything to arbitrating edge cases.

Orchestration through n8n

Content jobs, webhook triggers and third-party integrations ran through n8n. That choice was partly technical and partly organisational: the operations team could see and adjust the flow without waiting on an engineer, which is where a good deal of the manual-step reduction actually came from.

Owning the serving path

Under high content throughput, latency and cost live in the LLM serving path. I owned that path on FastAPI and Azure — request batching, concurrency limits, retries with sane backoff, and caching the retrieval work that jobs kept repeating.

n8n triggerWEBHOOK / CRON ResearchCITED SOURCES DraftSOURCES ONLY OptimiseNO NEW CLAIMS Voice &compliance gatePASS / RETURN Publish FAILS → BACK WITH THE RULE IT BROKE FastAPI serving path BATCHING · CONCURRENCY LIMITS · RETRIES · RETRIEVAL CACHE PostgreSQLJOB STATE · AUDIT TRAIL

Simplified flow. The gate is inside the pipeline, not after it — a failing draft loops back with its violated rule instead of entering a human queue.

What changed

Manual intervention fell by roughly 60%. More usefully, the shape of the remaining work changed: reviewers stopped being a throughput ceiling and became the people who resolved genuinely ambiguous cases and tuned the rules that caught the rest.

The transferable lesson is unglamorous. In content systems, the leverage is almost never a better generation prompt — it is moving a check from after generation to during it, and giving the failure a machine-readable reason so the pipeline can act on it.

My role

  • Built the multi-step agentic content pipeline for research, drafting and optimisation.
  • Enforced brand-voice and compliance checks at generation time rather than in review.
  • Orchestrated content jobs, webhook triggers and third-party integrations through n8n.
  • Owned latency and scalability of the LLM serving path on FastAPI and Azure under high throughput.

Client-confidential implementation detail is deliberately omitted. Figures are approximate and reflect internal measurement at the time.