Skip to main content

​
What the Inbox is for

The agent does the work and stops only when it genuinely needs you. The Inbox (at /inbox) is where all of it lands, so “does anything need me, and what did it do?” is one page rather than a hunt through run histories. Open it from the Inbox button in the top bar, on every screen; the badge on it counts what is waiting on you. The Inbox replaced the separate Work and Studio screens. The list of rows waiting on a person is called the inbox in the API, MCP (list_inbox) and emails too. It has four views, named for what you ask of it:
  • Waiting on you: everything waiting on you, as decisions. The three that matter most come first; the rest are grouped by what they ask. See At most three decisions first. Approvals, suggested changes, and articles and posts written for you all wait here, and snoozed rows come back here when their time comes.
  • Running: work that is approved and moving, and every Done we are still checking. Nothing here needs an answer; it is there so you can see what is happening.
  • Done: merged pull requests, placed pitches and delivered changes, each with its re-read result. See Shipped.
  • From your assistant: everything your own assistant filed over MCP, open or moving.
Two more sit beside them: Emails to send, the outreach drafts only you can send from your own mailbox, and Snoozed, what you put off and when it comes back. Links to older tab names, such as the ones in emails we already sent, open the view that holds those rows now. The Inbox names your workspace’s approval mode — ask, draft or act — because that setting decides what waits here at all. An empty Waiting on you means something different in each mode, and the line says which one is in force. Every row has its own page at /inbox/<ref>, where you read it in full and act on it. A row’s ref is the same everywhere: in the Inbox, on Home, in emails, and in the API and MCP.

​
Three kinds of row

Every row waiting on you asks one of three things of you. We work out which, not the agent and not the screen, so the Inbox, Home, the morning brief, the daily email, the API and MCP all agree on what a row is asking. A few rows are notices: they tell you something, such as credits we added back to your balance, and ask nothing. They are listed last and never count as a decision.

​
At most three decisions first

A row is one attempt; a decision is one thing for you to decide or do. Seven runs that hit the same missing GitHub connection are seven rows and one decision, shown as Connect GitHub · 7 waiting. Every row about the same missing integration folds into one decision, and so do approvals waiting on the same tool. Each proposed change is its own decision. Waiting on you shows the three decisions that matter most, ranked in this order:
  1. An approval that expires within a day. If it lapses, the run goes on without doing what it asked.
  2. How much is at stake: a whole capability switched off, then a failed run, then a run stopped on one thing or an approval that expired, then a judgement call or an unsent rewrite.
  3. An approval whose effect cannot be undone, which includes anything that spends money.
  4. A question, because an answer is the quickest thing on the list to give and unblocks a run straight away.
  5. How many rows are waiting on it.
  6. How long it has been waiting, oldest first.
Everything after the first three is grouped by what it asks, such as 2 more questions or 3 more approvals, and stays collapsed until you open it. This one ranking is read everywhere “what needs me” is shown: the Inbox, Needs you on Home, the badge, the morning brief, the daily email, and view=triage in the API and MCP. They cannot disagree about what comes first. The badge counts decisions, not rows.

​
Needs you on Home

Home leads with the same thing, under Needs you: the top three decisions from Waiting on you, in the same order, each one something you can act on right there: approve or decline a change, or connect what a group of rows is waiting on. A chat paused on a question for you is listed after them. Under the three, Home says how many more are waiting, with a link to the Inbox. The number beside Needs you on Home and the badge on the Inbox button in the top bar are the same number, read from one place, so they cannot disagree. It counts decisions, not rows, and adds each chat waiting on your answer. Act on a row on Home and both change together.

​
What ends up in Waiting on you

All of these used to be visible only inside a run’s transcript.
The agent tried to do something irreversible or hard to undo — publishing a page, sending mail, spending with a third party — and stopped for your explicit yes. The row’s page shows the tool, what it would do and whether it can be undone. Approve once lets the run make that one call; Decline takes a reason and an optional note, which the run reads before it carries on without the call. An approval is never edited; see why.An approval that goes unanswered expires after 7 days. When it does, the run is closed without doing the thing, nothing is changed, and you get a row in the Inbox saying so. See what the agent shows you.A run that stopped to ask you questions, rather than for permission, is answered in the run itself; the row links there.Whether an action stops here at all — and how much the agent will do on its own before it does — is set by your workspace’s approval mode.
The agent needs a fact only you have: a launch date, which plan to lead with, the name your customers use for a feature. You answer in the row. See Answering a question.
The agent tried and could not proceed: a site refused us, a credential is missing, a file it has no write access to. It files what it attempted and what it needs from you, rather than writing “I was unable to…” into a transcript nobody reads. When it knows exactly what you need to do, the row carries numbered steps and, where we can check the result, a check behind Done. See Done, and the check behind it.
Several courses of action are defensible and picking one is your call, not a guess the agent should make on your behalf.In Ask mode, a goal that falls far enough behind to re-plan becomes one of these rows: “your goal” is behind pace: re-plan the work toward it? The row starts nothing on its own. It is filed at most once per goal per week, and a dismissed row is not filed again that week. See Goal re-plans.
A tool could not run because an integration is not connected, was revoked, or does not have the permission the action needs. These are raised automatically from a call that actually failed — never from the agent’s opinion about what it can do.All rows about one integration, whether it is not connected or its credential stopped working, from any run or any of its failing tools, are one row with an occurrence count. Connecting the integration closes it automatically.A scheduled run that needs an integration its automation’s tool list does not include files nothing here, because connecting it would not help that run. It is noted on the run’s transcript; add the tool to the automation to fix it.
Business profile fields the agent needed and found empty share one row: fill in your business profile. It is a question: answer it in the row and the answer is saved to the profile field it names. It closes when a profile field is saved.
When the credit balance is spent, or the workspace’s monthly credit cap is reached, one row says scheduled work is paused and names the automations. It closes itself when the first one runs again. See Credits.
A scheduled automation run ended in failure. A chat that fails is failing in front of you; a 3am run is not, so it comes here instead.
One of your webhook endpoints kept failing, or answered 410 Gone, so we stopped sending to it. The row says which host and why, once per endpoint. Turn the endpoint back on in Settings → Webhooks once your server answers again, and resend what it missed from its delivery log.

​
Repeats and duplicates are one row

Each problem appears once. Three rules make sure of it, and none of them decides anything on your behalf. The same problem again. An automation that hits the same wall every night does not produce a row per night. The Inbox recognises a repeat of the same problem and updates the existing row, showing how many times it has now come up. The same question asked twice is one row too. That count is the useful part. “14 times” means the problem has been there for two weeks and nobody has acted on it — a different fact from the same row appearing for the first time this morning. Resolving a row closes that chapter. If the same problem happens again afterwards, it comes back as a new row rather than silently reopening one you had already ticked off. A better version of the same change. When the agent proposes a change to something it already has a proposal waiting on — the same file, the same passage of a page, the same article — it revises the waiting row in place rather than filing a second one. The row keeps its link, its activity log reads Revised: this replaced the earlier version, and the new version is what you approve. If you had the older version open, your approval is refused with this was revised since you opened it, so you never approve words you did not read. A proposal you already approved is left alone; the new version files beside it. The same thing in different words. Decisions, questions that do not fill a profile field, and other free-form rows cannot be matched by what they name, so a run that asks “which launch date?” on Monday and “pick a day for the launch” on Wednesday would file two rows. Every 15 minutes a duplicate check compares each new row of that kind from the last 7 days with the older open rows of the same kind. When it is confident they ask the same thing, it folds the newer row into the older one: the older row counts it as a repeat, and the newer row is hidden. The duplicate check can only hide a row. It never approves, answers, declines or closes anything, never touches a proposed change or an approval, never compares rows of different kinds, and leaves alone a row you have started to answer or that is being checked. When it is not sure, nothing is hidden. Every fold can be undone. Open the hidden row’s link and you land on the row it was folded into, with Not the same: press it and the hidden row is its own row again, and the two are never folded together again. The duplicate check costs you no credits.

​
Acting on a row

What you can do depends on what the row is: A snoozed row is put away until the time you picked, and comes back to Waiting on you on its own — nothing is lost by putting it off. Done is deliberately not called “approve”. Nothing is queued up to run when you press it — the work happened outside the product, and you are telling us it is handled. Declining and dismissing are both recorded rather than deleted: what you turn down is as useful a signal as what you accept. After you act on a row on its own page, the page says what happened and offers Next: the row the ranking puts first now.

​
Editing before you approve

An article or a LinkedIn post that is still waiting can be edited on its page before you approve it. Press Edit, change the words, and Approve edited approves your version in the same step. Your version is what publishes, and the agent’s original is kept on the item. In the dashboard a rewrite has no Approve button: we never publish one, so you copy its new text into your own editor. Over the API or the MCP server, an approve call can still carry your edit of a rewrite (edited_value); that keeps your words on the item, and it is still yours to paste.
  • An edited change is always a claim. Your words are now what the business says, so an edited change is never treated as a safe change and never goes out on its own: it waits for a person’s yes in every approval mode, and is never auto-merged.
  • Code is never changed this way. An edit that adds or changes a fenced code block, a <pre> or a <code> sample is refused with the rule, and nothing is approved.
  • Your edit gets the same check as a draft. It is checked against your workspace’s rules before it is approved, the same check the agent’s own draft gets.
  • An article keeps its front matter. If the article came with front matter for your site’s build and your edit dropped it, it is put back.
  • An edited article or post is updated on the content plan too.
A fix to a file in your repository cannot be edited here: edit it in the pull request it opens, or decline it with a note saying what to change. An approval from a paused run cannot be edited either; see why. If the agent revised the proposal after you opened it, Approve and Approve edited are refused with this was revised since you opened it, and the page shows the new version. Read it, then approve that.

​
Declining, with a reason

Every decline carries one of four reasons: You can add a note of up to 1,000 characters in your own words. With Wrong the note is required, because “wrong” alone does not say what to fix. The reason and the note are kept on the item and in its activity. Declining an approval from a paused run hands the run your reason and note before it carries on without the call.

​
Answering a question

Open the row and type your answer, up to 2,000 characters, or pick one of the answers the agent offered. Then:
  1. The answer is saved where every later run reads it. If the question names a business profile field, the answer is saved to that field, and every other row waiting on that field closes with it. Any other answer is kept as a fact you stated: every run in the workspace reads your newest stated facts, up to 40 of them. There is no screen that lists stated facts.
  2. The row closes, marked as answered by you.
  3. The run that asked is put back to work, depending on where it is now:
If the run could not be handed the answer, the answer is still saved and the row stays closed; the row says so and offers Retry. If two people answer at once, the first answer counts and the second is told the row was already answered. If saving fails, nothing changes and you can answer again.

​
Done, and the check behind it

A row to do on your side lists numbered steps, with a copy button beside each value you need to paste: a DNS record, a snippet, a line of text. Some rows also carry a check, because there is something we can look at to see it was done: On such a row the button reads Done, verify it. Pressing it does not close the row on your word, and you do not wait on a spinner either: the row moves to Running as Checking…, and the check runs within a few minutes.
  • It passes: the row closes on its own, saying what was verified.
  • It fails: DNS and caches often lag a change by minutes, so we try again three more times: after 10 minutes, then 20 minutes after that, then 30 minutes after that, about an hour in all. A check that points off your domain is not retried.
  • It still fails after that: the row comes back to Waiting on you with the reason in plain words, such as “There is no TXT record on example.com yet”, and a Check again button.
A check only ever looks: a DNS lookup, a read of your connections, a read of one public page. It only looks at your own domain and its subdomains, and a page that redirects off your site does not count. A row cannot be snoozed while its check is running. A row with no check closes when you press Done, as it always has.

​
The keyboard

The list is keyboard first. Keys are ignored while you are typing in a field, and whenever ⌘, Ctrl or Alt is held. a approves from the list only a single proposed change whose effect can be undone and that is classed safe. Anything else — a claim, a change that cannot be undone, spend, an approval from a paused run, a question, a decision with several rows behind it — says Open it to approve, because a yes to something nobody read is not a yes.

​
On a phone

On a narrow screen the row’s page keeps its main action pinned to the bottom of the screen, so approving is two taps: the row, then Approve. The action is reachable without scrolling past a long article or diff, long lines wrap instead of scrolling sideways, and every button is at least 44 pixels tall on a touch screen.

​
One email a day, at most

If something has been waiting on you, unseen, for 24 hours, we email you about it. It is one email per workspace per day, however many rows are waiting: it lists the top three decisions, in the same order as the Inbox, and how many more are behind them. A row being checked, or one folded into another as a duplicate, is not waiting on you and does not count. These emails are the Attention category of your notifications.

​
The pull request chip

A row whose work ended in a GitHub pull request carries a PR chip: the pull request number, linked, plus its current state. The chip is how you tell “the agent opened something” from “the agent opened something and it is stuck”. The state comes from GitHub, not from us guessing: it updates as the pull request is reviewed, merged or closed. A merge conflict shows the same way a red build does — surfaced on the row, and left for you.
A failing chip is not a task we are working on. Attensira never pushes a second time to a branch it opened, so nothing changes on that pull request until a person acts on it.
A change that is approved but held by your weekly change cap shows as Approved, held by your weekly limit.

​
Merging a pull request

We merge only when you press Merge here, or when you switched on auto-merge for safe changes. Approving a change opens its pull request and never merges it. Open an approved item whose pull request is still open and the pull request is shown in full, read live from GitHub: its files and diff, its checks, a deploy preview when there is one, and why it cannot merge yet when it cannot. Then:
  1. Mark ready for review, while it is a draft. It takes the pull request out of draft and does not merge it. If your repository merges ready pull requests on its own, that automation may merge it from here.
  2. Merge, once GitHub says it can merge. It squash-merges at the commit on screen.
Both are pinned to the commit you were looking at: if the branch moved since, the click is refused and the view reloads so you review what changed. Once it is out of draft, a conflict, a missing review or a failing check keeps Merge disabled with the reason beside it. The chip turns Merged when GitHub reports the merge, and the re-reads start then. Merging is dashboard only; the API and MCP cannot merge. The full rules are on the GitHub page.

​
Rewrites

A rewrite, shown as new wording in the app, is a fix for a page we cannot open a pull request against, because no repository is connected or because that page does not come from one. It is one passage of your live page, quoted exactly as published, beside a better version of it, with the reason and the buying questions it is meant to move. We never publish a rewrite. There is nothing to approve, so a rewrite row has no Approve button. What it has instead:
  • Copy the new text and paste it into your CMS yourself, then Mark shipped with the URL (see Mark shipped).
  • Share a link: a private, signed link that expires in 30 days, for forwarding to whoever owns the site. They need no account. The page carries your org’s branding. Rotating your workspace’s share secret revokes every link at once.
  • Request access from my developer: see GitHub.
The before side is always the page as we actually read it. If the agent quotes a sentence that is not on the page, the rewrite is refused rather than filed. Rewrites carry the same change class as pull requests: one classed claim (it touches a price, a number with a unit, a promise, or a competitor’s name) says so on the row and on the shared link. If a rewrite sits for five days with nobody copying it and no access request sent, it comes back in Waiting on you and in your morning brief. That row goes away the moment you act on it or ask your developer.

​
Written for you

Articles and LinkedIn posts the agent writes appear under Waiting on you, in Written for you, rendered as a document you can read in place. What you can do depends on where the piece goes: In the list, Edit is offered only on a piece you publish yourself (a copy target or a LinkedIn post): the edit stays on the page and Copy takes your version. To change the words of a piece bound for a repository or Notion before it goes, open it and use Edit then Approve edited, which saves your version on the item. For an article bound for a repository, the front matter fields show as one line above the body. Articles always wait for a person’s yes, in every mode. Revising an article that is still waiting updates the same item. Briefs, emails and notes the agent writes are not filed here. Articles also appear as drafts on the content plan. LinkedIn posts always carry the link to their source page. Attensira never posts to LinkedIn: you post it from your own account and mark it shipped with the post’s link.

​
Mark shipped

Mark shipped is for copy handoffs, where you publish the piece yourself: articles with a copy target, LinkedIn posts, and new wording for an existing page when no repository is connected (next to Copy the new text and Share a link). It is also how you tell us an article we created as a draft in your CMS went live, once you published it there.
  • You give the URL where it went live, and the item leaves Waiting on you. It is not yet listed in Done, which today shows what the agent shipped from its action log; the re-reads below still run.
  • The URL is recorded as given. It is not checked until the first re-read, which confirms the change is on that page before measuring anything.
  • Marking shipped starts the before-and-after re-reads for the tracked prompts attached to the item, unless a read of your page already saw the change and booked them. See Page changes.
Approving a copy item does not publish anything. The item comes back with an instruction to paste it and mark it shipped.

​
Shipped

The Done view lists merged pull requests, placed pitches and delivered changes. Each shows its re-read result in plain words: Moved (named more often on X of N prompt and engine pairs, across M answers), Fell, No change, Too close to call, Too few answers (not enough data from before the change), Not live, or Re-read booked with its date. Every result is a single dated reading, never a day-over-day comparison. See Before and after for what each means.

​
What the agent can and cannot put here

The agent can raise three things itself: something it is blocked on, a decision that is yours, and a question only you can answer. Each requires it to say what it actually tried. A row it raises can carry at most eight steps, and a check only against your own domain or an integration we offer; anything else is refused and the agent is asked to try again, with nothing filed. It cannot file the other kinds. A missing connection, a failed run and an expired approval are raised from evidence — a call that really failed, a run that really died, a deadline that really passed — so that everything on this list is a fact rather than a guess. An hourly pass also files decisions on its own, grouped by the source that caused them — see What the agent notices on its own. A change too small to tell from sampling noise is held back rather than filed, and checked again an hour later; see Noise, or a real change.
Raising something in your Inbox costs no credits and changes nothing in your workspace. The agent is never discouraged from telling you it is stuck.

​
The Inbox is not only a screen

Everything above is available through the MCP server and the REST API as well, so “what needs me right now” is answerable from wherever you already work, not only from the dashboard. Both read the same ranking (view=triage), read any row by its ref, answer questions, approve with an edit, decline with a note, and approve or decline a paused run’s approval. Every act returns next_item_ref, the row the ranking puts first now. An assistant acting for you should approve, answer or decline only on your instruction, never on its own reading of the row. Two things are not in the MCP tools or the REST API yet: Not the same on a folded duplicate, and Retry when a run could not be handed your answer. Use the row’s page for those.