Eight roles, not eight hires: the crew inside Vortex IQ

Most "AI agent" pitches sell you one clever generalist: a single model that reads, decides, writes, ships, and then reports on itself. It demos beautifully. Then it edits your live store at 2 a.m. on a hunch, and nobody can say which step went wrong, because there were no steps. There was one actor doing everything.

Vortex IQ is built the other way round. Instead of one agent that does eight things, the platform runs eight roles that each do one thing, and each one has a boundary it will not cross. These eight roles are the Vortex Agents layer inside Vortex IQ, the AI Operating System for e-commerce: the agentic operations and modernisation layer of the commercial platform. Below is the crew, what each role works like, and the line each one is not allowed to step over.

Why roles, not one clever agent

The design borrows from how a real operations team stays out of trouble: separation of duties. The person who writes a change is not the person who approves it. The person who approves it is not the tool that applies it. The tool that applies it keeps a receipt. No single actor has the whole chain, so no single mistake, or single bad instruction, can run end to end unchecked.

Two ideas make that work, and they are worth stating precisely before you meet the crew.

A role is fixed. A character is not.

A role decides the job. The audit log always records the role, never the nickname. A character is the face and name on that role, and you can change both. Rename Scout to anything you like; the log still records that the Scout role did the gathering. The story on screen can be friendly. The record underneath stays exact.

The job titles describe the work, not a headcount. When we say a role works like a release engineer, that is the shape of the job, not a claim that you are paying for eight people. These are eight functions that a team of three to five people already performs, named and separated so software can carry them safely. You are not hiring eight agents. You are giving eight jobs a clear owner and a clear boundary.

The eight roles

1. Lead, played by Beacon (always on)

Works like a project manager or delivery lead.

Beacon reads the request, works out which specialists it actually calls for, dispatches only those, and holds the rest back. If a job needs gathering and reporting but no changes, the roles that make and apply changes never wake up.

The boundary: Beacon never touches a tool itself. It dispatches, and it stops. The lead that also does the work is the lead that skips its own checks.

2. Scout, played by Scout

Works like an SEO auditor or research analyst.

Scout gathers. It pulls from any connected source, your store, your analytics, your search data, your ad accounts, and reports exactly what came back. What you get is the raw truth of what the connectors returned, nothing dressed up.

The boundary: Scout never writes anything, and never invents what a tool could have fetched. If the data is not there, Scout says so. It does not fill the gap with a good guess.

3. Analyst, played by Iris

Works like a data or BI analyst.

Iris runs the deterministic engine over what Scout brought back: it filters, extracts, and reshapes. Same input, same output, every time. When Iris tells you a number moved, you can reproduce that number yourself from the same source rows.

The boundary: Iris never does the maths in its own head. The calculation runs through the engine, not the model, so every figure stays reproducible and nothing is roughly right.

4. Maker, played by Forge

Works like a developer, designer, or copywriter.

Forge writes the thing. A title, a description, a fix, a summary. Then it hands the work over as a proposal, not a change. What Forge produces is a draft with your name on the approval line, waiting.

The boundary: Forge never applies, approves, or checks its own work. The role that creates the change is deliberately not the role that judges it. That separation is the whole point.

5. Runner, played by Kai

Works like a DevOps or release engineer.

Kai applies what you approved, and can roll it back byte for byte. Fixes run on a staging snapshot by default, with zero live writes; live writes go to the real store only through the platform admin connector, and only where you have opened the gate. Every change is captured and exactly reversible, proven live on Shopify and BigCommerce.

The boundary: Kai never acts without an approval, and never decides what should change. It is hands, not judgment: exactly what was signed off, plus the receipt that lets you undo it.

6. Checker, played by Lens

Works like QA, code review, security, or accessibility.

Lens flags the findings that must never be changed automatically, and holds them for a person to judge. Some things are too sensitive to touch on a machine's say-so, and Lens is the role that knows the difference and refuses to let them through the automatic lane.

The boundary: Lens never fixes what it finds, and never checks work it produced. A reviewer that can also edit is not a reviewer.

7. Reporter, played by Memo

Works like an account manager or technical writer.

Memo records what happened and tells people, short and factual, with the real numbers. When you come back, Memo is the one that says what was audited, what was proposed, what you approved, and what changed, in plain language.

The boundary: Memo never acts on the store, and never announces work that did not happen. The report matches the record. If it was not done, Memo does not say it was.

8. Pulse, played by Pulse (always on)

Works like a site reliability engineer.

Pulse proves the connectors actually work, on a heartbeat. It health-checks connections before they break, retries transient failures with a backoff ladder, auto-pauses what it cannot fix (always with a plain reason and a Fix and resume button), and interrupts you only when something genuinely needs a decision.

The boundary: Pulse never nags. A healthy heartbeat says nothing at all. It alerts one trusted channel, never inside quiet hours, and never twice for the same problem. Silence from Pulse is the good outcome.

The cast: one role, played across many jobs

A character carries its role from one scenario to the next. Scout audits your store today and researches your AI visibility tomorrow; it is the same Scout role doing the gathering in both. This is where role is fixed, character is not earns its keep: a familiar cast across every workflow, and an audit trail that does not care what you named them.

Here is who plays what, and where. A lock marks scenarios in the paid Vortex IQ plans.

• Beacon plays Lead. Appears in Audit and findings, Store migration 🔒.
• Scout plays Scout. Appears in Audit and findings, SEO and AI visibility 🔒.
• Iris plays Analyst. Appears in SEO and AI visibility 🔒, Ask Viq 🔒, Insight reports 🔒, Live monitoring, Ad spend 🔒.
• Forge plays Maker. Appears in Fixes, SEO and AI visibility 🔒, Ad spend 🔒.
• Kai plays Runner. Appears in Fixes, Ask Viq 🔒, Store migration 🔒, Live monitoring.
• Lens plays Checker. Appears in Audit and findings, Store migration 🔒.
• Memo plays Reporter. Appears in Audit and findings, Fixes, Ask Viq 🔒, Insight reports 🔒, Memory.
• Pulse plays Pulse. Appears in Insight reports 🔒, Live monitoring, Ad spend 🔒.

Why this is the safe way to run agents on a live store

Put the boundaries side by side and a single rule falls out of them: no role both makes a change and blesses it.

• Scout gathers but cannot write.
• Iris calculates but through the engine, not by feel.
• Forge proposes but cannot apply.
• Lens reviews but cannot edit.
• Kai applies but only what you approved, and can always undo it.
• Memo reports but only what actually happened.
• Beacon directs but never touches a tool.
• Pulse watches but stays quiet unless a human decision is needed.

That is what "agentic" should mean on a store you actually depend on: not one model trusted with everything, but a crew of narrow specialists, a person on the approval line for anything that writes, and a record that names the role behind every step. Detect. Explain. Fix. In that order, with a boundary between each one.

How this fits the rest of Vortex IQ

The crew is the Vortex Agents layer, and it works alongside the rest of the AI Operating System: Nerve Centre watching your store and connectors in real time, Vortex Mind explaining what it finds, and Vortex Apps staging every change as a diff you approve and can reverse. So a silent failure reaches you before it reaches a customer, and nothing touches your store without a person on the approval line.

Eight roles, eight boundaries, and one honest record of what each of them did while you were away. That is the shape of agentic operations we think a store can actually trust.

Vortex IQ is the AI Operating System for e-commerce. See how it works at vortexiq.ai.