Your first AI agent workflow in Slab

Give an agent a small, useful job you can check: turn a product brief into a customer onboarding guide. This walkthrough connects the parts of Slab around one outcome. Docs holds the facts, Work holds the assignment, Runner executes the agent's turn, and Runs shows what happened.

You will use a fictional product and a supplied brief. The finished guide stays in your workspace for review. You do not need to connect a mailbox, a customer account, or an external data source.

Before you start

You need a running Slab workspace with Work, Docs, Runner and an AI runtime connected. If you are starting from a fresh server, follow the installation guide, then complete workspace and runtime setup. Model usage may incur charges from your chosen provider.

In Settings, check the Work and Docs connections and test Runner and your chosen runtime. A saved configuration is not enough: the connections must pass their checks before an agent can use them.

New to the names? Read The Product for a short explanation of each part of Slab.

1. Put the facts in Docs

Open Docs inside your Slab workspace and create a document called Harbor onboarding brief. Copy this fictional product information into it:

Product: Harbor
Audience: small teams organizing their first shared project.

To get started:
1. Create a workspace.
2. Invite one teammate.
3. Create a project and give it a name.
4. Add a task and assign an owner.

Permissions:
Only a workspace admin can invite teammates.
A task must belong to a project before it can be assigned.

Support:
If an invitation does not arrive, check the recipient address
and ask the workspace admin to send it again.

Do not claim:
Harbor has a free trial, supports a particular integration,
or guarantees a response time. Those details are not specified.

Keep the document's link or identifier handy. This is the source your agent should use. The exercise works best with a short, explicit brief: you can trace every claim in the output back to these facts.

2. Create an agent with a clear responsibility

Go to Agents → New agent. Name the agent Onboarding writer, choose a connected runtime and model, and enable the agent.

Use these instructions as a starting point:

You prepare customer onboarding material from approved company documents.
Read the source named in each assignment before writing.
Use only supported facts. Identify missing information instead of inventing it.
Write short, direct instructions for someone using the product for the first time.
Keep the result and any questions attached to the Work assignment.
Do not contact customers or publish outside the workspace.

These instructions describe the agent's ongoing role. The specific Harbor request belongs in Work, so you can change the next assignment without rewriting the agent's identity.

3. Choose what the agent can do

Open the agent's Capabilities tab and use a Custom tool policy. Give it the Work and Docs access needed for this exercise. Review the available tools by what they do:

Select the tools that match these operations in your installed version. Tool permissions and access to the underlying content both matter: an allowed read tool cannot retrieve a document outside the agent's authorized scope.

Ask is an execution permission. Writing “ask me first” in the prompt is not a replacement for setting the tool policy. Slab captures permissions for a run; policy changes apply to future runs, so save this setup before assigning the job.

Read more about agent tool policy.

4. Create the assignment in Work

Open Work, create a work item called Draft the Harbor onboarding guide, and assign it to your enabled Onboarding writer agent. Use the agent's exact assignee slug shown by Slab.

Paste this request into the work item, replacing the source placeholder with the link or identifier from step 1:

Prepare a first-use onboarding guide for Harbor.

Source: [paste the Harbor onboarding brief link or identifier here]

Deliver:
- A one-sentence introduction.
- Four numbered setup steps in the same order as the brief.
- A note explaining who can invite teammates.
- One troubleshooting tip for a missing invitation.
- A reference to the source document.

Keep the guide under 250 words. Use no facts beyond the brief.
Post the draft in a comment on this Work item and ask me to review it.
Do not mark the assignment complete before my review.
If the source or a required tool is unavailable, explain what is missing.

Assignment can start an agent run through Slab's Work coordination. Follow that run in Runs. Avoid creating another identical assignment while the first one is queued or working.

5. Review the run and its requested actions

Open the run associated with the assignment. Follow the source lookup, tool activity and proposed result. If the agent requests a Work write covered by your Ask policy, inspect the target item and proposed content before approving it.

A tool approval permits that operation to execute. It does not mean you have accepted the quality of the finished guide; you will do that separately.

Check the usage and cost information reported by the runtime. Available fields depend on the runtime and provider, so an absent cost value should not be treated as proof that the run was free.

6. Check the result against the brief

Use the same criteria you gave the agent:

• Are the four setup steps present and in order?
• Does the guide say that only an admin can invite teammates?
• Does it explain that a task belongs to a project before assignment?
• Does it include the missing-invitation troubleshooting tip?
• Does it avoid unsupported claims about trials, integrations and response times?
• Is the source identified, and is the guide under 250 words?
• Is the draft attached to the intended Work item?

If something is missing, put precise feedback on that work item. For example: “Add the project requirement before assigning a task, and remove the unsupported free-trial claim.” Follow the resulting correction through the run history; the first output is not automatically the accepted result.

Once you accept the guide, save the approved version in Docs and record its link in Work. Complete the assignment after the result and review are recorded. You can do these final edits yourself, keeping the writer's initial permissions unchanged.

What you should have at the end

You should have a source brief in Docs, a Work item with an owner and reviewed draft, a run record showing the agent's actions, and an approved guide saved for reuse.

This is a worked exercise with acceptance criteria, not a claim that every model will produce the same text or succeed on its first attempt. The useful outcome is a result you can check and an execution record you can inspect.

If the workflow stops

Extend it when the first run is reliable

Create a second agent to review drafts against the brief. Give it a distinct role and permissions, then name its exact assignee slug when asking the writer to delegate a review. Keep the human acceptance step: an agent review and an operator approval serve different purposes.

For more realistic context, connect a knowledge source. For actions in another system, configure HTTP or MCP integrations and review the permissions for the new tools before using them. A Blueprint can provide a reusable starting point for a larger team.

Prefer a managed workspace? Slab Hosted is accepting early-access requests. Use Request Hosted access at the top of this page to join the waitlist. Self-hosted Slab is available today.