Architecting the Agentic Era: Shipping a Code-First CMS with AI

In my last post, Architecting the Agentic Era: The Content Operating System, I broke down the philosophy behind shifting from a traditional CMS to Agentic Content Operating Systems.

Theory is great, but modern architecture is proven in execution. To validate these concepts in a low-risk environment, our team is currently exploring a Proof of Concept (PoC) to evaluate migrating away from proprietary SaaS constraints—specifically Webflow and onto an in-development, decoupled code-first CMS stack (Payload CMS) targeted for enterprise AWS deployment using an end-to-end agentic pipeline.

Here is a look at the developer experience (DX), design-to-code pipeline, domain routing architecture, and governance controls we are using during this active PoC to take a sample schema from Webflow to cloud code while satisfying enterprise engineering security, accessibility, and infrastructure standards.

Why Test Beyond Webflow?

Visual SaaS builders like Webflow are fantastic for rapid prototyping, but as digital platforms and multi-site footprints scale, engineering teams often run PoCs to test for critical architectural boundaries:

• SaaS Sprawl & Vendor Lock-in: Evaluating how custom business logic, complex data relationships, and fine-grained RBAC perform outside proprietary hosted ecosystems.
• Accessibility & Design System Compliance: Working towards strict WCAG 2.2 AA accessibility compliance and institutional brand adherence through centralised, version-controlled React components rather than unvalidated visual styling in page builders.
• AWS Enterprise Integration & CDN Routing: Prototyping containerised deployments on AWS ECS Fargate, structured relational data in PostgreSQL, multi-environment edge asset distribution via AWS CloudFront, and custom vanity URL proxying using standardised Terraform IaC modules.

Through this active PoC, using a Payload CMS foundation is allowing us to test a code-first, TypeScript-native architecture where the entire CMS configuration, database schemas, and frontend design system live safely in Git alongside our Next.js frontend as a unified Single Source of Truth.

The Agentic Toolchain & Pipeline

To execute this experimental migration at speed without introducing technical debt, we have wired together an event-driven agentic stack connected directly to a multi-stage GitHub Actions CI/CD pipeline:

1. Architectural Discovery

We leverage Claude during the early discovery phase as an interactive thought partner to draft system specifications, analyse vendor trade-offs, and produce Architectural Decision Records (ADRs).

Crucially, before any sprint planning begins, these AI-assisted ADRs pass through a formal Technical Design Authority (TDA) Approval Gate. This gate applies a strict Buy Before Build (SaaS-First) lens, stress-testing whether turnkey commercial solutions meet long-term platform needs or introduce unacceptable markups and API ceilings.

Simultaneously, the gate evaluates internal resource allocation, verifies that the architecture maintains a strict Single Source of Truth in Git, and enforces Proactive Debt Elimination by auditing proposed code generation for future refactoring liabilities before a single line of code is committed.

2. Work Tracking & Triage

To streamline cross-functional alignment and planning, we coordinate our development tasks and communicate updates directly within Slack & Linear.

When feature requirements or architectural shifts arise, we leverage Cursor to directly create and assign Linear issues right from our editor environment without context-switching. When unplanned work, bugs, or urgent feature requirements emerge, our Slack-to-Linear integration automatically captures triage discussions and converts them into tracked issues

Once tasks are tracked, we accelerate development across all technical layers using Cursor integrated with GitHub. The AI agent processes architectural requirements in context across the entire stack, automating schema mapping, translating Webflow data structures into typed Next.js and TypeScript collection configurations, and scaffolding database hooks.

Finally, we use Cursor's Git workflow to commit code, link our Linear tracking IDs, and open pull requests on GitHub.

3. Code-First Engineering

We organise code generation and execution across three strict architectural layers, using Cursor for generation and GitHub as the universal entry point and Single Source of Truth before downstream deployments:

• Layer 1: Frontend (Next.js & Figma MCP): We bridge institutional design systems and engineering using Figma layouts integrated directly into Cursor via MCP (Model Context Protocol). Cursor agents parse design tokens directly from Figma, generating Next.js templates that enforce brand guidelines and help us systematically work towards WCAG 2.2 AA accessibility standards.
• Layer 2: Headless CMS (Payload CMS & PostgreSQL): Payload CMS collection configs and relational database schema hooks targeting PostgreSQL are generated from Webflow schemas in Cursor, then committed to GitHub alongside the frontend codebase to maintain strict version alignment.
• Layer 3: CI/CD & Infrastructure Automation (Terraform & AWS): Terraform declares Infrastructure as Code (IaC), PostgreSQL database schema migrations, and AWS CloudFront CDN distribution routing. Committing these definitions to GitHub triggers GitHub Actions pipelines to provision resources deterministically.

During code generation across all layers, we enforce Cursor's Plan Mode to review execution steps before touching files. Running in Auto-mode drastically optimises API token costs by routing repetitive boilerplate typing, component framing, and unit tests to lighter models—reserving flagship models strictly for complex layout logic, collection hooks, and RBAC rules.

4. Stakeholder Review Gate

To ensure AI-generated code and infrastructure changes never bypass testing environments we implement GitHub Actions workflows coupled with a mandatory review gate:

• Dev (Active) : Opening a Pull Request on GitHub automatically provisions an isolated dev environment via Terraform, routes traffic through dynamic CloudFront subdomains, runs PostgreSQL migrations, and deploys containers to AWS ECS Fargate.
• Staging (Review Gate): Merging a PR into main promotes the build to the staging environment. Here, non-technical stakeholders can test live features, content workflows, and layout fidelity against staging database instances, providing formal visual and functional sign-off before production release.
• Payload Prod (Gated Target): Production releases require a manual GitHub Actions dispatch gate with required reviewer approvals, ensuring human oversight before applying production releases.

Target Architecture: Code-First CMS on AWS

Domain Name, CDN & Proxy Routing Layer

Managing multi-environment isolation and custom vanity URLs cleanly across AWS requires a structured edge proxy and CDN routing model:

• Environment Domain Mapping via CloudFront:
  • Development: dev.domain.co.uk — Automatically provisioned per PR via Terraform, pointing directly to isolated Next.js/Payload ECS container slots for developer validation.
  • Staging: staging.domain.co.uk — Stable pre-production testing target mapped to the staging ECS cluster for non-technical stakeholder review gates and QA sign-off.
  • Production: www.domain.co.uk (plus vanity aliases) — Primary production domain fronted by global CloudFront distribution points with AWS ACM managed TLS certificates.
• Vanity URLs & Edge Proxying: Custom vanity aliases (e.g., campaigns.domain.co.uk or GTM/department shortlinks) terminate at CloudFront. Using CloudFront CloudFront Functions, incoming requests are seamlessly rewritten and reverse-proxied to specific Next.js page routes or payload API endpoints without exposing underlying infrastructure ports.
• Decoupled API Routing: The Next.js frontend acts as the primary public edge interface. Client-side requests or server-side rendering (SSR) fetches hit Next.js API routes, which internally proxy authenticated requests to the headless Payload CMS container running securely within private subnets on ECS Fargate.

Key Engineering Takeaways 💡

1. Governance & Architectural Discipline Before Code: Pairing Claude-generated ADRs with a Buy Before Build (SaaS-First) assessment, formal TDA review, and Proactive Debt Elimination guarantees that high AI velocity never compromises long-term platform maintainability.
   
2. Centralize Version Control as a Single Source of Truth: Keeping frontend components, Payload CMS configurations, database migrations, CDN routing rules, and Terraform IaC unified in Git prevents configuration drift across all environments.
   
3. Validate Early with Staging Review Gates: Promoting validated code to a stable Staging environment gives non-technical stakeholders a reliable surface to test functionality and provide final sign-off before production.

Wrap Up

Prototyping a decoupled CMS migration on an AWS containerised stack proves that high-velocity AI engineering doesn't require sacrificing enterprise architecture standards.

By grounding agentic workflows in strict governance, evaluating build-versus-buy decisions at the TDA gate, maintaining Git as the single source of truth, and systematically eliminating tech debt, this proof of concept establishes a sustainable blueprint for modern web infrastructure.

• Payload CMS Docs
• Model Context Protocol (MCP)
• Cursor AI Features

I will be sharing more deep dives on scaling agentic workflows and modernizing enterprise platforms in upcoming posts, so stay tuned!