Creating an agent

Agents → New agent asks three questions in order. The third one is the one worth slowing down for.

1. What it does

Name it for what it produces — "Weekly digest" beats "Agent 2" the day you have six of them.

Prompt is the instruction it runs every single time, so write it as a standing order rather than a one-off request. Say what to produce, where to put it, and what to do when there's nothing to do:

Summarise the documents published in the last seven days as a short internal digest, and save it as a new note document titled Digest — <today's date>. If nothing was published, save nothing.

Nobody is watching a run, so a prompt that ends in a question is a run that wastes its time. Tell it how to decide.

Model picks the intelligence behind the run, with its rate shown beside each option. The default is a good all-rounder; a cheaper model is a false economy for work you aren't checking.

2. When it runs

Three triggers, and an agent can use more than one.

On a schedule

Pick one: every hour, every day at 09:00, every weekday at 09:00, every Monday at 09:00, or the 1st of each month. The wizard reads your choice back in plain language underneath, which is the quickest way to catch a mis-tap.

Schedules run in your own timezone, so "09:00" stays 09:00 across daylight saving rather than drifting an hour twice a year. The API accepts any five-field cron expression if you need a shape the presets don't cover.

:::note Missed runs don't stack up A schedule always looks forward. If Corte is unavailable across three of your agent's slots, it runs once when it comes back — not three times in a row. "Every hour" means "at most once an hour", which is almost always what people mean by it. :::

When content changes

Tick any of published, unpublished or deleted, and the agent runs when that happens to a document in its project. The run knows which document and which event triggered it, so a prompt can act on the thing that just changed.

Publishing the same document twice is two events and two runs. Editing a draft is not an event — only the three above are.

Only when you run it

Leave both empty and the agent runs only from Run now on its page, or from the API. Useful while you're still tuning a prompt.

3. What it can touch

This is the step that decides how much damage a bad prompt can do.

An agent acts as you, with a credential that exists only while the run is alive and dies with it. It can reach only the areas you tick here, and each area is either read-only or read and write:

• Read lets it look — list documents, fetch a workflow, read the library.
• Read & write lets it change things — create and publish documents, run generations, start workflows.

Tick the least that does the job. An agent that only writes a digest needs content read and write, and nothing else — not media, not workflows.

:::tip The tool count is the real check Under the list, the wizard says how many Corte tools your selection unlocks. If it says none, the agent still runs — every sandbox carries its own file and shell tools — it just can't reach anything in your account, so it will finish having achieved nothing you can see. That happens when the areas you ticked have no agent tools yet, or when you gave read-only access to something you want changed. Fix it here rather than reading a puzzling run later. :::

Account is never available

You can't give an agent access to your account, plan, billing or API keys, and the wizard doesn't offer it. That area can create API keys — an agent holding it could mint itself a permanent credential and keep working long after the run it belonged to ended, which is exactly the property the per-run credential exists to prevent.

Every other area is on the table, including Build, so an agent can maintain an app you've built as well as the content in it.

After you create it

The agent is live immediately: a schedule starts counting from now, and content triggers apply to the next change. Open it to watch what happens — see Runs and costs — or turn it off from the list while you think again. The toggle is the fastest fix for an agent doing the wrong thing; deleting it also stops anything it has in flight.

Changing it later

Edit prompt and access on an agent's page opens the same three groups of fields on one page — by then the agent exists and the question is usually which single thing to change. Only what you actually changed is sent, so two people editing different fields don't overwrite each other.

A run always uses the prompt and the access the agent had when the run started, so nothing you change afterwards can re-point work already under way. Changing a schedule recomputes the next run from now; turning the agent off clears it entirely.