Skip to main content
RUN IT WELL

​
A good client outcome is a routine, not a rescue.

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.

The shape of it

​
Six stages, in order.

Each stage leans on one specific part of Actionist. Skip one and the next stage gets harder, not impossible, just harder.

DiscoverQuestions that map onto the five groups you’ll actually build.
Set upBuild each agent’s five groups in the Agent Onboarding studio.
TestDry run every trigger, run every schedule once, before you confirm.
Hand overShow Needs attention, a run record, and the approval mode control.
TrainWalk their team through what each agent can do alone, and can’t.
Check inRead the metrics tab and the Needs attention list. Nothing arrives on its own.
Discover. The five questions you ask map directly onto the five groups in the studio, nothing you learn goes to waste later.
Set up. Confirming an agent turns its schedules and triggers on the same instant. Confirm last, never first.
Test. There is no whole-agent test mode. A trigger’s dry run and a schedule’s Run now are the only two checks you get.
Hand over. Nothing in the product records what you changed. If you don’t tell the client, nobody will.
Train. A client can revoke any permission the moment training ends, without telling you first.
Check in. The metrics view moved into Billing. There is no digest email sitting there to remind you it exists.
Before discovery

​
Making the case to a business.

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.
Before you open the studio

​
Discovery that produces a build.

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.

  • 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?
  • 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?
  • 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?
  • 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?
  • 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.
The most useful thing on this page

​
Walking the Agent Onboarding studio.

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.

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.

Set once, per agent

​
Choosing an approval mode.

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.

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.
Before you confirm

​
Testing before it is real.

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.

Before you exit for the last time

​
Handover and training.

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.
Leave something behind

​
What goes in a handover note.

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.
After the handover

​
Check-ins that are worth having.

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.
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.
Run it well

​
Nothing here is a guess.

Discovery that maps to the studio, a checklist that actually blocks confirming, and check-ins that only cover what the product really tracks.

Open the DashboardSignup as a Partner

Anchored to the product, not a template.
Five groups per agent · one checklist that blocks confirming · six measures in Billing.

Keep going

​
Next steps.

Onboarding a new client

The full path from invitation to a live workspace, including the six-step handoff checklist.

Delegate the work, keep the wheel

Approval modes, blockers, and how Actionist keeps a human in the loop on unattended runs.

Troubleshooting

Every message you can hit in a session or a setup, what it means, and whose problem it is.

Client permissions and access

The eight toggles behind every lock you’ll meet, and what each one opens.