OpenAI expanded Codex with role-specific plugins, shareable Sites, and annotations, turning a coding agent into a broader work surface for analysts, sales
What Role Plugins Actually Change
Codex started as a tool that reads a codebase and writes code. Role plugins reframe it around who is doing the work rather than what language they type. Instead of one generic assistant, you configure Codex with a plugin scoped to a job — an analyst pulling numbers, a salesperson drafting outreach, a support lead triaging tickets — and the agent inherits the context, vocabulary, and default actions that role expects.
The practical effect is that fewer people have to translate their intent into engineering terms. A plugin can carry its own instructions, preferred data sources, and output conventions, so the same underlying agent behaves differently depending on the hat it is wearing. That is what turns a coding tool into something closer to a shared work surface.
Sites: Turning Output Into Something You Can Hand Off
A coding agent's output is usually a diff or a file that only makes sense inside an editor. Shareable Sites change the delivery format: the result of a Codex run becomes a live page you can send to someone who will never open a terminal. That closes the gap between "the agent did the work" and "a stakeholder can see it."
This matters most for non-engineering roles. An analyst can produce a page a manager reviews directly; a sales team can share a generated summary with a prospect. Because the artifact is a URL rather than a repository, distribution stops being a separate step you bolt on afterward.
Annotations and the Feedback Loop
Annotations let people mark up what the agent produced instead of describing changes in prose. Pointing at a specific spot and saying "this part is wrong" is faster and less ambiguous than writing a paragraph of instructions, and it keeps the correction attached to the thing being corrected.
For teams, this creates a review loop that resembles how people already collaborate on documents. Consider what each piece contributes:
- Role plugins decide what the agent tries to do and how it frames the task.
- Sites make the result visible to people outside the tooling.
- Annotations feed targeted corrections back in without a full rewrite.
How to Approach It Without Overreaching
Treat role plugins as scoped definitions, not magic. The value comes from being specific about a role's inputs, its acceptable outputs, and the boundaries of what it should act on. A vague plugin produces a vague agent; a tightly defined one is predictable and easier to trust. Start with a single role where the workflow is well understood, and expand only once the outputs hold up to review.
The broader shift is worth naming plainly: the boundary between "software you use" and "work someone does for you" gets thinner when the same agent can be pointed at coding, analysis, or outreach depending on its plugin. That is powerful, but it also means the quality of your role definitions and your review habits now sets the ceiling on the output. Keep humans in the annotation loop, and let the Sites you share be the checkpoint where judgment still applies.