I use this AI stack to run marketing and growth work.
Codex is where most of the work happens. Around it, I have shared memory, specialist skills, recurring automations, project workers, verification, and authority rules.
On 22 July, I audited the setup and counted 115 reusable components across nine workstreams:
- 25 specialists: 19 skills and six Custom GPTs
- 27 recurring and background operators
- 63 project and QA workers
Together, they form the AI operating system I use to run my work.
What it runs
The work spans acquisition, creative, SEO, funnels, lifecycle, analytics, and research. The system keeps those surfaces connected and routes the operating work around them.
Codex is the execution environment
I use Codex for work that needs more than a single answer: research, code, browser work, documents, analysis, and multi-step execution.
It can inspect the current state, use tools, change a file, verify the result, and record what happened. That makes it the main execution environment in the stack.
Execution is one layer. The system also has to know which context to load, what it owns, what evidence counts, what it may change, and when a decision has to return to me.
The stack has a control plane
The control plane holds the management rules shared by every workstream:
- a canonical workstream registry;
- an append-only operating log;
- explicit ownership and routing;
- acceptance and reporting standards;
- authority rules and escalation gates;
- a morning, evening, and weekly management cadence.
This creates one operating model for different kinds of work. The subject matter changes. The management standard does not.
Shared context carries the state
My Second Brain holds durable knowledge and decisions. Project histories and canonical trackers hold current state. Skills carry instructions, judgment rules, procedures, tool use, and quality boundaries.
Before a workflow starts, it reads the relevant state. After a material result is verified, the decision and state change are written back.
The next run continues from the actual current state instead of reconstructing the project from a chat history.
One coordinator across the work
I have one human-facing coordinator, essentially my chief of staff, as the main point of contact.
Under it, nine workstream coordinators own delivery inside their domains. Each can route bounded work to the specialists, automations, project crews, and QA workers in the shared execution layer.
Every workstream follows the same loop:
- Read the current state and rules.
- Route a bounded task to the right worker.
- Verify the result and report what matters.
- Write back any material decision or state change.
The coordinator owns the outcome and the route. The worker owns the bounded piece of execution.
Verification is part of the work
The reporting standard is:
- the outcome;
- the evidence;
- the alternatives checked;
- why one option won;
- the remaining risk;
- the next action and owner.
Verification preserves the difference between unavailable data, zero, and success. A task is complete after the result has been checked.
Authority is granted by lane
Routine work can run without per-item approval when its permitted actions, evidence gates, logging, rollback, and stop conditions are explicit.
Actions inside that authority are executed and verified. Decisions, exceptions, and risks outside it return through the chief of staff to me.
New positioning, unverified claims, private material, money, permissions, and outbound messages stay outside a lane until I grant that authority.
One workflow in practice
The twice-weekly search and funnel monitor for Doubledash is one example of how the system runs a growth workstream.
It has one operational owner across crawlability, indexing, search visibility, referrals, and funnel defects. Before it starts, it reads the controller, the previous state, the publishing state, and the commercial scorecard.
Its decision hierarchy is:
- Paid or qualified demand.
- Attributable inquiry intent.
- Diagnostic and Review Intelligence progression.
- Qualified organic visits.
- Rankings and impressions.
The workflow checks the measurement surfaces and the live website. If it verifies a broken route, canonical, CTA, or analytics event, it can repair the low-risk defect and verify the result. If there is no verified defect, it leaves the repository alone.
What comes back to me is the commercial status, the technical evidence, the funnel state, the action taken, the remaining risk, and a direct recommendation: continue, improve, pause, or pivot.
What the operating model changes
Marketing and growth work crosses channels, product, data, creative, and commercial decisions. The system can distribute execution because ownership, context, verification, and authority are designed into it.
The AI stack is the management and execution layer underneath that work.