Strategy and Copy Agent: Evidence-to-Creative Direction Pipeline
Ugo Chukwu
Verified
Strategy and Copy Agent — Engineering a Governed Path From Evidence to Approved Creative Direction
Role: Founding Lead Engineer
Company context: Peerless
Public reconstruction: Strategy and Copy Agent by Etherlabs
Repository: https://github.com/Etherlabs-dev/strategy-copy-agent
Delivery: Tier 1 runnable repository; local and CI verified, intentionally not hosted
Strategy and Copy Agent by Etherlabs is a fresh, independently branded reconstruction of strategy-and-copy systems I designed and built during my work for Peerless CMO. The public repository uses new code, deterministic synthetic organizations, and fictional research and performance evidence. It contains no proprietary source, private prompts, production credentials, client identities, or live advertising actions.
An evidence-bound strategy system—not a one-click copy generator.
The outcome
I designed and built a full-stack workspace that turns research evidence and synthetic ad observations into a reviewable portfolio of distinct campaign strategies, then carries each strategy through evidence-linked hooks, static copy, short-video scripts, immutable revision, exact-version approval, and a safe handoff.
The important outcome is not that the interface can produce persuasive sentences. It is that the system makes the reasoning around those sentences inspectable:
Is the organization ready to create strategy, or is essential evidence missing?
Which source supports a hook, proof statement, or buyer insight?
Does each campaign bet occupy a genuinely different strategic position?
What does the buyer believe now, and what supported belief should move?
Which version changed, who was authorized to change it, and which exact version was approved?
Can approval remain separate from export or live execution?
The result is a product workflow where creative strategy behaves like a governed decision artifact rather than disposable generated text.
The implemented desktop workspace uses deterministic Northstar Athletics data. Its 84% coverage value and every source, offer, strategy, and warning are synthetic demonstration data.
The problem: fluent copy can hide weak decisions
Most copy-generation demos optimize for the moment of generation. Add a prompt, select a tone, and receive a page of headlines.
That interaction is visually satisfying and operationally incomplete. A fluent result can still be strategically repetitive, unsupported by customer evidence, built on stale proof, inconsistent with awareness stage, or approved from an outdated version. The interface rarely shows those failures because it treats generation as the product.
The real engineering problem was broader: how do you preserve evidence, strategic intent, revision history, and human authority across the entire path from research to handoff?
This required a stateful product, a strict domain contract, deterministic checks, authorization boundaries, durable history, and explicit non-goals. A language model could eventually draft within that system, but it could not be allowed to define its controls.
My role and ownership
I served as Founding Lead Engineer at Peerless CMO, beginning February 10, 2026. I was the sole engineer through July 2026, then provided technical direction as the engineering team expanded.
For the underlying strategy-and-copy work, my supported ownership includes:
identifying and structuring the product problem;
defining the evidence, strategy, copy, review, and handoff boundaries;
designing the product and system architecture;
building full-stack workflows and persistence;
defining contracts, state transitions, and failure behavior;
testing tenant, role, concurrency, durability, and idempotency boundaries;
iterating against real operational constraints; and
translating the production lessons into this sanitized public reconstruction.
This describes architecture and delivery leadership without inflating people-management or unsupported commercial impact.
Constraints that shaped the system
The product had to remain useful while respecting several hard constraints:
Missing brand truth, proof, or audience intelligence must produce a warning or block—not invented confidence.
Source text must remain evidence, never executable instruction.
Exact portfolio checks cannot depend on probabilistic model judgment.
Every strategy needs a complete, testable contract.
Tenant identity must be derived from the verified session, not trusted from a mutation payload.
Strategy leads and brand reviewers require different authority.
Revisions must reject stale writes and survive process restarts.
Approval must lock one exact version.
Handoff must be separate, checksummed, idempotent, and non-executing.
The public repository cannot use customer data, launch ads, or imply performance lift.
System architecture: governance around generation
The public implementation is a standalone React, Vite, and TypeScript interface backed by FastAPI, Pydantic, and durable SQLite state. Signed demo sessions represent two fictional organizations and two roles. OpenAPI is the web/API contract.
The language-model provider is deliberately outside the control plane. Deterministic contracts and authorization remain authoritative during provider failure or complete provider absence.
The architecture separates five concerns:
Context and readiness: brand truth, audience, customer language, proof, objections, offer, prior synthetic observations, and safe claims.
Strategy portfolio: distinct campaign bets with explicit coverage and deterministic concentration checks.
Copy assets: hooks, static copy, and short-video scenes tied back to strategy and evidence.
Governed state: immutable revisions, optimistic concurrency, audit history, and exact-version approval.
Safe delivery: a reviewable checksum handoff that never creates or publishes an advertisement.
From evidence readiness to a strategy portfolio
Before producing a campaign direction, the system evaluates whether its inputs are usable. Each readiness area is typed as ready, warning, or blocked. A stale proof source can remain visible as a warning; missing required context can prevent approval.
The strategy portfolio then creates four distinct bets across angle, format, awareness stage, emotional posture, hook family, proof, offer, and buyer movement. Diversity is evaluated across the portfolio rather than inferred from surface-level wording.
A portfolio is not diverse because four headlines use different words. Each bet must occupy a distinct, contractually visible position.
The strategy contract is the central artifact
Every strategy item carries a structured contract:
audience and awareness stage;
current and target belief;
marketing action;
mechanism and differentiation;
proof and evidence identifiers;
offer and call to action;
hook family and emotional posture;
rationale and expected learning; and
a deterministic success signal.
This contract prevents the copy layer from silently rewriting the strategic decision. Hooks and scripts become expressions of the approved strategy, not independent improvisations.
Belief movement is not a creative instruction
“Use a product close-up” is not a buyer belief. “I need more gear to improve” and “a repeatable ritual helps me improve” are two different mental states.
Keeping current belief, evidence trigger, and target belief separate gives reviewers a precise question: does this strategy contain enough relevant proof to support that movement? The interface exposes the answer next to the creative assets instead of hiding it inside a prompt.
Copy Studio preserves strategy and provenance
The Copy Studio organizes hook families, static copy, short-video scenes, evidence links, and copy-review notes around the selected strategic bet. A hook cites synthetic source identifiers. Each video scene retains audio or on-screen copy, visual direction, and evidence.
This approved interface concept established the Copy Studio information architecture. The public application implements the workflow and verifies tab switching, hook selection, and role-aware review behavior.
This structure makes a critical distinction: provenance is not a bibliography added after content generation. It is a relationship carried by the domain model.
Immutable revision, exact approval, separate handoff
The workflow uses four states:
draft → awaiting_review → approved → handed_offA strategy lead may create a bounded revision only when the supplied
expected_version matches the current snapshot. A stale writer receives 409 Conflict. Approval belongs to the brand reviewer and locks one exact version. Once approved, that version cannot be revised.
The server enforces those semantics rather than relying on disabled buttons.
Cross-tenant identifiers return 404; role violations return 403; stale versions return 409.
Tenant and role boundaries
Signed, expiring demo sessions carry organization and role claims. The API verifies the signature in constant time, derives organization scope server-side, and never accepts an organization identifier in a mutation body.
The two public roles are intentionally asymmetric:
Strategy lead: inspect, revise, submit, and create an approved handoff.
Brand reviewer: inspect and approve the exact review version.
Neither role can cross tenant boundaries. A reviewer cannot rewrite strategy content, and a strategy lead cannot approve their own version.
Safe handoff is not publishing
After approval, a strategy lead can create a handoff only for the exact approved version. The service serializes the snapshot canonically, produces a SHA-256 checksum, and records the result against an idempotency key. Repeating the same request returns the same handoff.
The boundary stops there. There is no ad-platform connector, campaign launch, media generation, or external publishing action. The handoff proves controlled delivery without pretending that approval is execution.
Verification and public proof
The repository was verified on August 11, 2026 with:
4 passing web interaction tests;
8 passing API, negative-security, role, idempotency, and restart-durability tests;
8/8 deterministic evaluation gates;
passing frontend lint, API Ruff, and production build;
JavaScript and Python audits with no known vulnerabilities at publication;
a passing credential-pattern scan;
local health and OpenAPI smoke tests;
desktop acceptance at 1440 × 900;
mobile acceptance at 390 × 844; and
no observed browser-console warnings or errors during retained acceptance.
GitHub Actions run
31512563798 passed both public jobs at commit 6fb05d4.
These results prove repository behavior and CI repeatability—not campaign lift, provider quality, hosted availability, production traffic, or client impact.
What the evaluations measure
The deterministic evaluation suite checks that:
the portfolio contains at least four bets;
primary angles are distinct;
every strategy has evidence;
every hook cites evidence;
each strategy defines an actual belief movement;
each strategy includes a deterministic success signal;
copy avoids prohibited absolute guarantees; and
every fixture source is explicitly synthetic.
These are contract and fixture-completeness checks. They are not semantic-quality scores on real campaigns and should not be presented as model accuracy.
Historical engineering context
A dated August 11, 2026 review of the private Peerless source confirmed a substantial end-to-end strategy-and-copy subsystem spanning authenticated routes, evidence readiness, deterministic winner ranking, structured planning, immutable revisions, approval and release controls, persistence, tests, and multiple review surfaces.
That private evidence supports the high-level architectural story and my role. It does not authorize publication of proprietary prompts, internal names, client data, private paths, or numerical authorship totals. Those details remain in the private claim ledger.
What the public reconstruction proves
The public repository demonstrates that:
strategy readiness can fail visibly instead of inventing context;
a campaign portfolio can be evaluated for contractual diversity;
hooks, copy, and scripts can preserve synthetic provenance;
belief movement can remain explicit and reviewable;
tenant and role boundaries can be tested without production data;
durable revisions can reject stale writes;
approval can lock one exact version; and
handoff can be safe, checksummed, idempotent, and non-executing.
The mobile implementation deliberately stages the same decision model as a single column rather than shrinking the desktop table.
The most consequential engineering decisions
1. Treat strategy as a contract, not a prompt
Prompts are implementation detail. The strategy contract is the durable product artifact that tests, UI, review, and downstream systems can share.
2. Evaluate the portfolio, not isolated outputs
Individually plausible concepts can still form a repetitive portfolio. Coverage and concentration require cross-item checks.
3. Separate knowledge, intent, and expression
Evidence supports a strategic decision; the strategy defines buyer movement; copy expresses it. Collapsing all three into generated text destroys traceability.
4. Make failure states useful
Missing evidence, stale proof, blocked readiness, and provider degradation remain visible product states. They do not become silent hallucination.
5. Separate revision, approval, handoff, and execution
Each transition carries different authority and risk. Modeling them independently makes the workflow testable and operationally safer.
6. Keep provider intelligence outside the control plane
A provider can draft. It cannot bypass tenant scope, required fields, safe-language rules, version checks, approval, or handoff constraints.
What I learned
The unit of quality in an AI strategy product is not the sentence. It is the reviewable decision around that sentence: evidence, buyer movement, portfolio position, revision history, approval authority, and safe next action.
The most valuable parts of this system are therefore not the most theatrical. They are the boundaries that remain stable when generated content changes: typed contracts, deterministic checks, durable state, role separation, and explicit non-goals.
That is what turns an AI feature into a product teams can reason about.
Explore the work
Peerless CMO context: https://peerlesscmo.com
The repository includes the runnable local demo, synthetic fixtures, API, migration, OpenAPI contract, tests, deterministic evaluations, security model, architecture, runbook, production lessons, and deployment guidance.
Like this project
Posted Aug 12, 2026
Developed a strategy system that links research evidence to campaign strategies with a focus on governed decisions.
Likes
0
Views
1
Timeline
Mar 1, 2026 - Aug 31, 2026
