HarperFlow: Two Runtimes, One Content System
Explore HarperFlow’s content-system architecture: research, drafting and publishing, with an explicit n8n-to-Cloudflare execution boundary.
THE BRIEF
What the system needed to do.
HarperFlow connects the work around an article: the topic and source material, brand requirements, research, drafting, references, media preparation and the publishing target. The architecture makes the boundary between orchestration and execution explicit, with an n8n producer and a Cloudflare execution path documented separately.
The scope
- A shared description of the work passed between system layers.
- Research, drafting, references, formatting and media preparation.
- Publishing integration with Webflow and WordPress.
- A documented n8n-to-Cloudflare execution architecture.
DESIGN CHOICES
What makes the build interesting.
Content teams evaluating how research, editorial requirements and publishing integrations fit into one operating system.
Keep the business workflow explicit
Separate orchestration from execution
Design around the final destination
THE ARCHITECTURE
Follow the flow.
- Describe the job. Keep the topic, source requirements, brand context and publishing destination together.
- Pass the execution boundary. Use a defined handoff between the producer/orchestration layer and the execution layer.
- Prepare the content. Research, draft, structure and prepare references and media for the selected destination.
- Apply the workflow’s checks and deliver. Follow the review policy for that workflow, then hand the prepared content to Webflow or WordPress.
Tools and platforms
- n8n
- Cloudflare
- AI providers
- Webflow
- WordPress
What the design enables.
- Keep the business workflow explicit. Source material, brand requirements and publishing constraints travel with the job.
- Separate orchestration from execution. A defined handoff lets the workflow and execution layers be examined independently.
- Design around the final destination. The output must fit the target CMS and the publication's operating process, not just produce fluent text.
The difficult parts.
The useful unit of work is a publishing job with requirements. Its context is broader than a prompt: it includes the material to research, the publication’s voice and structure, and the constraints of the destination.
A defined execution boundary makes it possible to examine the orchestration and runtime layers independently. The producer describes the work; the execution path has responsibility for carrying out its stages and exposing the relevant state.
Build notes and context.
The useful unit of work is a publishing job with requirements. Its context is broader than a prompt: it includes the material to research, the publication’s voice and structure, and the constraints of the destination.
A defined execution boundary makes it possible to examine the orchestration and runtime layers independently. The producer describes the work; the execution path has responsibility for carrying out its stages and exposing the relevant state.
Publishing integration is part of the system design. Content must be structured for the selected CMS, references and assets must be handled, and the final handoff must fit the publication’s operating process. Fluent text alone is not a complete delivery.
This case study describes the owned product and the documented hybrid architecture. The native Cloudflare Workflows port has a separate implementation and test record. The existence of two execution paths should not be read as evidence that every provider path has verified live parity.
The broader lesson for a client engagement is to define the work and its operating contract before selecting the runtime. The systems, people and publishing requirements determine the implementation choices.
Explore the HarperFlow product, the Cloudflare port case study, or the related automation services.
Have a related process in mind?
Tell me what goes in, what should come out and where the current process gets stuck.