How agents ask before they write

An agent can read freely once you’ve granted it an area. Writing is different — creating a contact, updating a record, sending something — because it changes state in your workspace. By default, a write pauses for a person’s sign-off first. This page covers how that sign-off actually works, including the one case where the agent can’t pause and proposes the write instead.

For how to grant an agent access in the first place, see Give a teammate or agent the right access.

The two write levels

When you grant an agent write access to an area, you pick one of two levels:

Read / Write (asks first) — the default. Every write waits for a person to approve, edit, or decline it.
Read / Write (unattended) — the agent writes without asking. Use this once you trust how the agent behaves in that area.

Start with asks first. Upgrade a specific area to unattended only once you’ve watched the agent get it right.

When you ran the agent yourself

If you triggered the agent — from chat, or the Run button on its page — an “asks first” write pauses the run. A card lands in your Inbox (“Agent name: Approval needed — Wants to: action”), and you can:

Approve — the agent runs the action with the arguments it chose, then continues.
Decline — the agent is told the action was declined and carries on from there (it might try something else, or just note it in its summary).
Edit — change the arguments before it runs (available from the agent’s run page, not the Inbox card itself).

The run genuinely waits — it holds no thread and survives a restart — and resumes the moment you answer.

When a flow invokes the agent

A Run Agent step inside a flow can’t pause the whole flow just to ask you something — there’s no thread sitting around waiting. So instead of pausing, the agent proposes the write and keeps going:

The agent reaches the write, and instead of performing it, queues it as a proposal.
The agent’s run finishes normally — it can carry on to its next steps, and it reports what it would do rather than claiming it’s done.
The proposal shows up in your Inbox, exactly like the interactive case — same card, same Approve / Decline.
When you approve it, the write happens then — on its own, separate from the run that proposed it.

This means a flow-triggered agent that reviews, say, 40 items and wants to create 6 contacts finishes in one pass with 6 proposals waiting for you, rather than getting stuck on the first one. Nothing is silently skipped: every proposed write sits in your Inbox until you decide.

Before it asks

A proposal that duplicates something you already have erodes trust fast, so before a flow-invoked agent queues a create, it checks what’s already there:

Creating a contact matches by name first — ignoring case, spacing, and how accents were typed — so an existing contact is reused instead of proposing a near-duplicate. If the only thing it finds is a name that differs by accents (say “Jana Krckova” vs. “Jana Krčková” — genuinely could be two different people), it still proposes the create, but flags it: “Possible existing match: Jana Krckova — confirm before approving.”
Creating a deal matches by name within the same company, so you get one “Upsell” deal per company rather than a fresh one every time an agent revisits it.
Two agents proposing the same thing only queues once. The card that survives credits every agent that proposed it — “Also proposed by: …” — instead of silently crediting whichever one happened to queue first.

None of this merges or edits anything on your behalf. It only decides whether to ask you at all, and how to word the ask.

Grouped by who it’s about

When several proposals concern the same contact, company, or deal, they render next to each other in your Inbox under one heading instead of scattered among unrelated cards. Each still has its own Approve / Decline — the grouping is visual only, so you can approve one note and decline another about the same person.

Where it lands

A proposal that changes something that already exists — adding a note, moving a deal to a new stage — links forward to that record, not just back to where the agent got the idea: ”→ lands on Acme s.r.o. ↗.” Click through to check the target before you approve.

After you approve

Approving used to just make the card fade away. Now you get a small confirmation of what actually happened — “Create deal: Q3 renewal — Acme” — or, if the write genuinely failed (the target was deleted in the meantime, say), a sticky error explaining why, instead of the card disappearing as if it had worked.

How long a run can go

Every agent run has a step budget — the number of tool-call rounds (look something up, decide, write, look up the next thing…) it can take before it stops, whether or not it’s finished. This is a safety backstop, not a quality setting: it exists so a run can never loop forever.

Set it per agent from that agent’s Configure page, under Max steps per run. Leave it blank to use your workspace’s default (16 steps). Raise it for an agent that does a lot in one pass — reviewing a long backlog, or handling a record that touches several related things.

If a run hits its limit before finishing, it shows as Completed with errors rather than a clean success, with a note that it ran out of steps — so a truncated run is always visible, never mistaken for a finished one.

Where to go next

Give a teammate or agent the right access — the click-path for granting read/write levels.
Access: who can do what — the full access model behind those levels.
Asking a person — the equivalent mechanism for a flow pausing to ask a person a question (not an agent write).
Building an automation — how triggers, steps, and data fit together in a flow.