Press / to search

All documentation
docs Teach the agent Scribe

Runs onWrit CloudDesktop

scribe ▸ describe it, it builds it

Describe the job. Scribe drives.

Scribe is Writ’s own AI. You say what you want in plain words; it opens a real browser, finds the page, validates a selector on it, and builds the monitor, the workflow or the crawl. It works in turns, and it pauses before anything that costs you money or touches your accounts.

Scribe stops and asks. It never places an order, and it never asks you for a card number.

approval ▸ it pauses

It stops and asks. That is the design.

A mission runs in turns. When it needs something from you, it stops: the session goes to awaiting_input and carries a pending_request describing what it is waiting for. There are three shapes of pause:

PauseWhat you see
A questionOne or more fields it needs answered — a threshold, a choice, a confirmation, a login identity.
A monitor-batch reviewEvery site it discovered, all preselected and individually deselectable, with an estimated setup cost — shown before a single monitor is created.
A connect-setup reviewThe live endpoint URLs it just published, plus the offer to create an API key for them.

An approved purchase has a hard precondition, not a soft one. A persona, a payment method, an explicit confirmation and a threshold must all be collected before it will draft anything. Missing any one of them, it asks instead of proceeding.

Two ways to stop. interrupt breaks the current turn and parks the mission — it is resumable. cancel ends it. And a reply to a turn that has already moved on answers 409: re-read the session and answer the current turn rather than the one you were looking at.

capabilities ▸ one tool a turn

What you can ask it to do.

Scribe picks exactly one tool per turn, from a fixed set. It cannot invent a tool, so the list below is the whole of what a mission can do:

Find and read a pageLand on the right page, then propose a selector and validate it against the live page before using it.
Create a monitorWatch a price against a numeric threshold, or watch content for any text change. Mode: a selector, or a visual pixel-diff of a screenshot zone — which is how charts, images, canvas/SVG and logos get watched. Render: auto, http or js.
Watch several sites at onceDiscover candidate sites, propose a ranked batch for your review, and create one monitor per kept site in a single turn.
Ask you for inputtext, value, choice, confirm, secret, persona or payment_method.
Sign in as youLink a saved login identity and handle 2FA, so login-gated pages are reachable.
Build a workflowDraft an approved-action workflow, run an autonomous session that signs in and builds one, or persist a workflow from steps you state explicitly. Add a named callable.
Test it and schedule itRun the workflow and report PASS or FAIL with sample data, then configure a schedule.
Publish itExpose the workflow as REST, as an OpenAI-compatible surface, or as MCP — then pause to show you the live URLs.
Wire an automationConnect a detected change to a notification.
Crawl and answerRun a whole-site crawl with live progress, fold a finished crawl into a single answer, and arm a recurring or reactive crawl.
Use what you already haveList, search and answer from datasets you have already collected. This is the cheapest path, and it is preferred before crawling anything.
FinishClose the mission with a summary of what was built.

The set is fixed on purpose. An AI that can only pick from a known list is an AI whose worst turn is still a tool you can read about on this page — so “what could it possibly do?” has an answer with a finite length.

venues ▸ two, not one

Cloud Scribe and desktop Scribe are not the same.

There are two implementations, and they differ in what they are allowed to build. Read the row that matches where you are running before you plan a mission around it.

WhereBaseWhat it can build
Writ Cloud/api/ai-conciergeThe full set — including approved-action drafting and multi-site batch monitors.
Writ Desktop/v1/ai-conciergeWatch and notify. No approved-action drafting, no multi-site batch monitors.
Self-hostedNot available. Scribe is not part of the self-hosted coordinator.
CallWhat it does
POST /api/ai-concierge/startStart a mission. Answers {session_id, status, poll_url} immediately; the work continues in the background.
GET /api/ai-concierge/{id}The full session state. This is what you poll.
POST /api/ai-concierge/{id}/respondAnswer the current pause.
POST /api/ai-concierge/{id}/askAsk a follow-up about what it built.
POST /api/ai-concierge/{id}/personaAttach or clear the login identity.
POST /api/ai-concierge/{id}/interruptStop the current turn and park the mission.
POST /api/ai-concierge/{id}/cancelEnd the mission.
GET /api/ai-conciergeYour missions, newest first.

On the desktop agent

The same shape, on loopback, against the agent running on your own machine — and free, because the browser is yours:

POST /v1/ai-concierge/startStart a mission.
GET /v1/ai-conciergeList missions.
GET /v1/ai-concierge/{id}The session state to poll.
POST /v1/ai-concierge/{id}/respondAnswer the current pause.
POST /v1/ai-concierge/{id}/interrupt · /cancelPark it, or end it.

Say it plainly: Scribe is not part of the self-hosted coordinator. A self-hosted deployment runs workflows, monitors, automations and crawls — it does not ship Scribe. If a mission-driven build is what you want, that is Writ Cloud or Writ Desktop.

session ▸ what you poll

The mission runs in the background. You poll it.

Start answers straight away with a session id and a poll URL — a browser mission outlives an HTTP request, so a handle is the honest answer. Every poll returns the same projection:

FieldWhat it holds
session_id · goal · platformWhat you asked for, and where it is running.
statusplanning, browsing, building, proposing, awaiting_input, armed — plus the terminal states.
phase · progress_messageWhere it is, in words you can show a user.
transcriptThe conversation so far.
thoughtsThe tool it chose and a short thought, per step.
planWhat it has decided so far. Payment references are stripped.
pending_requestThe pause it is waiting on, when status is awaiting_input.
resourcesWhat it has created — the monitor, the workflow, the endpoints.
turn_seqThe optimistic lock you echo back when you respond.
tokensinput, output and the credits spent so far.
error_message · created_at · completed_atWhy it stopped, and when.

Its visible reasoning is deliberately narrow: the tool it chose and a short thought. Tool arguments and tool results are never streamed — which is also why nothing you typed into a secret field can appear in the reasoning feed.

Start, poll, answer

A mission end to end, over plain HTTP.

start.sh

# Describe the job. goal is 3-2000 characters; url is an optional seed.
curl -X POST https://api.usewrit.app/api/ai-concierge/start \
  -H "Authorization: Bearer $WRIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "goal": "Watch the price of the 15-inch model and alert me under $1,200",
    "url": "https://example.com/laptops/15"
  }'

respond ▸ answering a pause

Answering the turn in front of you.

A response carries turn_seq and an answers object keyed by the fields the pause asked for. turn_seq is an optimistic lock: send back the one you read. If the mission has moved on, you get 409 — refresh and answer the current turn instead of overwriting a newer one.

Input kindWhat it asks for
textFree text.
valueA number — a price threshold, a quantity.
choiceOne of a set it offers.
confirmA yes or no, before something happens.
secretA credential. Sealed to the vault on arrival.
personaWhich saved login identity to use.
payment_methodHow a purchase would be paid, if you are building one.

A secret answer is sealed into the vault as it arrives. What reaches a run afterwards is a placeholder that resolves at run time — the value itself does not travel through the plan, the transcript or the model.

There is one more field a response can carry, and Scribe never asks for it. Payment is collected as a choice — the model cannot request a card number at all. But if you take the advanced path and type one, those fields ride in their own card_fields object rather than in answers, and they are sealed into the vault as they arrive. Only placeholders reach the plan, payment_mode becomes vault_card, and the references are stripped back out of the plan you poll — the number itself never travels through the transcript or the model. If it cannot be stored, the answer is refused with 400: the pause stays open, and nothing is kept.

The same, on your own machine

Loopback, a local token, and the desktop’s narrower scope — watch and notify.

desktop.sh

curl -X POST http://127.0.0.1:8131/v1/ai-concierge/start \
  -H "Authorization: Bearer $WRIT_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"goal": "Tell me when this page changes", "url": "https://example.com/status"}'

curl http://127.0.0.1:8131/v1/ai-concierge     -H "Authorization: Bearer $WRIT_TOKEN"
curl http://127.0.0.1:8131/v1/ai-concierge/7   -H "Authorization: Bearer $WRIT_TOKEN"

curl -X POST http://127.0.0.1:8131/v1/ai-concierge/7/respond \
  -H "Authorization: Bearer $WRIT_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"turn_seq": 2, "answers": {"confirm": true}}'

curl -X POST http://127.0.0.1:8131/v1/ai-concierge/7/interrupt -H "Authorization: Bearer $WRIT_TOKEN"
curl -X POST http://127.0.0.1:8131/v1/ai-concierge/7/cancel    -H "Authorization: Bearer $WRIT_TOKEN"

limits ▸ plainly

What Scribe will not do.

Worth reading before you plan around it. None of these are settings you can change:

  1. It does not place the order — For a purchase, it drafts the checkout up to the pay button and stops there. The last click is yours.
  2. It never asks for a card number — Payment is collected as a choice — a card already saved on the merchant, your browser’s own autofill on your own machine, or a virtual card. The model cannot ask for a number. If you take the advanced path and enter one yourself, it is sealed into the vault as it arrives and only a placeholder reaches the plan.
  3. It cannot invent a tool — One tool per turn, from the fixed set on this page. There is no free-form action.
  4. It does not run self-hosted — Scribe is not part of the self-hosted coordinator.
  5. Desktop Scribe is narrower — No approved-action drafting, and no multi-site batch monitors.
  6. It does not stream its arguments or results — The visible reasoning is the tool it chose and a short thought. Nothing more.

plan ▸ what it costs

What it needs, and what it spends.

Scribe needs a plan that includes AI assist. Token spend is metered and shown inside the session itself — the tokens field carries input, output and the credits consumed so far, so a long mission is never a surprise at the end of it. A mission on your own machine drives your own browser, so the browser time is free; the AI tokens are still metered.

faq

Scribe questions, answered.

Will Scribe buy something without asking me?
No. It drafts the checkout up to the pay button and stops — the last click is yours. And it will not even draft one until it has collected a persona, a payment method, an explicit confirmation and a threshold. Missing any of the four, it pauses and asks.
Does Scribe ever see my card number?
No. Scribe cannot ask for one — payment is collected as a choice between a card already saved on the merchant, your browser’s own autofill on your own machine, and a virtual card. If you take the advanced path and enter a card yourself, it is sealed into the vault as it arrives, only a placeholder reaches the plan, and payment_mode becomes vault_card. The number does not travel through the transcript or the model, and payment references are stripped out of the plan the session returns to your client.
Can I run Scribe on a self-hosted deployment?
No. Scribe is not part of the self-hosted coordinator. A self-hosted deployment runs workflows, monitors, automations and crawls; the mission-driven build surface is Writ Cloud and Writ Desktop only.
What is different about desktop Scribe?
It is watch-and-notify only: no approved-action drafting and no multi-site batch monitors. Everything else — finding a page, validating a selector, creating a monitor, building and testing a workflow — works the same way, on loopback, driving the browser on your own machine.
My respond call returned 409. What happened?
The turn moved on between your read and your write. turn_seq is an optimistic lock, so a reply carrying an old one is refused rather than applied to the wrong question. Re-read the session, look at pending_request, and answer the current turn.
How much of its reasoning can I see?
The tool it chose and a short thought per step, in the thoughts field. Tool arguments and tool results are not streamed — so a secret you typed into a pause cannot surface in the reasoning feed. Token spend is visible throughout, in the tokens field.

end ▸ ask it

Describe one job and watch it pause.

The fastest way to understand the approval model is to start a mission and read the first pending_request it stops on.