Discovery, setup, testing, handover, training and check-ins, each step anchored to something Actionist actually does, not a generic agency playbook. Every recommendation on this page names the exact screen, button or copy it depends on.
Two arguments do most of the work in a first conversation, and they are the two a business objects to first: what it costs, and whether they can trust you inside their systems.
The cost argument
The average US worker costs a business about $66,622 a year, per SoFi. A dozen staff is over a million in payroll.
An agent takes real work off that team, or lets the same people cover far more, for a fraction of one salary.
Anchor on a specific task the business already pays someone to do, not on the software. “This is the four hours a week your ops person spends on invoices” lands harder than a feature list.
The trust argument
You never see their passwords, API keys or tokens. That is enforced on the server, not promised in a contract.
They choose exactly which parts of their workspace you can reach, toggle by toggle, and can change it at any moment without asking you.
Show them the Manage Reseller panel early. Handing someone the off switch up front is usually what makes them comfortable turning things on.
The strongest version of the trust argument is a demonstration rather than a sentence. Walk a prospective client through the eight permissions and the credentials hard limit before they ask, and you convert a worry they were about to raise into a reason to say yes. See Client permissions and access.
Do not promise a specific saving, a payback period, or an income figure on the client’s behalf. You have no verified benchmark to quote and the product does not produce one. Talk about the work an agent will take on, and let the client apply their own numbers to it.
Every agent the client works through in the Agent Onboarding studio breaks into the same five groups: Agent Instructions, Skills, Channels, Advanced, and Apps. Ask your discovery questions in that shape and the answers drop straight into the build, instead of sitting in a notes doc you translate later.
Agent Instructions: identity, remit and team
Which named task or decision does this agent take on, and what is explicitly outside its remit?
Whose voice should it write in, and is there a house style doc or set of past emails to point it at?
Which of the client’s team members should this agent be shown as working for, so its remit reads correctly the first time they open it?
Is there a decision this agent should never make on its own, regardless of how it’s configured elsewhere?
Skills: manual tasks, schedules and triggers
Which of this agent’s jobs should run itself on a clock, and how often, daily, hourly, a fixed time each week?
Which jobs should only ever run because someone asked in chat?
Is there an inbound event, a payment, a support ticket, a form submission, that should wake this agent instead of a schedule?
If a trigger fires on a payload field that isn’t always present, what should happen instead of the agent guessing?
Channels: where this agent talks to the team
Where does this agent’s output actually need to land, a specific Slack channel, Telegram, or nowhere, silent and logged only?
Who should see its day-to-day output, and who should only be told when something goes wrong?
If “silent” is the answer, is that a deliberate choice or does no one know a channel option exists?
Advanced: delegation, access control and approval mode
How much should this agent do without asking, in its first week? Is that answer different by month two?
Is there an irreversible action, a payment, a delete, a message sent outside the organization, this agent should never take without a human confirming, no matter the approval mode?
Should this agent be able to delegate to others, or does that wait until the client trusts it more?
Apps: connecting the tools this agent uses
Which of these connections need the client’s own login, and have you named them individually rather than describing them abstractly?
Does the client already use one of these apps under a different account than the one they’ll connect here?
Which connections does this agent share with other agents, so one broken connection affects more than a single workspace?
Five questions per agent is deliberate, not five for the sake of it. Each group in the studio only accepts input in its own shape, an Advanced answer never helps you fill in Channels, so an answer that doesn’t map to one of the five groups usually means the question was aimed at the wrong stage of the conversation.
This is the studio your client runs, and the one you can pick up from mid-way through inside a delegated session. Knowing its exact shape means you never guess what comes next.
Open the studio
A re-entry teaser reads “Set up your agents”, with “Answer a few questions about your business and Actionist proposes the agents to build.” One button, Start, opens Agent onboarding itself: “Review the company memory every agent reads, then work through your agents one at a time.”
Watch the workspace come online
The workspace provisions in the background across three states, Preparing, Ready, and Needs attention. The timing copy is deliberately calm: “Usually ready in two to three minutes. You can keep working while it starts.” If it stalls: “Agent setup carries on. Anything that needs the workspace waits until it is back.”
Read Company Overview
Before touching any single agent, the client sees the memory files every agent reads from. This is the shared context behind “what does it actually know about us”, worth pointing a curious client to directly.
Work the five groups per agent
Agent Instructions, Skills, Channels, Advanced, Apps, in that order, for every agent on the roster. The Apps group reports its own readiness: ” of connected”, warning “Each app still needs connecting before can use it without you.” until it reads “Every app needs is connected.”
Confirm each agent
“Confirm this agent” carries a real warning: “Confirming turns on and enables its schedules and triggers at the same moment.” Roster progress reads ” of agents confirmed”, ending in “Every agent is live.”
Confirming is a one-way switch for schedules and triggers, so the studio itself blocks it until a specific set of conditions clears. This is the checklist worth memorizing, because it is also the shortest path to diagnosing why a client’s agent won’t go live.
What blocks confirming
What’s actually stuck
Who resolves it
An open blocking issue
A blocker tied to this agent or one of its triggers hasn’t cleared
Usually you. Agent- and trigger-scoped blockers clear on the next successful run once the cause is fixed
Incomplete app connections
Not every app the agent needs shows connected, this is the ” of connected” count
The client only. Completing a connection always needs their credentials or their OAuth
The workspace still Preparing or on Needs attention
Provisioning hasn’t finished, usually two to three minutes
Nobody. Wait it out. If it sits on Needs attention, treat it as a support case
A relied-on connection unhealthy
An app connection this agent shares with others has gone bad, an expired token or revoked access
The client. Reconnecting an app is their action even inside a delegated session
A duplicate trigger
Two triggers on this agent are configured to fire on the same thing
You, from inside the Skills group. Remove or rename one
Incomplete trigger configuration
A required field is missing, often the same one a dry run already flagged as referenced but absent
You. Finish the field before confirming
A final cross-agent check still running
A last validation pass across the whole roster hasn’t finished yet
Nobody. It clears itself in moments
Run this table top to bottom before you tell a client “it’s ready.” Four of the seven rows are yours to fix, one is the client’s, and two just need a moment.
Workspace provisioning and your own management access clear on two separate clocks. A client’s workspace can already be Ready while your delegated session is still finishing its own sync, or the other way round. Don’t read one as a proxy for the other, check each state directly rather than assuming.
Every agent has one approval mode, set on its Tools tab under Advanced, and it applies to all of that agent’s tools, including Skills and MCP servers. Four modes exist, ordered from most hands-on to most autonomous.
Mode
Exact description
Suggest
Propose tool calls; user runs them manually.
Ask each time
Require approval before every tool execution.
Guarded auto
Run safe tools automatically, ask for risky ones.
Full auto
Runs automatically, but asks before irreversible actions such as deleting or overwriting files, making payments, or sending messages outside your organization.
Start a nervous client on Ask each time or Guarded auto. Either one lets them watch the agent work without a single unsupervised action, and both still let it move at a reasonable pace once the risky calls are the only ones that pause. Guarded auto is the sensible everyday default once a client has seen a week or two of an agent’s decisions and stopped double-checking every one. Loosen to Full auto only for a routine you’ve watched succeed repeatedly, and only for an agent whose irreversible actions, payments, deletes, external messages, you’re comfortable it will still pause on.
Approval mode is agent-wide, not per-tool by default, though individual tools can be overridden stricter or looser underneath it. Full detail on how modes interact with unattended runs and blockers lives on Delegate the work, keep the wheel.
Actionist gives you exactly two real checks, one for triggers and one for schedules. Neither is a substitute for the other, and there is no third check that exercises a whole agent end to end.
A trigger's dry run
Paste a sample payload into Preview with sample payload and Actionist hands back the rendered instruction and whether the filter passed, with no database write and no model call. It also tells you whether the agent would actually receive the dispatch, and flags any payload field your instruction references that the sample doesn’t actually contain.
A schedule's Run now
Run now is not a preview. It is a real, live run: the agent executes, the result lands in Agent Studio → Runs exactly like a scheduled firing would, and anything the agent is set up to do, it does. Use it once you’re ready for the run to count.
There is no whole-agent test mode. Nothing in Actionist simulates an entire agent, chat included, end to end without it actually running. Test each trigger with its dry run, run each schedule once with Run now, and treat any first real chat message the same way, watched, on a cautious approval mode, not assumed safe because the pieces tested clean individually.
The two checks catch different failures. A dry run tells you the trigger is wired correctly, the filter passes, the instruction renders, every field your task description references actually exists in a real payload. It cannot tell you what the agent does with that instruction, because no model call happens. Run now is the opposite: it proves what the agent actually does, but only for the one execution you watched, not for every payload shape it will meet later. Use both, for the reasons each one is actually good for.
Handover is not a document, it’s a short walkthrough inside the workspace itself, done once with the client watching, so the four things they’ll need are things they’ve already clicked once themselves.
Show them Needs attention
It lives on their Home tab. Walk them through reading one card: what’s stuck, why, and the exact fix action written in plain language. This is the one screen they’ll check without you.
Show them how to read a run
Open Agent Studio → Runs together. Point out the source (manual, schedule, trigger), status, timings, the output summary, any files written, token usage, tool calls, and the error class on a failed run.
Show them the approval mode control
On the agent’s Tools tab. They should be able to tighten it themselves the moment something makes them uneasy, without waiting for you to be online.
Show them how to revoke you
Any toggle in their Manage Reseller panel can be turned off at any time, without telling you first. Say this plainly during training rather than letting them discover it mid-project.
A short written note, sent after the walkthrough, should cover:
Which agents are live and what each one actually does day to day.
Which apps are still unconnected under whose name, taken straight from the Apps group readiness count.
Each agent’s approval mode and the reasoning behind starting it there.
Anything you changed this session, agent by agent, dated.
Actionist keeps no client-visible record of what a reseller changed inside a delegated session. That last item on the list is not optional. If you don’t say what you changed, the client has no other way to find out.
Three real surfaces exist to check on: a metrics view, the Needs attention list, and any schedule you set up yourself. There is no fourth surface that gathers all of it and emails it to you.
The metrics view is not a top-level navigation item anymore. It now lives inside Billing, under a Value delivered tab. If you’re used to finding it elsewhere, that’s where it moved.
Once you’re there, it reports six measures: estimated time saved, tasks completed, actions taken, automated runs, success rate, and how many agents contributed, plus a per-agent leaderboard and a week-over-week trend. It only counts automated agent work, a schedule or a trigger firing, not manual chat use, so it undercounts a client who mostly talks to their agents directly.
Metrics, in Billing → Value delivered. Six measures, a leaderboard, a week-over-week trend, automated work only.
Needs attention, on Home. The list you already trained the client to read is also the one you should be reading.
A scheduled agent, of your own making. Point one of the client’s agents at a recurring task, “summarize this week’s automated runs and any open items,” and let it post into a Channel. Actionist ships none of this automatically; you build it if you want it.
What to review monthly
Where
Estimated time saved, tasks completed, actions taken, trend
Billing → Value delivered
Which agents contributed the least, and why
The leaderboard, same tab
Anything sitting on Needs attention longer than a few days
Home
Whether an approval mode still matches how much the client trusts the agent
The agent’s Tools tab
Whether every app connection is still healthy
The Apps group inside that agent’s setup
There is no automated weekly digest and no report email. Everything above is something you open and read, or an agent you scheduled yourself to summarize it. If a client expects a report to arrive on its own, that expectation needs correcting during handover, not discovered during a check-in.
The leaderboard is a per-agent view, not a per-client one. On a multi-agent workspace it’s the fastest way to spot an agent that’s confirmed and connected but never actually doing anything, worth a look before a client asks why one of their agents seems quiet.
