Your First AI Agent: A 30-Minute Onboarding Checklist

Most people who abandon AI agents abandon them in the first hour. Not because the technology failed, but because they started with a job that was too big, gave the agent too much freedom, and never learned to read what it actually did. The fix is a boring one: a checklist.

This guide walks through a complete AI agent setup in roughly 30 minutes, using Skopx's Create Agent workspace as the concrete example. The sequence is deliberate: connect your tools first, describe one narrow job, set the trigger to manual, run it while you watch, read the step timeline, then decide what to approve and what to tighten. Every step exists because skipping it causes a specific, predictable failure later.

You do not need to write code. On Skopx you build agents by describing them in chat, and the chat assembles the agent for you: instructions, trigger, tool grants, budgets, and success criteria. If you want the deeper conceptual background first, read what an autonomous AI agent actually is. If you are ready to build, keep going.

Minute 0 to 5: Connect the tools the job actually needs

Before you describe any agent, connect the accounts it will touch. An agent without tool access is a chatbot with opinions. An agent with the wrong tool access is a liability.

The rule for a first agent: connect the minimum set of integrations for one job. If your first agent summarizes your inbox, connect Gmail and nothing else. If it watches a Slack channel, connect Slack. Skopx supports nearly 1,000 integrations through its Composio-backed catalog, including Gmail, Slack, Notion, HubSpot, Salesforce, Google Sheets, GitHub, Linear, Jira, Stripe, and Shopify, plus read-only SQL access to connected databases like Postgres and MongoDB. You can browse the full list on the integrations page.

Resist the urge to connect everything now. Two reasons:

1. Grants are per toolkit. Every integration an agent can use is a separate grant with its own permission tier. Fewer connections means fewer decisions and a smaller surface for surprises.
2. You will read this agent's runs closely for the first week. Every extra tool is another category of step you have to evaluate. Keep the first run legible.

Connected credentials on Skopx are encrypted, and there are security controls in place around how agents receive access. But the strongest control is the one you exercise yourself: only grant what the job requires.

Checklist for this step:

• One job chosen, written down in one sentence
• Only the integrations that job needs are connected
• Credentials verified (open the integration, confirm it authenticates)

Minute 5 to 12: Describe the job in plain language

Open the Create Agent workspace at skopx.com/dashboard/create-agent and describe the job in chat, the way you would brief a careful new hire. No canvas, no flowchart. The chat turns your description into the agent's instructions, which stay editable and versioned afterward.

What makes a good first description? Specificity about inputs, outputs, and judgment calls. Compare:

"Monitor my email and handle important stuff."

versus:

"Every time I run you, look at unread emails from the last 24 hours in my Gmail. Group them into: needs a reply from me, FYI only, and newsletters. For anything that needs a reply, draft a short response in my voice but do not send it. End with a summary I can read in two minutes."

The second version tells the agent what to read, how to categorize, what action to take (draft, not send), and what the deliverable looks like. Vague instructions do not make agents creative; they make agents unpredictable. There is a full guide to writing agent instructions that hold up if you want to go deeper, but for onboarding, three principles carry most of the weight:

• Name the boundaries. "Draft but never send." "Read the CRM, never modify it." "Only look at the #support channel."
• Describe the output. Agents on Skopx end every run with a markdown report. Tell the agent what that report should contain and you will get consistent, skimmable results.
• State what to do when unsure. "If you cannot classify an email confidently, put it in a 'not sure' section rather than guessing."

While you are describing the job, the chat will also assemble success criteria: conditions the run report is evaluated against. For the inbox example, a success criterion might be "every unread email from the window is accounted for in exactly one category." Success criteria matter because they turn "the run finished" into "the run did the job." You can refine them later; just make sure your first agent has at least one that is checkable.

Checklist for this step:

• Instructions name the data sources explicitly
• Instructions state what the agent must NOT do
• The expected report format is described
• At least one checkable success criterion exists

Minute 12 to 15: Set the trigger to manual (yes, even if you want a schedule)

Skopx agents support three trigger types, and your first agent should use the first one regardless of your end goal:

The reason to start manual is simple: you want to be watching the first several runs. A scheduled agent that misbehaves does so at 9:00 UTC while you are asleep. A manual agent misbehaves in front of you, once, and you fix it.

Once the agent has produced three or four runs you are happy with, switching the trigger is a one-line request in chat. If the destination is a Monday-morning digest, the guide to scheduled AI agents covers cadence choices and the failure modes specific to unattended runs. If you are heading toward event-driven automation, note that Skopx treats webhook payloads as untrusted data by design, which is one of several reasons webhook agents deserve their own hardening pass before launch.

Checklist for this step:

• Trigger set to manual for now
• The eventual trigger (schedule or webhook) written down for later

Minute 15 to 18: Set grants and budgets before the first run

This is the step people skip, and it is the step that determines whether your first surprise is a minor annoyance or a real problem.

Grants control what each connected toolkit is allowed to do, per agent. Skopx gives you tiers per integration:

• Runs automatically: the agent uses the tool without asking. Appropriate for reads on a first agent, and for writes only after you trust the agent.
• Asks first every time: every write-shaped action parks as a pending approval showing the exact call and its arguments. You approve it and exactly that parked call executes once, or you reject it and nothing executes.
• Agent decides when to ask: the agent escalates the actions it judges risky. Useful later; too much delegation for day one.
• Drafts-only mode: the agent can prepare content but never send or publish it.

For a first agent, the default posture is: reads run automatically, every write asks first. Under approval_required, reads still flow without interruption, so the agent can do its research; only actions that change something in your tools stop for you. This is the pattern explored at length in AI agents with human approval, and it is the single most effective safety habit for new agent builders.

Budgets are the other half. Every Skopx agent carries hard limits: tokens per run, tokens per day, a maximum step count, and a minute cap. If an agent hits budget failures three times, it auto-pauses. Set these tighter than feels necessary. A first agent doing an inbox summary does not need hundreds of steps; if it uses them, something is wrong, and you want the budget to catch that rather than your patience.

You also pick the model here. Skopx lets you choose per agent among Claude, GPT, Gemini, Kimi, and others, either through your own API keys across 8 providers with zero markup, or on the $16 per seat Team plan with included tokens. For a first agent, pick one capable model and do not overthink it; you can change it later without rebuilding anything.

Checklist for this step:

• Every write-capable toolkit set to "asks first every time" or drafts-only
• Token, step, and time budgets set conservatively
• Model chosen

Minute 18 to 22: Run it manually and watch

Now run the agent. On Skopx, every run produces a live step timeline: each action gets a humanized label ("Searched Gmail for unread messages," "Fetched 14 results"), and every step can be expanded to show the raw result underneath. The run also tracks duration and token count as it goes.

Watch the first run end to end. You are looking for four things:

1. Did it read the right sources? If you said "last 24 hours" and it pulled a week, the instructions need tightening.
2. Did it take a sensible path? An agent that loops, retries the same call, or wanders into tools it does not need is telling you the instructions are ambiguous.
3. Did any write-shaped action park for approval? If you set grants correctly, it should. Open the pending approval and read the exact call and arguments. This is the moment the whole permission model earns its keep: you see precisely what would happen before it happens.
4. Does the report answer the brief? Every run ends in a markdown report rendered as a document. If the report is vague, your output description was vague.

If something goes visibly wrong mid-run, stop it. Runs can be stopped mid-flight, and pausing the agent acts as a kill switch for anything queued behind it. There is no penalty for stopping a bad run early; the run history is append-only, so the record of what happened stays available for you to learn from.

Checklist for this step:

• First run completed or deliberately stopped
• Timeline read step by step, at least one raw result expanded
• Pending approvals inspected (exact call and arguments read, not skimmed)
• Report compared against the one-sentence job description

Minute 22 to 27: Approve, reject, and tighten

The first run gives you material. Now act on it.

On approvals: approve the parked actions that are exactly right. Reject anything that is close but not quite; rejecting executes nothing, and you lose nothing by being strict. Note that approvals can expire, so do not treat the pending queue as a to-do list for next week. The discipline you want to build: never approve an action whose arguments you have not read.

On instructions: go back to chat and fix what the run revealed. "You included promotional emails in 'needs a reply'; treat anything from a no-reply address as newsletter." Instructions are versioned, so you can see what changed between runs and roll your thinking forward deliberately rather than by accumulation of vibes.

On grants: if a tool never got used, consider removing the grant. If a write action parked five times and you approved all five identical calls, that specific action might be a candidate for automatic execution eventually, but not yet. Loosen grants only after a pattern of correct behavior, and loosen them one tier at a time.

On budgets: if the run came in far under budget, leave the budgets where they are. Budgets are not targets; they are tripwires.

Run the agent manually two or three more times across this and the next day. Skopx agents carry memory between runs: cursors, baselines, and other state persist, so a second run typically produces a delta report ("3 new emails since last run") rather than re-processing everything, and is usually cheaper. Watching the memory behave correctly across runs is part of onboarding too; a first run and a second run are different tests.

Checklist for this step:

• Every pending approval explicitly approved or rejected
• Instructions revised based on the timeline, not on assumptions
• Unused grants removed
• Second run completed; delta behavior verified

Minute 27 to 30: Decide what "done onboarding" means

Onboarding ends when you can state, honestly, three things:

1. You can predict what the agent will do. Given a new run, you could sketch its step timeline in advance and be roughly right.
2. You know how to read a run. Timeline, expanded steps, token count, report, success criteria evaluation. If a run looks off, you know where to look. The companion guide on debugging agent runs covers the diagnostic side in detail.
3. The permission posture matches your trust level. Writes still ask first. You have not loosened anything you have not personally watched succeed repeatedly.

Only then switch the trigger to a schedule or webhook. And when you do, keep the approval requirement on writes for at least the first week of unattended runs. A scheduled agent whose write actions park for approval is still doing 90 percent of the work: the research, the drafting, the reporting all happen without you, and you spend thirty seconds a day approving the parts that touch the world.

What you should not do at minute 30: clone this agent five times for five other jobs. One agent, run well, teaches you more than five agents run carelessly. When you are ready to scale, the Skopx agents overview covers how the workspace handles multiple agents, with every agent visible in a rail beside the one you have open.

Common first-week mistakes, and what they cost

A short field guide to the ways first agents go sideways. All of these are avoidable with the checklist above; all of them are survivable if they happen anyway.

Starting with a schedule. The agent runs unattended before you have ever read one of its timelines. Cost: you discover instruction problems days late, through their accumulated output. Fix: manual trigger until you have read three good runs.

Granting write access on day one. "It is just my own Notion, what could go wrong" is how a page gets restructured in a way you did not want. Cost: cleanup, plus eroded trust in a tool that was doing what you told it. Fix: asks-first on every write until a pattern of correct parked calls exists.

Instructions that describe a mood instead of a job. "Keep an eye on customer sentiment" gives the agent nothing checkable. Cost: reports that sound plausible and mean little. Fix: name sources, boundaries, output format, and at least one success criterion.

Never expanding a raw result. The humanized labels are honest, but the raw results are the ground truth. Cost: you approve a pattern of behavior you never actually verified. Fix: expand at least one raw step per run during onboarding.

Skipping budgets because the job is small. Small jobs with ambiguous instructions can loop. Cost: wasted tokens and a longer timeline to read. Fix: conservative budgets; remember three budget failures auto-pause the agent, which is the system working as intended.

Treating a stopped run as a failure. Stopping mid-flight is a feature. Cost of the opposite belief: letting bad runs finish "to see what happens" while approvable actions pile up. Fix: stop early, read the partial timeline, revise, rerun.

One honest limit worth stating: no checklist makes an agent perfect on day one. Agents are probabilistic systems operating on messy real-world data. What the checklist does is make failures small, visible, and cheap while you converge on instructions that work. That convergence usually takes days, not minutes; the 30 minutes here buys you a safe starting position, not a finished system.

FAQ

How long does AI agent setup actually take?

The first working version takes about 30 minutes on a platform like Skopx, where you describe the agent in chat rather than building it in code or on a canvas. Getting the agent to the point where you trust it on a schedule usually takes a few days of manual runs, instruction revisions, and approval reviews. Budget the 30 minutes for setup and a week of light supervision for convergence.

Should my first agent be read-only?

Very close to it. Let reads run automatically and set every write-shaped action to ask first or to drafts-only mode. On Skopx, a parked approval shows you the exact call and arguments before anything executes, so the agent can still do write-shaped work, it just cannot complete it without you. Loosen this only after you have watched the same class of action park correctly several times.

What is a good first agent to build?

Something that reads, summarizes, and drafts, with one clear deliverable. Inbox triage, a competitor page summary, a weekly digest of a Slack channel, a report on new CRM leads. Bad first agents share a trait: they take irreversible actions (sending, publishing, deleting) or require judgment you have not encoded. The article on what AI agents can do has a broader menu of starter jobs.

What if the agent does something wrong during a run?

Stop the run; runs can be stopped mid-flight, and pausing the agent kills anything queued. If the wrong thing was a write, it likely never executed at all, because write actions under an asks-first grant park as pending approvals and rejecting one executes nothing. Then read the timeline to find where the run went off course, revise the instructions, and rerun manually. Run history is append-only, so the bad run stays available as evidence.

When should I switch from manual to a scheduled trigger?

After you can predict the agent's behavior: three or four consecutive manual runs where the timeline held no surprises, the report matched the brief, and the success criteria passed. Switch the trigger in chat, keep writes on asks-first for the first unattended week, and check the run history daily at the start. Memory persists between runs, so scheduled runs will typically be delta reports against what the agent already knows.

Do I need separate agents for separate jobs?

Eventually, usually yes: narrow agents are easier to instruct, budget, and debug than one agent with a sprawling mandate. But during onboarding, build one. The tradeoffs between a single broad agent and several narrow ones are covered in one agent vs many; the short version is that clear boundaries beat clever consolidation, especially while you are learning to read runs.