A couple of weeks ago I had the chance to spend a day at the Optimizely Opal Partner Enablement Workshop hosted at the Horizontal Minneapolis office. It was a hands-on session focused on getting partners up to speed on Opal — Optimizely’s AI orchestration layer — and walking through the building blocks you actually compose when you build an Opal agent.
This post is my attempt to distill the basics into something I can come back to (and that maybe helps you, too, if you’re just starting out). If you want the marketing-level pitch first, the official landing page is here:https://www.optimizely.com/ai
At its core, Opal is built on four primitives: Instructions, Tools, Specialized Agents, and Workflows. Once those four clicked for me, everything else in the platform started to feel a lot less mysterious. Let’s walk through each one.
Instructions [Recently updated to Context]
Short explanation: Instructions are the natural-language guardrails that shape how an Opal agent thinks and responds. They are the agent’s job description — its role, its tone of voice, what it should and shouldn’t do, how it should handle edge cases. If you have ever written a “system prompt” for an LLM, you already know the shape of this. The difference in Opal is that instructions become a reusable, versioned asset that any agent or workflow can pull in.
One example: A “Brand Voice” instruction set that tells the agent to write in second person, keep sentences under 20 words, avoid corporate jargon, and always end on a clear call to action. Drop those instructions into a content-writing agent and every draft it produces starts from the same baseline — no more re-explaining the brief.
Opal team has provided multiple examples here, repo link: https://github.com/optimizely/opal-agent-examples/tree/main/instructions
Tools
Short explanation: Tools are the things an Opal agent can actually do in the outside world. A tool is a callable function — usually exposed over an API — that the agent can invoke when it decides it needs to fetch data, take an action, or hand work off to another system. Without tools, an agent is a very articulate text generator. With tools, it becomes something that can publish a page, run a query, or trigger an experiment.
One example: A simple get_cms_content tool that takes a content ID and returns the latest draft from Optimizely CMS. The agent doesn’t need to know how the CMS works — it just needs to know that this tool exists, what it accepts, and what it returns. That separation between “reasoning” (the agent) and “doing” (the tool) is what makes the model practical to build on.
You can write these tools in either of these languages:
- C# .NET
- Python
- Typescript
Following repos can help you get started :
- https://github.com/optimizely/opal-agent-examples/tree/main/tools
- https://github.com/newscred/sample-opal-tools
Here’s how it looks:
Specialized Agents
Short explanation: A Specialized Agent is what you get when you combine a focused set of instructions with a curated set of tools and aim it at one specific job. Instead of a single do-everything assistant, you build narrow agents that are very good at one thing — SEO review, A/B test ideation, product copywriting, content tagging — and then compose them. Narrow agents are easier to reason about, easier to test, and easier to trust in production.
One example: An “SEO Reviewer” agent whose only job is to read a draft article and return three things — a recommended meta title, a meta description under 155 characters, and a list of missing keywords based on the target topic. It has instructions about how to think like an SEO analyst, and a small tool for pulling keyword data. That’s it. No content generation, no publishing — just review.
Multiple examples are available here : https://github.com/optimizely/opal-agent-examples/tree/main/specialized-agents
Workflows
Short explanation: Workflows are how you stitch the pieces together. A workflow chains agents, tools, and decisions into a multi-step process — pass the output of one agent into the next, branch based on a result, loop until a condition is met. This is where Opal stops feeling like “a chatbot with extras” and starts feeling like an orchestration platform. The agents stay small and focused; the workflow is where the choreography lives.
One example: A “Blog Post Pipeline” workflow that takes a topic brief, hands it to a Writer agent, passes the draft to the SEO Reviewer agent above, calls a CMS tool to create a draft entry, and then notifies the editor in Slack. Each step is independently swappable — you can upgrade the writer, replace the SEO reviewer, or change where the final draft lands without rewriting the whole thing.
Repo link: https://github.com/optimizely/opal-agent-examples/tree/main/specialized-agents (workflow patterns live alongside the agent examples in the same repo)
My Final Example
To put all four primitives in one place, here is the small example I’ve been sketching out since the workshop — a “Web Accessibility Validator Agent which sends report via email”:
It’s a small example on purpose. Once those four primitives clicked, the temptation was to design something enormous on day one — but the thing the workshop kept pushing was to start narrow, get one workflow working end-to-end, and then grow from there.
Wrapping up
If you remember nothing else from this post, remember this: Instructions/Context shape behavior, Tools enable action, Specialized Agents combine the two for a specific job, and Workflows orchestrate the whole thing. Almost everything you’ll build on Opal is some arrangement of those four pieces.
Huge thanks to the Optimizely and Horizontal teams who put the Minneapolis partner enablement workshop together.