From Prompt-and-Response to Agentic Workflows: Engineering an AI Content Platform for Telehealth

A healthcare company came to us with an internal AI-powered SEO platform.

The prototype already worked.

It could research topics, generate content, perform SEO checks and publish to WordPress.

The problem was scalability.

As the system grew, it became increasingly difficult to maintain. The architecture relied too heavily on a single AI provider, browser-side state and workflows that were not designed for multiple brands.

We needed to turn the prototype into production software without losing the workflow that had already been validated.

1. The original architecture had reached its limits

The initial system was built around a relatively simple interaction:

User Input
    ↓
LLM
    ↓
Response

That works well for experimentation.

It becomes limiting when a workflow needs to remember previous decisions and pass structured context between multiple stages.

The new workflow looked more like:

Topic Discovery
      ↓
Research
      ↓
Content Planning
      ↓
Content Generation
      ↓
SEO Evaluation
      ↓
AEO/GEO Evaluation
      ↓
Human Review
      ↓
Publishing
      ↓
Feedback

Each stage had a specific responsibility.

The system was no longer treating the LLM as one general-purpose assistant.

It was becoming an orchestration layer around multiple specialized tasks.

2. Moving away from a single-model dependency

The original platform depended directly on one LLM provider.

That creates a practical engineering problem.

A model change, pricing change, availability issue or capability change can suddenly become an application-level problem.

We moved the AI layer to OpenRouter so the application could work with multiple models through a common integration.

An image-generation routing layer was also added.

The goal wasn't to use more models for the sake of using more models.

It was to make the application layer less dependent on one provider.

3. Persistent context became part of the workflow

A multi-step content system needs memory of what happened earlier in the workflow.

For example, when evaluating a new article, the system needs to know:

• What content already exists?
• Has this topic already been covered?
• What did the research stage find?
• What did previous evaluation stages identify?
• What feedback has the human reviewer provided?

Without that context, every stage becomes another isolated AI request.

The architecture therefore shifted toward persistent workflow context.

This allowed different agents to work on different stages while maintaining continuity.

4. AI-generated content still needed human evaluation

Healthcare is not a domain where increasing generation volume is enough.

The platform was designed to support high-volume content production while retaining a human review layer.

SEO specialists and writers could provide natural-language feedback.

That feedback could then become part of the system's context.

The objective was not:

AI → Publish

It was closer to:

AI
 ↓
Evaluation
 ↓
Human Review
 ↓
Feedback
 ↓
Improved Context
 ↓
Next Generation

5. Supporting multiple publishing environments

The platform eventually needed to support both WordPress and Astro-based websites.

WordPress provided an existing CMS workflow.

Astro introduced a different challenge because content specialists needed a CMS-style interface even though the underlying sites were using a more developer-oriented architecture.

The solution was to add CMS capabilities to the platform itself while maintaining compatibility with WordPress.

Custom WordPress components were also required for specific generated content such as HTML-based infographics.

6. The result

What started as an internal AI experiment became a multi-tenant platform supporting around 14 brands.

The platform could connect:

Discovery
   ↓
Research
   ↓
AI Agents
   ↓
SEO / AEO / GEO
   ↓
Human Feedback
   ↓
CMS
   ↓
Publishing

The important engineering lesson wasn't “use AI agents.”

It was understanding when a prototype has stopped being a prototype.

Once an AI workflow becomes part of a real healthcare business, reliability, context, model abstraction, human review and scalable architecture become product requirements.

That's where the engineering work really begins.