Running the AI agent safely (admin guide)

Running the AI agent safely (admin guide)

This article is for the person responsible for rolling out AI agent execution to a team. It covers what gets approved, by whom, and how to keep costs sane in the first weeks.

If you're an end-user trying to use the agent, see Let AI actually run the task instead.

The core safety model

The agent has two action tiers:

This split is a code-level guarantee, not a configuration toggle. There's no admin setting to "auto-approve emails", by design.

Who can approve

In the current MVP, anyone with access to the task can approve a suspended run. The approver's identity is recorded in the activity log alongside the action.

If your team needs role-gated approval (e.g., only managers approve customer-facing emails), that's on the roadmap. For now, set team norms in writing.

What happens when an approval is rejected

The entire run is cancelled. The agent does not retry, does not "try a different approach", and does not partially-execute. The activity log records who rejected it and when.

To re-run with different parameters, start a new run with adjusted extra-context.

Approval card UI

When a run is suspended, the user sees this directly inside the task:

Approvals do not currently route to a central queue or to Slack/email, they live on the task. If your approver isn't watching the task, they won't see it. Decide on a notification convention (e.g., assignee always reviews; or a #agent-approvals Slack channel for high-volume orgs).

Cost & rate limits

Each agent run uses Claude. Cost ranges from ~$0.01 (low-risk only) to ~$0.05 (multi-turn with knowledge base + scraping).

Recommended day-one config:

• Daily cap: 50 runs / org / day
• Per-user cap: 10 runs / user / day
• Watch the cost dashboard for the first two weeks

These caps aren't user-facing settings yet, contact your account rep to adjust. We're shipping a self-serve panel in the next release.

Agent identity on send

When the agent sends an email or WhatsApp message, the sender is the user who started the run. Recipients see your team member's name and address, not "agent@wrrk.ai". This is intentional, it preserves continuity for the customer, but it means the user who started the run is accountable for what the agent sends.

If you'd prefer all agent-sent mail to come from a shared sender (e.g., ops@yourcompany.com), you can wire that up via the email-routing settings, but it's a deliberate setup step.

First-week rollout checklist

• [ ] Pick a single team to pilot with (5–15 people).
• [ ] Default mode = Supervised for the entire org. Don't open Autonomous until the team has run 50+ supervised runs cleanly.
• [ ] Set the daily cap to 25 (half the recommended) for the first week.
• [ ] Schedule a 15-min "what did the agent do this week?" review for Friday, pull recent runs from the activity log.
• [ ] Add an internal Slack channel for agent rejections so patterns surface fast.
• [ ] After two weeks: review approval rejection rate. >20%? The team needs prompt-engineering training, not more autonomy. <5%? Consider expanding caps and opening Autonomous mode.

What if the agent does something wrong?

Every run is logged with full action history. To investigate:

1. Open the task in question.
2. Activity tab → filter to "(Agent)" entries.
3. The Agent tab shows every approved action with its payload.

If the agent dispatched something it shouldn't have and the action was approved by a human, the failure mode is the approval, not the agent. Update your team's norms.

If the agent dispatched a low-risk action that caused harm (rare, they're scoped tightly), file a bug with the runId, that's the system's failure.

Disabling the agent

There's no global "disable" toggle in the UI yet. To disable agent runs for an org, contact your account rep, we can flip it off via support.