StrataDocs

Agents overview

Agents are scheduled AI runs that work autonomously — Strata executes them on the schedule you set, with the tools you allow, and (optionally) emails you the result so you can act on it without ever opening a chat.

What an agent run is — vs. a chat conversation

A chat is interactive: you ask, the AI answers, you steer with a follow-up. An agent is one-shot: you write the task once, and Strata runs that same prompt on a recurring schedule (or on demand). There is no follow-up because there's no human in the loop during the run. Each execution:

  • Runs in a fresh session with no chat history.
  • Uses only the tools you explicitly enabled.
  • Has a hard runtime cap (30–600 seconds, default 300).
  • Has a hard token cap on its written response (500–100,000 tokens, default 20,000).
  • Ends with a status of success, failed, or timed out, and the full output is stored in the agent's run history.

Use agents for recurring reports, monitoring, inbox triage, OneDrive intake — anything you wish would just happen on its own.

The Agents page

Click Agents in the sidebar. The page shows your agent table with these columns: Agent, Status, Schedule, Model, Next, Last, plus a row-action cell on the right. Above the table is a stats row (Total, Active, plus Running and Disabled counters when applicable) and the Deploy agent split button.

The Model column shows which AI model the agent runs on — you pick it on the wizard's Engine step. The available models come from your organization's Model Catalog (the set your admin has enabled), so the list reflects the same models you see in chat. See Models for how the catalog works.

Status words

  • ready — armed and waiting for the next scheduled run.
  • running — a run is currently executing.
  • paused — you've toggled the agent off; it won't run on schedule.
  • failed — the last run ended in error or timed out (but the agent is still scheduled to try again).
  • disabled — five consecutive failures auto-disabled the agent. Edit it (or fix the underlying issue) to bring it back.
Note

Agents are also paused org-wide while a subscription is inactive. Runs are skipped rather than failed — they show as Paused — not started in the run history, and the run records "Organization's subscription is inactive — agents are paused until billing is resolved". Nothing is lost: once an admin restores billing at Admin → Billing, agents resume on their normal schedule without being re-armed.

Note

An agent also stops running if its pinned model is later removed from your organization's Model Catalog. The run fails cleanly and you're notified — an admin must re-enable the model, or you can edit the agent to use a model that's still enabled.

Starred agents show a small star icon next to their name. Use Star / Unstar in a row's ... menu to flag the agents you check most often.

Row actions

Each row's action cell has three controls:

  • Pause / Resume — toggles the enabled flag. A paused agent stops appearing in the scheduler poll; its next_run_at is cleared.
  • Run now — kicks off a manual run immediately, independent of the schedule. The run is tagged trigger_type=manual in run history.
  • A row-menu (...) — for less-common actions.

Clicking anywhere else on a row opens the detail view, which shows recent runs and a Details button that opens the wizard to edit the agent.

Deploy your first agent

Click Deploy agent at the top right of the Agents page. The split button gives you two choices:

  • Deploy custom agent — opens the six-step wizard with empty defaults. See /docs/agents/create.
  • Deploy from a template — opens the Templates view, listing every template you can deploy. Templates published by your admin appear under From your organization; the Kronisys-curated set appears under Built-in templates. See /docs/agents/templates.

The current built-in templates are:

TemplateWhat it does
Daily database summaryWeekdays at 9 AM, queries your active SQL connection for the 3 tables that grew most in the last 24 hours and emails a plain-language paragraph.
Weekly inbox triageMondays at 8 AM, ranks the top 10 unread/flagged Outlook messages from the past week and emails a digest.
OneDrive new file digestWeekday mornings, lists files modified in the last 24 hours under any folder named "Inbox" in OneDrive.
SQL anomaly watcherHourly during business hours, looks for zero/negative amounts or other anomalies and emails only when something is wrong (errors-only mode pre-configured).

Org limits on agents

Your admin can constrain how many agents you can deploy and how often they can run:

  • Max agents per user — a per-org cap. Hitting it returns Agent quota reached: your organization allows up to N agent(s) per user. Delete an existing agent to make room. (HTTP 429).
  • Minimum run interval — the shortest cadence the org allows. A schedule below the threshold returns Schedule is too frequent: your organization requires at least Ns between runs (this schedule fires every ~Ms). Pick a less frequent cadence.
  • Daily agent runs per user — a soft daily cap that pauses further scheduled runs once reached. Manual Run now still works.
  • Cost ceilings — admins can also cap what a run may consume: a max-tokens-per-run ceiling and a max-spend-per-run ceiling stop a run mid-execution once reached, and a monthly spend cap per agent skips that agent's runs until the calendar month resets. These are what make short (every-few-minutes) schedules safe to allow.
  • Org-wide kill switch — admins can toggle lock_agents to block new agent creation and edits across the org. Existing agents continue to run on schedule.
Note

Self-serve trials carry two limits your admin cannot raise. For the length of the trial, each member may deploy at most 2 agents, and every schedule is floored at one hour between runs. Both are clamps rather than replacements: an admin who set something tighter still wins. Both lift when the trial converts to a paid subscription, and neither applies to legacy indefinite-trial organizations.

See /docs/admin/rate-limits for how admins configure these and /docs/agents/per-user-governance for per-user restrictions that apply on top.

Where to go next

Related