Content Engine

What it is

Content Engine is a multi-tenant platform I built for agentic content operations. Content flows through one pipeline: generate, multimodal assets (image, video, audio), AEO optimization, human approval, multi-platform publish, recycle. Around that core sit deep-research agents (competitive analysis, PESTLE, Porter's, sentiment, trends), email sequences, scraping with a review queue, a knowledge graph, and analytics feedback loops.

The API is FastAPI on Python 3.13. Agents run on Pydantic AI over AWS Bedrock, with Polly for audio and S3 for assets. State lives in PostgreSQL with row-level tenancy; Redis handles cache and rate limiting. The frontend is Next.js 15 with React 19, and a Helm chart deploys the API, frontend, gateway, and workers.

Orchestration is Temporal, one worker per service on its own task queue: content, orchestrator, approval, analytics, research, scraping, knowledge graph. You start only the workers for the pipelines you use.

Why it matters

Most AI content tools stop at the draft, which is where the actual work starts. This platform carries a draft to a published post: the pipeline generates text with a Bedrock agent, fans out parallel image, video, and audio generation, runs AEO optimization, then blocks on a human.

That approval is a first-class primitive, not a flag in a table. The Temporal workflow parks until an approval signal arrives from the queue UI; kicking off a pipeline returns 202 with a workflow_id, and the run survives restarts because Temporal holds the state. After approval, platform adapters publish to X, LinkedIn, Facebook, Instagram, Reddit, and WordPress, and analytics feeds performance back into A/B testing and the next generation cycle. OAuth tokens for connected platforms are stored Fernet-encrypted, and tenancy is enforced at the database row level, not in application code alone.

Architecture decisions

Temporal as the spine. A content pipeline is a long-running, failure-prone, human-interrupted process; durable workflows with signals model it directly. Per-service task queues keep the blast radius small: a wedged scraping worker cannot stall approvals.

Row-level tenancy in PostgreSQL. Multi-tenant isolation mistakes are the expensive kind; enforcing it in the database makes isolation the default rather than a code-review hope.

Human-in-the-loop by signal, not polling. Approval is a Temporal signal with its own worker and queue, so waiting on a human is a durable state, not a timeout risk.

Pipeline definitions are data. Thirteen core pipelines (data collection, deep research, competitive analysis, PESTLE, Porter's, demand signals, trend monitoring, sentiment, content, email sequence, feedback loop, landscape monitoring, A/B testing) are seeded into a registry table, so new pipelines ship without new deploy plumbing.

TigerGraph is optional and off by default; the knowledge graph earns its operational cost only for tenants using research features. Production boots reject default JWT secrets, and the dev seed script refuses to run when ENVIRONMENT is production.