Put Opal to work on the marketing jobs your team repeats every week.
I started with the work: ideation, QA, content review, strategy synthesis, the stuff a marketing or experimentation team redoes every week. Then I decided which part of it Opal could own, and which part stays with a person.
Every build below says what it was. A proof of concept is a proof of concept.
Inputs
- Context
- Tools
- Skills
Specialized agent
One narrow job, done the same way every time
Workflow
- Ideate
- Build
- Review
- Human gateA person decides what launches, what scales and what touches a customer
- ActionThe approved change goes out
- MeasurementDid it change the decision?
- LearningThe result shapes the next round
Learning becomes context for the next round
Principle
Give the agent a job.
A common first design is one giant agent asked to do everything. It costs more, drifts more, and when it’s wrong nobody can tell which part was wrong.
What I avoid
One agent, every job
- One general agentAsked to do everything in a single prompt
- High costEvery step pays for the biggest context
- InconsistentOutput drifts from run to run
- Hard to checkNobody can say which step went wrong
Big context, big bill, hard to trust.
What I build
Narrow agents and a person
- Agent 1: pull the dataRead only what the task needs
- Agent 2: check the rulesStandards, brand, accessibility
- Agent 3: draft the recommendationOne output, one format
- Person approvesThe decision stays human
- Agent 4: actOnly after approval
Each step can be tested, measured and approved on its own.
Experimentation
The human stays in. Just at a different step.
One experimentation workflow, split into specialized agents.
WorkflowRuns the steps in order and passes context forward
IdeationTurns evidence into test ideas
- In
- Analytics and past results
- Out
- Scored ideas
BuildDrafts the variation
- In
- The chosen idea
- Out
- A variation ready to review
ReviewChecks setup against the plan: PASS or FAIL
- In
- Variation, audience, metrics, compliance skill
- Out
- PASS opens a task. FAIL goes back to build.
CMP taskA PASS creates a task for a person
- In
- Review result
- Out
- An approval request
Human approvalNothing launches until a person says yes
- In
- The task
- Out
- Go or no-go
Results summaryWrites the readout in plain language
- In
- Test results
- Out
- A summary and a recommendation
BacklogFeeds what we learned into the next ideas
- In
- Readouts
- Out
- An updated backlog
Program overviewShows the whole program’s health
- In
- Backlog and results
- Out
- A program view for the team
- What I built
- In a partner co-innovation proof of concept I built a chain of narrow Opal agents for experimentation, with a CMP task as the human approval before anything launched.
- Maturity
- A working proof of concept inside a partner environment. It never ran for a client.
- Why it’s built this way
- Each agent can be tested on its own, and the review step can stop the chain with a FAIL before anything reaches a person.
What I did
- Split the work into narrow agents: ideation, build, review, results, backlog and program overview
- Gave review a PASS or FAIL, so the chain could stop itself
- Made a PASS open a CMP task, so a person approves before anything launches
- Shaped behavior with standards and compliance skills instead of longer prompts
- Fed results back into the backlog so the next round starts smarter
Human authority
What stays human, by workflow.
Mixing deterministic checks with judgment calls is how a team ends up trusting a guess the way it trusts a rule. I keep them separate, per workflow.
Experimentation
The review agent checks setup against the plan and returns PASS or FAIL, a rule with no judgment in it. A person still approves launch, every time, through the CMP task above.
Regulated content
An agent checks brand voice, accessibility and answer-engine readiness. The content owner approves. No AI opinion counts as the approval.
Personalization
An agent can recommend an audience or an action. The business rule for who sees what stays with a person until the evidence earns more autonomy.
Customer-facing write
Read happens automatically in the MCP gateway below. Write stays locked behind consent, approval and an audit trail, on purpose.
Review brand, accessibility and answer quality before content reaches the publisher.
- A page of contentDrafted by a person on the content team
- In parallel:
- Brand voice reviewDoes it sound like the organization?
- Accessibility reviewWCAG 2.1 AA checks
- Answer-engine reviewCan AI search understand and cite it?
- ConsolidatorOne list of issues, in priority order
- Person approvesThe content owner decides what changes
- The problem
- Authors were publishing without quality checks, and the team had no way to check accessibility at scale.
- What I built
- For a children’s health system’s content team I built and tested review agents for brand voice, accessibility and answer-engine readiness, with a person approving the result.
- Boundaries
- No clinical guidance from AI, and no patient data in scope. The content owner decides.
- Maturity
- Built and tested in a sandbox. Not running for the client.
- Why separate reviewers
- Each check can be evaluated on its own. When one reviewer is wrong, it’s clear which one to fix.
Strategy
Audience data, content gaps, search readiness and test history lived in five different places.
Every strategy conversation started from zero because nobody had pulled that evidence into one view.
OSA: a strategy assistant made of seven Opal agents
Audience suggesterProposes audiences from customer data
- In
- Customer data profiles
- Out
- Suggested segments, confirmed by a person
Content reviewChecks existing content against the goals
- In
- CMS content
- Out
- Content gaps
GEO auditLooks at readiness for AI search
- In
- Site content
- Out
- Search findings
Experiment blueprinterTurns findings into test plans
- In
- Gaps and findings
- Out
- Test plans, parameters confirmed by a person
Personalization ideasMatches audiences to experiences
- In
- Audiences and content
- Out
- Personalization ideas
Customer journeyPlaces each idea on the journey
- In
- Ideas and journey stages
- Out
- A journey view
RoadmapSequences everything into a plan
- In
- All of the above
- Out
- A prioritized roadmap
- What I built
- I built a working prototype that chained seven Opal agents into one strategy workflow. I wrote the instructions it runs on (Optimizely now calls these skills): brand, KPIs, personas and data governance.
- Human checks
- A person confirms audiences before they’re created and confirms test parameters before a plan is set. A person also chooses where results go.
- Maturity
- A working prototype. Some connections used sample data, so it wasn’t run end to end in production.
Track where Opal credits are going and what the workflow is producing.
- Every agent callLogged with its workflow and step
- Credit usage by workflowWhich steps are expensive, which are cheap
- Repetition checkSame data fetched more than once?
- Deterministic steps move outA data pull or a significance check doesn’t need a model
- Opal stays on judgmentOnly where a model actually has to interpret something
- Measure againConfirm the tuned workflow costs what it should
- What I found
- One day of post-test analysis used roughly 500 to 600 Opal credits, and nobody on the team could say which step was driving it.
- What I recommended
- After one day of post-test analysis used roughly 500 to 600 Opal credits, I recommended moving the repeatable steps out of Opal.
- Why
- A data pull and a significance check are deterministic. They don’t need a model to interpret anything, so logging and caching them once is cheaper and more reliable than asking Opal to redo them.
- What stayed in Opal
- The steps that actually need a model: the plain-language summary and anything Optimizely-specific.
I kept the write path off.
- My applicationAssessment answers and recommendations
- Read-only MCP gatewayFive tools, read access only
- OpalCalls the tools like any other
- Concierge and Virtual TeammateAnswers and guidance from what it read
- Write actions: lockedHeld behind consent, approval, audit and a kill switch. Not switched on.
- What I built
- I built a read-only MCP gateway with five tools and verified it inside Opal. I configured a Virtual Teammate in a partner environment, connected it to a read-only system, and kept write actions switched off.
- The locked lane
- I designed a write path that would need consent, approval, an audit trail and a kill switch. I left it off on purpose.
- What an experimentation Virtual Teammate would own every week
- Check active tests, flag missing QA or review, summarize completed results, update backlog context. It would flag a decision that needs a person; it would not make the launch call, the statistical interpretation, or anything that writes to a customer-facing system.
One-to-one pages
I built a rule-based version of Optimizely’s own page-generation pattern.
As a partner I was walked through Optimizely’s own method for generating one-to-one pages. That product is theirs. Separately, I built my own version with rules instead of a model, so every page could be traced back to a decision.
Optimizely’s agentic pattern
An agent builds the page
- Customer data and audience
- Research
- Page-generation agent
- CMS
- Governance and human review
- Distribution
Optimizely describes Limitless 1:1 Personalization as starting with human review and allowing more autonomy as quality is proven.
My prototype
Rules build the page
- Assessment answers
- Rule-based recommendationNo model writes the copy
- CMS (SaaS) content API
- Read back through GraphVerify nothing was lost
- A page for one person
I built a prototype that wrote a personalized page for each visitor into Optimizely CMS (SaaS) from their assessment answers, then verified it through Graph. It was verified in production, then retired as the live path.
What building it showed: generating the page was the easy part. The work was everything around it:
What I’d build next
Worth building. Not yet built.
My ideas, not Optimizely’s roadmap. Each one keeps a person on the decision that matters.
Experiment learning network
Turns past tests into better next tests.
- Flow
- Past results, patterns, new hypothesis, pre-analysis, QA, post-analysis
- Keeps
- A reusable record of what worked and why
A person decides which learning becomes a rule.
Personalization readiness agent
Says no until a segment has evidence for a different experience.
- Asks
- Do we know who this is? Is there a signal? Does it predict a different need? Do we have a better experience to show? Can we measure it?
- If not
- Don’t personalize yet
A person decides when the evidence is good enough.
Content governance workflow
Moves every page through the same checks before and after publishing.
- Steps
- Create, accessibility, brand, search and answer-engine readiness, compliance
- After
- Publish, then keep monitoring
A person approves before anything goes live.
I’ve spent most of my career asking what makes someone take the next step. Optimizely gave me better ways to test the answer. Opal is giving us better ways to act on what we’ve learned.
The part I still care about hasn’t changed: the system should help the team make a better next decision.
If any of these stories are ones you’d want to talk through, that’s the conversation I enjoy most.
Optimizely and related product names are trademarks of their owner. This section reflects my own professional experience with the platform. It is not affiliated with or endorsed by Optimizely, and client examples are described by industry, not by name.