The five-stage pipeline
Stage 1, prompt
The merchant types a description of what the app should do. Examples that work well:- “Every Tuesday at 9am, summarise last week’s Shopify sales by SKU and post the top 10 to the #ops Slack channel.”
- “When a customer’s third order ships, send them a 15% off code from Klaviyo.”
- “When checkout conversion drops 10% week over week on BigCommerce, open a Jira ticket assigned to the engineering lead.”
- “Make me a sales report.” (too vague: which platform, which period, which metrics, where to send it)
- “Help with abandoned carts.” (which signal triggers it, which channel, what message, what discount)
Stage 2, plan
The agent generates a structured plan from the prompt. The plan has six parts:| Plan part | What it captures |
|---|---|
| Trigger | What starts the app: a schedule, a webhook, a Vortex Mind finding, a Nerve Centre threshold, a manual run. |
| Data sources | Which connected sources the app needs to read from (Shopify orders, BigCommerce products, Google Analytics sessions, Datadog metrics, Vortex Mind reports). |
| Logic | The conditional, computational, or filtering logic the agent will apply to the data. |
| Output | What the app produces: a Slack message, an email, a Jira ticket, a webhook call, a CSV export, an Ask Viq summary. |
| Schedule | When and how often the app runs. |
| Approval gates | Whether each run needs human approval before sending output, or runs autonomously. |
Stage 3, tools
Once the plan is approved, the agent picks the specific tools it needs from the App Builder toolkit. Tools fall into three buckets:- Read tools. Connector adapters that fetch data from any source connected to Nerve Centre. The agent has read access to the same data layer that powers the dashboard. See Tools and integrations for the full read surface.
- Write tools. Notification channels (Slack, Microsoft Teams, email, SMS via Twilio), ticket systems (Jira, Linear, internal Kanban via Actions), platform-level write actions (post a Shopify product update, change a BigCommerce price, route an order in CloudHub).
- Reasoning tools. Ask Viq for plain-English Q&A on the merchant’s data, Vortex Mind report runners for triggering or pulling diagnostic findings, Vortex Memory for retrieving past run output.
Stage 4, sandbox
The approved app deploys to a sandbox runtime. The sandbox is functionally identical to production: same code, same tools, same credentials. The difference is that sandbox runs route their write actions to a safe channel by default. A Slack message goes to a sandbox channel, an email goes to the merchant’s inbox, a Jira ticket goes to a sandbox project. This lets the merchant verify the actual output without polluting production systems. The merchant runs a test execution from the sandbox view. The output renders inline. If the output is wrong, the merchant goes back to the prompt or plan stage and edits. If the output is right, the merchant promotes the app to production.Stage 5, production
The promoted app runs on its scheduled trigger or live event. Each run is logged to Vortex Memory with the input data, the agent’s reasoning trace, the tool calls it made, and the output it produced. Production runs are visible in Deployment and monitoring, where the merchant can pause the app, edit it, view error history, and roll back to a previous version.The agent under the hood
App Builder agents are built on the same agent framework that powered V1 Agent Hub agents (the framework that runs ConnectorAgent, AskVIQ, Google Ads Performance Agent, and the rest of the legacy catalogue). The framework provides:- Tool calling. The agent picks tools from a registered toolkit and calls them with structured arguments.
- Sub-agent delegation. Complex apps can break themselves into sub-agents (an “ask Ask Viq” sub-agent, a “post to Slack” sub-agent, a “filter the result” sub-agent), each with its own scoped toolkit.
- Reasoning traces. Every decision the agent makes is logged so the merchant can see why the agent chose a particular tool or wrote a particular query.
- Approval gates. Tool calls that have side effects (write actions) can be marked as gated, requiring human approval per run.
| Capability | V1 Agent Hub | V2 App Builder |
|---|---|---|
| Discoverability | Browse a catalogue of pre-built agents | Describe what you want; agent assembles it |
| Customisation | Limited; engineering required for changes | Plain-English edits at any stage |
| Tool availability | Per-agent fixed toolkit | Full toolkit available to every agent, agent picks |
| Cross-platform | Each recipe was platform-bound | Apps span multiple platforms natively |
| Schedule | Manual run in most cases | Scheduled, event-triggered, or on-demand |
| Sandbox | Not first-class | First-class staging surface before production |
| Deployment surface | Run from the catalogue UI | Owned, editable production app |
The architectural shift, in one paragraph
V1 Agent Hub asked: “what pre-built agent do you want?” The catalogue dictated what was possible. The merchant was a consumer of the catalogue. V2 App Builder asks: “what do you want your app to do?” The merchant is the author. The agent is the implementer. The toolkit is the universe of possible actions, not a list of fixed recipes. This is the AI OS pattern at work: the platform is no longer a fixed feature set; it is an operating system on which the merchant can build.Cross-links
- Walk through a full build with the worked example on Building an app.
- See the full toolkit on Tools and integrations.
- Understand the post-deploy surface on Deployment and monitoring.
- Browse the legacy starter recipes on Recipes and FAQs.