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](/resellers/permissions). 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.

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." 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." 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. Agent Instructions, Skills, Channels, Advanced, Apps, in that order, for every agent on the roster. The Apps group reports its own readiness: "{'{{done}}'} of {'{{total}}'} connected", warning "Each app still needs connecting before {'{{agent}}'} can use it without you." until it reads "Every app {'{{agent}}'} needs is connected." "Confirm this agent" carries a real warning: "Confirming turns {'{{agent}}'} on and enables its schedules and triggers at the same moment." Roster progress reads "{'{{done}}'} of {'{{total}}'} 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 "{'{{done}}'} of {'{{total}}'} 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.

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.

| 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](/Folders/oversight).

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.

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. **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.

| 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.

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 Dashboard Signup 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.

The full path from invitation to a live workspace, including the six-step handoff checklist. Approval modes, blockers, and how Actionist keeps a human in the loop on unattended runs. Every message you can hit in a session or a setup, what it means, and whose problem it is. The eight toggles behind every lock you'll meet, and what each one opens.

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

Six stages, in order.

Making the case to a business.

Discovery that produces a build.

Walking the Agent Onboarding studio.

Choosing an approval mode.

Testing before it is real.

Handover and training.

What goes in a handover note.

Check-ins that are worth having.

Nothing here is a guess.

Next steps.