We Tried to Build a Marketing System That Could Improve Itself

We did not start by deciding to build an AI CMO. We started with a more annoying problem: Endertech had plenty of marketing tools, but no system whose job was to learn across all of them.

Paid search, organic search, content, social, outbound, analytics, the website, and CRM were all real. Each produced activity and reports inside its own boundary. What we lacked was a persistent loop that could keep asking the same four questions across the whole commercial system: What happened? What does it mean? What should we change? Did the change work?

That gap became the original ambition. We were not trying to “use AI to write more content.” We were trying to build a marketing system that could improve itself—observe, interpret, recommend, approve, execute, verify, and measure again.

The first idea was a closed loop, not a smarter spreadsheet

The earliest useful framing was operational, not magical. Collect evidence. Spot waste and opportunity. Interpret results across channels. Recommend a change. Execute only what was approved. Verify that the change actually landed. Then measure again.

Those steps sound obvious when written in a line. In practice they are easy to collapse. Teams often treat a dashboard as interpretation, a recommendation as approval, a ticket as execution, and a green status as verification. The whole point of the project was to stop collapsing those states.

ChatGPT became the natural strategy layer because that was already where cross-channel questions lived. It could reason about paid media, SEO, conversion, content, positioning, sales feedback, and business constraints in one context. For interpretation and tradeoffs, that was a genuine advantage.

It also exposed a limit quickly. A conversational strategist is not automatically a good high-frequency operations engine. Frequent collection, normalization, monitoring, and routine coordination do not belong in the same place as portfolio judgment. Leaving them there creates the wrong kind of busywork: the system that should be thinking spends its attention fetching, formatting, and chasing connectors.

That discovery mattered more than any single vendor choice. It told us the first architecture was incomplete even if the reasoning layer was useful.

Specialists arrived because one model could not own every job

As the idea matured, we explored specialist systems instead of assuming one model should run marketing end to end.

Ryze was one of the first serious examples. Its value was not merely content generation. It brought SEO and AI-prompt monitoring, search-coverage content, off-site work, and—later—an execution surface for approved ad-platform changes. That mattered because strategy without a dependable way to change the live system is only commentary.

Profound and Okara were also part of the broader exploration while we were still clarifying requirements. Current operating documents do not record a precise rejection decision or final comparative verdict for either. Their lasting contribution to the story is architectural: they forced a clearer question. Should we adopt one monolithic AI-marketing system, or assemble a team of specialist capabilities with explicit jobs?

The answer that stuck was specialization.

Treg filled a different gap: live access when direct connectors were missing or inconvenient. Over time its role settled as supplemental access and validation, not ownership of the underlying facts. Social Bloom became the cold-outreach system through meeting handoff. Postiz became social scheduling and analytics. Cursor and Cursor Cloud Agents became the natural route for bounded website, tracking, and related implementation work.

Each addition made the fantasy of one all-knowing AI marketer less plausible—and the operating model more honest. Capability was no longer the scarce resource. Responsibility was.

Grok Bot was the architectural turning point

Specialization still left a missing role: persistent operations coordination.

Grok Bot changed the design because it could run like an operations coordinator rather than an occasional assistant. It could schedule recurring jobs, collect evidence, normalize observations, monitor systems, prepare handoff packets, coordinate specialist executors, and return results for later review.

That allowed a clean separation that is now foundational. ChatGPT remains the strategic reasoning layer. Grok Bot is the operational coordination layer. High-frequency collection and routine orchestration should not consume the same system responsible for cross-channel interpretation.

In practical terms, that is when “self-improving” stopped being a slogan and started looking like software operations. The strategy layer could stay small and deliberate. The operations layer could run on a clock.

Cursor stayed bounded on purpose

As recommendations began to imply website and software changes, Cursor Cloud Agents became a useful implementation path. The important design choice was not “let the AI edit production.” It was: turn an approved decision into a bounded engineering assignment.

Exact requested change. Acceptance criteria. Affected systems. Tests. Branch or merge-request workflow. Human review. That pattern reinforced another emerging rule: the strategist should not automatically become the executor, and execution should not silently expand beyond the approval.

This also forced better decision writing. Vague asks like “improve conversion” do not survive contact with a branch, a test checklist, and a merge request. Bounded implementation made fuzzy strategy expensive—and therefore rarer.

Ansible and MCP made the hard constraint obvious

At some point model intelligence stopped being the main bottleneck. Agents needed precise, permissioned ways to interact with real business systems.

So we expanded the capabilities exposed by our internal Ansible platform and its MCP tooling. The goal was to replace fragile copying and exports with structured operations: complete blog reads, precise edits, conflict checks, CRM lifecycle evidence, newsletter delivery surfaces, and other controlled functions.

The lesson was blunt. If the system cannot read the authoritative record, perform a precise action, report the actual state, or expose failure clearly, better prompting does not fix it. The limiting factor moved from model quality to interface quality.

That is also why later articles in this series talk about sources of truth so carefully. An AI that summarizes CRM outcomes from a spreadsheet projection is not the same thing as an AI that reads the CRM. Convenience is not authority.

Drive and the Growth Decision Ledger solved coordination without fake omniscience

Once specialist systems were useful, a new problem appeared: they did not share one memory.

We did not solve that by forcing every platform into one database. Google Drive became a neutral coordination layer. The Growth Decision Ledger became the normalized decision surface. Grok Bot writes evidence packets. ChatGPT or a designated human interprets and merges decision-relevant material. Operational systems remain authoritative for their own facts. The ledger records cross-system decision state.

Shared context is not shared authority. That distinction later became one of the most important parts of the architecture—and it is the subject of the next article in this series.

Scheduling made the ambition concrete

The phrase “self-improving marketing system” only became operational once different work got different clock speeds.

Early evidence collection for paid and analytics. CRM outcome synchronization. Social-performance pulses. A morning review that converts evidence into a small number of decisions. A human approval window. Scheduled execution of approved work. Afternoon reconciliation. Weekly strategic review. Monthly portfolio and economics review.

The specific times matter less than the principle. Automated does not mean everything should run continuously. Paid waste can require daily scrutiny. Social conversations can go stale within hours. SEO patterns usually need longer windows. Portfolio allocation belongs at a slower cadence. Code changes should happen only after approval and through controlled implementation.

Different clock speeds also protect attention. If everything is urgent, nothing is governed. Cadence is how the organization decides which uncertainties deserve a decision today and which ones should wait for a better sample.

Failure forced the system to grow up

One of the most useful maturities came from failed execution.

An approved task can be incomplete even when an executor reports progress. Early on, the temptation is to retry until something looks successful. That erases the signal the system needs. So we developed rules for preserving failed attempts and giving corrective work its own lifecycle: classify the failure, keep the original result, create a bounded corrective child only when the original authorization still applies, or return for new approval when scope or risk expands.

A recent landing-page QA sequence made the point concrete. The original approved check failed because CRM reconciliation was incomplete. A corrective child completed more of the acceptance criteria and still remained Failed where evidence was missing. A later verification-only child reconciled the CRM records and was Verified—while the earlier Failed attempts stayed in history. That pattern is not bureaucracy. It is how a learning system avoids lying to itself.

The same pattern appeared when an approved unpublished blog draft could not be created because an Ansible interface was unavailable. The failure stayed Failed. A corrective attempt retried inside the original scope. A later verification confirmed the draft existed and remained unpublished. Success did not rewrite the earlier miss out of existence.

What “self-improving” came to mean

The system does not improve because a model rewrites itself overnight. It improves because actions produce evidence; evidence changes later decisions; failures change procedures; recurring work moves to better-suited systems; duplicated processes get retired; operating instructions evolve; and humans retain authority over consequential changes.

That is a practical definition. It is also why we stopped asking which AI should run marketing and started asking what each system should be responsible for.

The next article describes those jobs: strategy, operations, specialists, sources of truth, and the handoffs between them. The third explains the learning loop itself—cadence, approvals, verification, and corrective work—in more detail.

What we thought versus what we learned

Looking back, several assumptions did not survive contact with real operations.

We thought one AI might eventually run the system. We learned specialization was more reliable once each role had clear inputs, outputs, and authority.

We thought data access would be the hard problem. We learned provenance, ownership, and authority were harder. Two systems can both return a number and still disagree about what the number means.

We thought automation meant execution. We learned verification is part of execution. Asking for a change and confirming the live state matches the approval are different jobs.

We thought self-improving implied autonomy. We learned supervised experimentation creates better learning because humans remain responsible for consequential moves while machines handle recurring collection and preparation.

We thought a failed task should simply be retried. We learned preserving failure is necessary if the system is expected to improve. A tidy green status that forgets yesterday’s miss is not maturity.

Those lessons are why this origin story ends where it does. The interesting question was never which model was cleverest. It was whether we could design an organization of humans, AIs, and software that could learn together without losing accountability.

If there is one management lesson from the origin story, it is this: ambition without role design produces automation theater. Role design without evidence produces polite meetings. Evidence without preserved failure produces false confidence. We needed all three before the system became something we were willing to trust with real work.