Oded Tal Soffrin, Project Lead
TL;DR
We built Base44’s marketing website and custom blog CMS through agentic workflows across engineering, design, SEO, marketing and legal. Shared component contracts connect authoring to rendering, while Cloudflare separates visitor decisions from cached pages. Developer review supports contributions across the team.
This article started with an agent interviewing me about how we built Base44’s marketing website. I answered questions, pointed it toward the code and asked it to check the pull requests when I couldn’t remember the timeline. The intended destination is our custom blog CMS, rendered inside the custom marketing website we built through agentic workflows.
That’s the outcome we were working toward: a team member can bring an idea to an agent and carry it through an established path to production. Building that path meant working on the website’s architecture, the publishing system and the way people contribute to both.
Building a contribution path
Our previous marketing infrastructure revolved around a visual editor, with different websites making up different sections and languages. It was difficult to maintain through agents. We wanted agents to build landing pages, write posts and help conduct experiments, with SEO, accessibility and performance built into the process.
As Project Lead, I brought my experience building web systems to the architecture. Agents helped us turn those decisions into working code. Every PR in this effort was built agentically and the people contributing extended well beyond engineering: designers, technical designers, SEO, product marketing and legal all participated.
They connected Claude or Codex to the codebase and described the changes they wanted. The agent produced a PR. A developer reviewed it and the discussion continued until the change was ready to merge and go live. Someone with expertise in a particular discipline could take a request directly into the system that implements it.
That breadth of participation made the shared foundations important. A new page needed to fit the website’s design and publishing conventions. An experiment needed to preserve attribution. The system had to give people a repeatable way to make changes while keeping those requirements intact.
Caching experiments without losing attribution
The architectural requirement
One of my architectural requirements was to support traffic at the scale of millions of views while running personalized experiments and preserving marketing attribution. That presents a practical caching problem: visitors may need different versions of a page, but rendering every visit independently gives up much of the benefit of caching.
We separated the work across a Cloudflare edge worker and a server-rendered React application. The edge resolves the experiments relevant to the requested page and passes the chosen variants to the renderer. The HTML cache distinguishes between those variant combinations, so visitors receiving the same version can reuse the same rendered page.
Visitor cookies remain separate from the stored response. The worker attaches them after the cache lookup. Known campaign parameters, such as UTMs and ad click IDs, remain available on the live request for attribution but don’t produce separate HTML cache entries. Parameters that might change the rendered page stay in the key.
This means two visitors arriving through different campaigns can share a cached page when the content they should see is identical. We retain their campaign context without making the cache store another copy of the page for every ad click. The browser also receives the experiment assignment used for server rendering, keeping the initial page and the client’s view of the experiment consistent.
That separation was intentional from the start. It gave us a foundation on which the team could add pages and experiments without redesigning the delivery path each time.
Connecting authoring to rendering
The custom CMS followed the same thinking. I wanted us to be able to keep building and expanding it, including blog components that share the marketing website’s look and feel. When we add a component, the marketing agent should be able to learn how to use it in an article.
The shared component contract
We made that connection explicit through a shared component contract. It describes the available blocks, their attributes, their content structure and examples of how to author them. The blog renderer uses it to understand which components belong in an article. The publishing validator uses it to check the content. The marketing agent reads the contract to learn what it can write.
An article can contain ordinary Markdown alongside blocks for things like callouts, quotes and code examples. The renderer turns those blocks into the corresponding blog components. Its adapter registry is checked against the contract’s component names, so a component listed in the contract needs a matching renderer. If a block is malformed or unsupported, the renderer falls back to prose, preserving the words.
The contract connects writing to the actual capabilities of the website. Extending the blog gives the agent another building block it can use, with an explicit description of how that block works. We can keep expanding the reading experience and the authoring workflow together.
Milestones over months
The PR history shows how the foundations came together. The first edge-to-renderer PR opened on March 13 and merged on March 15. Multilingual routing and sitemaps followed on March 22. The first custom CMS model PR opened on July 22 and custom article rendering merged on August 2. Those are delivery milestones within a broader effort that evolved over months. They give a more useful account of the pace than my initial recollection that we built it “in zero time.”
Changing how the team works
The hardest part was getting people comfortable with a different way of working. Colleagues accustomed to visual editors wanted to move pixels directly or edit something by hand. That’s understandable: they knew what they wanted and already had a way to express it.
We still support manual editing as a fallback. But if a change takes too long through an agent, I see that as work we need to do on the agentic flow. Everyone needs to understand that direction. Falling back for a particular task is compatible with it; abandoning the direction whenever there’s friction would leave us rebuilding the old workflow.
My involvement now centers on changes to infrastructure, flows and new capabilities. Work inside established pipelines, including pages, blog posts, design and components, can proceed without my involvement as Project Lead. The review process gives contributors a path forward without routing every decision through me.
Building toward what comes next
We’re making a deliberate bet that agents will be capable of much more in a few months, six months or a year. I can’t promise the timetable. I can build toward it by making the system accessible to agents today and improving the paths where they struggle.
This interview is one of those paths. I supplied the experience and judgment; the agent asked questions and checked the architecture and PR history. The CMS provides the publishing path and the marketing website provides the components and delivery infrastructure. The next person with something worth explaining should be able to use the same flow.