Agent Workflows
The Virtual Environment
The Virtual Environment is the visual canvas where agent workflows are built. You reach it from Agent Suite in the sidebar, which opens the canvas inside En Garde with the normal navigation around it. The flow itself is drawn as nodes connected by edges, and the whole chain is editable in one place instead of being spread across separate tools.
Brand Space scoping
You do not sign into the canvas separately. En Garde signs you in for you, using a session that names three things: the tenant, the workspace, and the brand you currently have selected. That context is what makes the environment scoped — a flow you build while one Brand Space is selected belongs to that context rather than to your login generally. The session is short-lived and refreshed automatically while you work, so a long editing session does not drop you out.
Switching Brand Space switches the canvas context too. If you manage several brands or clients, confirm which one is selected in the header before you start building — that is the single most common source of a flow ending up on the wrong brand.
How a flow is put together
A workflow is a graph. Each node does one thing, and each edge passes the result of one node into the next. In practice the nodes in a marketing workflow fall into a few roles:
- An input or trigger — what starts the run and what it starts with.
- Conditions — checks against audience or campaign state that decide whether and how the flow continues.
- Work — the model calls and transformations that generate or evaluate something.
- Actions — writing back out, such as syncing a profile to a connected tool or producing a content asset for review.
Flows are saved with a name, a description, and the node and edge count, and appear in your agent list once saved. Building and editing happens on the canvas itself — the surrounding En Garde screens list, trigger, configure, and monitor flows rather than editing their contents.
Starting from a template
An empty canvas is rarely the fastest start. Workflow Templates lists pre-built automations you can search by name or description, each showing its category, how many steps it has, and how often it has been used. Choosing Use Template opens the builder pre-populated with that template, ready to adapt. The agent gallery is the other source: browse shared agents by category, sort by popular, top rated, newest, or most cloned, and clone one into your own brand.
Testing and running
A flow can be exercised three ways, and they are worth using in this order:
- Run it on the canvas with a sample input while you are still building, so you can see the output of each step before anything reaches a live tool.
- Trigger it from My Agents. Each agent card has a Trigger Agent button that starts a run on demand — the safest way to confirm the deployed version behaves like the one you tested.
- Let it fire itself once you trust it, on a schedule or from a configured trigger.
Configuring a deployed agent
Configure on an agent card opens its configuration screen, which has four tabs:
- Configuration — the agent's own settings, presented as a form. Some agents need none, in which case the tab says so.
- API Keys — credentials the agent needs, each showing its name, a key prefix, when it was last validated, and whether it is currently valid.
- Schedule — whether the agent runs on a schedule, and whether that schedule is enabled or disabled.
- Triggers — the events that start it.
When something goes wrong
Two screens answer most questions. Activity is the real-time log of workflow executions and events, newest first, each with a status. The Executions monitor covers runs in more detail: status (pending, running, paused, completed, failed, or cancelled), progress, how many steps completed, failed, or were skipped, start and end time, total duration, and the error message when there is one. Start with Activity to find the run, then open the execution to see which step failed.
What the boundary actually is
“Virtual environment” is not only a description of the canvas. It is also the boundary the work runs inside. A flow you build while one Brand Space is selected is not a route into another brand's data. Three things hold that line:
- The session that opens the canvas. En Garde issues a short-lived token naming the tenant, workspace, and brand you are in, and refreshes it while you work. Switching Brand Space re-issues that token for the new context rather than widening the old one — the canvas is reloaded against the new context, not handed a bigger one.
- The tenant on the request, not in the request. When a screen or a running flow asks the platform for data, the tenant is taken from your authenticated session. It is not read from a parameter the caller supplies, so it is not something that can be swapped by editing a request. Where a request arrives without a resolvable tenant, it is refused rather than falling back to an unscoped read.
- The workflows themselves. Each deployed workflow instance is registered against the tenant that created it, and the tenant's own list of instances is what the platform enumerates and applies limits against. A flow belongs to a context in the same way its data does.
The practical version: check the brand in the header before you build, because that selection decides both where the flow lives and what it is able to see.
What is recorded when an agent runs
A run is not a black box you have to take on trust. Three separate records are kept, and each has a screen behind it:
- The run itself. Activity and the Executions monitor, described above, hold the per-run history: status, progress, which steps completed, failed, or were skipped, timings, and the error text when a step fails.
- How the agent is performing over time. Analytics under Agent Workflows covers a window you choose. Per agent, that is execution count, success rate and duration, how many suggestions it generated and how many of those were approved or rejected, quality and confidence scores, and a day-by-day breakdown. There is also an aggregate view across every agent in the tenant, and both can be exported as JSON or CSV.
- The audit trail. Audit Logs under System is the forensic record: who did what, to which resource, and whether it succeeded, failed, or was denied. It can be filtered by user, action, resource type or specific resource, result, date range, severity, and risk score, and exported. Agent Inbox activity is tagged so it can be pulled out on its own.
Audit access is deliberately narrower than the rest. Reading the trail requires a team lead or workspace admin role, and the query is still scoped to your tenant — an audit log is evidence, so who can read it is itself a control.
Making an agent stop and ask
An agent does not have to auto-execute everything it decides to do. A workflow can be built so that a consequential step raises an approval request and waits, instead of acting. The approval workflow templates do this with a risk classification step feeding a router, so the request goes to the right level of reviewer rather than to whoever happens to be watching.
Requests surface in the Agent Inbox, and carry the detail a reviewer needs to decide:
- What is being asked, with estimated cost and reach where those apply.
- A risk level of low, medium, high, or critical, which sets how long the request has before it breaches its deadline and how quickly it escalates if nobody acts.
- Approve with optional comments, or reject with a reason — the reason goes back to the requesting agent rather than being discarded.
- Every decision is written to the audit trail with the approver on it.
There is a blunter control as well. A deployed agent can be paused, resumed, or archived from its registry entry, which is what you want when something is behaving oddly and you would rather stop it than debug it live.
Why this matters for customer-data insights
Pointing a model at your own customer data is a different proposition from prompting it in a blank window. The value is obvious — the objection is that you are handing real records to something that acts on its own. That objection is answerable in three parts, and they are the three sections above.
The run is scoped, so a flow reasons over one brand's data rather than everything the platform holds. The run is recorded, so a question asked weeks later — what did this agent do on that campaign, and what did it see — has an answer you can pull up rather than reconstruct. And the steps that reach a customer or spend money can be made to wait for a person, so autonomy is something you extend deliberately, step by step, instead of granting up front.
A sensible way to adopt this: start with everything consequential behind an approval, watch the analytics and the audit trail for a few weeks, and relax the gates only on the specific actions the record shows the agent gets right.
Next: Agent Inbox for what happens when a workflow needs a human, or back to Agent Workflows.