Agents

Admin → Agents

An agent is saved instructions that Lucy runs without a person in the chat: when someone presses Run, when another system calls a webhook, or on a schedule (at most every 15 minutes). Every run is a normal conversation, so you can follow it live and read it afterwards. For what people see, read Agents for users.

The Agents setting: who may create and run agents.

Why agents matter to the business

Repeatable work becomes dependable work. The Monday fee check happens every Monday, the same way.
Systems start work for people. A new supplier in procurement can start the DORA field check, with no one asking.
Output is reviewable. Every run is a conversation with steps and files, so there is always an audit trail.

Who may use them

Option	Meaning	Choose it when
`off` (default)	Nobody. No agent runs, webhooks answer 404 and schedules do not fire.	You have not decided yet
`admins`	Only org admins	A first pilot with two or three real jobs
`selected`	Org admins, plus the people and groups you grant	Rolling out team by team
`everyone`	All members	Everyone is trained and limits are in place

Switching to off stops everything at once: no new runs, no schedules, no webhooks.

Two kinds of agent

Owner agent

Acts as the person who made it, with their access and their allowance. Its runs are that person’s conversations. It stops running if its owner may no longer use agents or leaves the organisation.

Service agent

Only admins create one. It has its own identity, its own allowance and its own connections. Its runs are read-only and visible to admins only. Use it for shared automations that should outlive any one person.

What keeps agents safe

Control	What it does
Own connections	An agent never borrows its owner’s mail or files. Its managers sign it in separately, possibly with another account such as a shared mailbox, and can revoke it alone.
No questions asked means denied	An unattended run cannot answer an approval. Any tool set to `ask` is denied to agents. Only tools you set to `allow` can run, and only if the agent was given the app.
No local access	Agents never get tools on people’s computers.
Per-run budgets	A limit on tool calls and on minutes (at most 15). A run that reaches one stops, and the run records why.
One run at a time	Extra runs queue (up to 20). A schedule that fires while a run is going records a skipped run.
Untrusted input	A webhook’s content is passed in a block that tells the model it is data, not instructions.
Guarded callbacks	Results are posted only to public https addresses, signed, and re-checked at connection time.
Audit	The audit log names the agent as the actor of what its runs do.

What admins can see

The agent’s configuration (instructions, tools, limits, triggers) for every agent.
Service agents’ runs, in full. Owner agents’ runs belong to their owner’s conversations.
The audit log entries for creating, changing, disabling and running agents, creating and rotating triggers, and granting access.

You can disable an agent you are worried about, without deleting it.

Examples

Situation: You want to try agents without risk.

Setup: Set Agents to admins. Create two service agents: “DORA register reminder” (monthly, read-only) and “Contract expiry watch” (weekly, reads a folder). Give neither any write tool.

Result: After a month you have 8 runs to read, a feel for cost, and no exposure beyond reading.

Situation: The operations team wants a morning digest of the shared client mailbox.

Setup: A service agent with Mail only, signed in with the shared mailbox account. mail_read and mail_search are allow, mail_send stays ask (so it is denied to the agent). Schedule weekdays at 07:30.

Result: A digest and draft replies in the shared mailbox’s Drafts. A person reviews and sends.

Recommendation

Start with admins and one agent. Read the runs.
Keep write tools off for agents until you trust the process.
Use service agents for shared jobs, so they do not stop when someone leaves.
Review limits and budgets first: one runaway schedule can use a month’s allowance.