RUStart a project
Case study 072026

Content Control Room

2 intake paths, 4 lifecycle states, 7 controlled handoffs and 3 orchestration workflows connect onboarding, approval, activity and recovery to one agent core.

Modern House
Content operations product control room for intake, approval, publishing, QA and recovery
Content operations productExecutable agent core, Docker, API and n8n workflow
Case type
Content operations product
Role
Product + System Designer / Developer
Period
2026
Status
Product design · executable agent core
Focus

Content operations productProduct DesignGovernanceAgent Systems

01

Problem and solution

Problem

Portfolio updates were fragmented across messages, files and manual WordPress work. The design task was to give the team one controlled path for project data, images, approval, publishing, updates, archiving and visible failures.

Solution

A product interface and bounded-agent system that move a project from team intake through validation, approval, WordPress tools, browser QA, recovery and an auditable trace.

My role

Product + System Designer / Developer

Designed product surfaces for intake, validation status, approval queues, run health, audit activity and reversible failure states.

02

Process audit

Content lifecycle audit

I decomposed the manual process into states, roles and handoffs: intake, validation, approval, publishing, update, archive and error handling.

Automation starts with a clear model of states and ownership, not with connecting tools.
01

The core Compose stack defines PostgreSQL, NocoDB, n8n, Publishing Orchestrator, Data, Publishing, QA and Site Manager agents; MinIO lives in the Telegram-bot stack.

02

Telegram passes project data to Data Agent, while NocoDB gives the team direct table control over the same PostgreSQL source of truth.

03

Publishing Orchestrator reloads fresh database state, selects an allowlisted route and stores each agent objective, tool, decision, input and output in agent_runs.

04

A failed QA check triggers a compensating WordPress rollback to draft; the offline demo proves both completed and blocked paths without claiming live external calls.

03

Architecture

Publishing lifecycle

Two intake channels converge into a shared data model and pass the same controls before WordPress.

  1. 01Intake
  2. 02Validation
  3. 03Approval
  4. 04Publishing
  5. 05Monitoring and archive
Modern House
Content operations control room with project states, approval queue, run health and auditability
  1. 01

    Designed product surfaces for intake, validation status, approval queues, run health, audit activity and reversible failure states.

  2. 02

    Mapped the manual process into an end-to-end lifecycle with explicit agent objectives, handoffs and four project states.

  3. 03

    Implemented a bounded orchestrator with an allowlisted planner, hard data gate, optional Claude review, specialist tools and complete JSON trace.

  4. 04

    Added browser QA as a blocking step and a compensating action that returns a rejected WordPress page to draft.

04

Agent run

One project, seven controlled handoffs

Each agent receives one objective, a restricted tool and the previous step's context. A successful WordPress response is not a successful run until QA passes.

  1. 01Team

    Submit the project

    Telegram or NocoDB stores the record in PostgreSQL before emitting project.ready.

  2. 02Data Agent

    Reload the source of truth

    A fresh snapshot blocks the run when description, category, image or state requirements fail.

  3. 03Planner Agent

    Build an allowed plan

    Current wp_post_id selects create, update or archive; an allowlist prevents arbitrary tools.

  4. 04Content Review Agent

    Assess semantic readiness

    Claude can recommend pass or block, but cannot control WordPress or bypass hard rules.

  5. 05Publishing Agent

    Execute the WordPress action

    The agent creates, updates or recovers the page and returns its ID and URL.

  6. 06QA Agent

    Verify the public result

    Playwright checks the page; failure triggers a compensating rollback to draft.

  7. 07Site Manager + n8n

    Sync and report

    Site-wide state is refreshed, the trace is stored and Telegram receives the structured result.

State model
  1. draft

    stored without starting publication

  2. ready

    approved; n8n delegates to the publishing orchestrator

  3. published

    WordPress ID and URL are stored

  4. archived

    the post moves to recoverable trash

05

Orchestration

Three n8n workflows surround one auditable agent run

n8n owns transport, schedules and notifications. Planning, tools, QA and compensation stay inside the agent run and are stored in PostgreSQL.

WorkflowTriggerRuleActionResult
01Project eventready / archivedstable event_idPublishing Orchestrator /runsrun_id + route + status
02Daily healthCron 00:00once per daySite Manager + QA Agentsync + browser report
03Blocked / errorHTTP 409 / 5xxgate or tool failureextract failed stepTelegram + retry from DB

Failure behaviour

  1. 01

    The model never selects API tools: create, update and archive are controlled by deterministic policy.

  2. 02

    An AI failure switches review to policy fallback while the source record and local slug remain available.

  3. 03

    Failed browser QA returns the WordPress post to draft and marks the run as blocked.

  4. 04

    A repeated event_id returns the stored trace instead of starting another sequential run.

Product states, architecture and trace

Onboarding, approval and recovery screens connect directly to the architecture, data model and auditable agent run.

Content operations product control room for intake, approval, publishing, QA and recovery
01Executable agent core, Docker, API and n8n workflow
Four-step content intake and onboarding flow with a live validation preview
02Intake onboarding / source, project, assets and review
Approval queue and audit trace showing a failed browser QA check and rollback to draft
03Governance and recovery / approval, audit and rollback
Bounded agent architecture from Telegram and PostgreSQL through n8n, specialist agents, QA and WordPress
04Bounded agent architecture / policy, tools and trace
Seven controlled agent handoffs from team intake to QA, rollback and Telegram feedback
05Agent run / seven controlled handoffs
Three n8n transport workflows around one auditable bounded agent run
06n8n boundary / transport outside, decisions inside
PostgreSQL project state, image records, audit events and complete agent run traces
07Data model / project state and agent evidence
06

Validation and outcome

Result and system scope

2 intake paths, 4 lifecycle states, 7 controlled handoffs and 3 orchestration workflows connect onboarding, approval, activity and recovery to one agent core.

What can be verified

  1. 01

    The product screens translate the existing lifecycle, policy and trace contracts into interface states.

  2. 02

    Local source: modern-house/agents/docker-compose.yml defines the service topology.

  3. 03

    Local source: modern-house/agents/agents/publishing_orchestrator contains the executable pipeline, tests and offline demo.

  4. 04

    Local source: modern-house/agents/db/schema.sql defines projects, images, action logs and complete agent_runs traces.

  5. 05

    Local source: modern-house/agents/n8n/workflows/agent-publishing-workflow.json is an importable event-to-agent workflow.

  6. 06

    Local source: modern-house/telegram-bot contains the guided intake and Data Agent client.

  7. 07

    Generated success and QA-blocked runs demonstrate the orchestration logic and recovery path.

Role boundaries

Agency work at Lex Wizhevsky Architects · Role: Product + System Designer / Developer

Agency work is credited to Lex Wizhevsky Architects.

The control-room screens are based on the lifecycle, policy and trace contracts implemented in the agent core.

The case scope covers product design, orchestration logic and QA behaviour.

Measured system scope: 2 input channels, 4 states, 7 handoffs, 3 workflows and 1 reversible failure path.

Outcome

A product interface and bounded-agent system that move a project from team intake through validation, approval, WordPress tools, browser QA, recovery and an auditable trace.

Discuss a related project

Need a website, product interface or automation system?

Send the current surface, goal and constraints. I will propose a route from diagnosis to a verifiable release.

Discuss a related project↗
Next case / 08Evidence Governance↗