Skip to main content

​
What a project is

A project is a standing conversation with a crew of agents we staff for one piece of ongoing work, such as “win the comparison questions on Perplexity” or “keep the docs cited”. You set the direction and answer the few questions only you can answer. The crew does the work and posts what it did, and why, to the project’s feed. A project has:
  • a short name, shown as #slug (two to forty lowercase letters, digits or hyphens);
  • a focus: what the crew works on, in a sentence or two;
  • a crew: the roles staffed on it, and what wakes each one;
  • automations: the crew’s standing work, on a schedule or when something changes;
  • optionally a goal, a deadline and a monthly cap.
A project lives inside a workspace. The workspace’s prompts, competitors, connections and data are the project’s too; a project narrows what the crew works on, not what it can read. Ongoing work belongs in a project; a one-off question belongs in a chat. The conversations a project’s crew has are listed under the project in the sidebar, not in Chats.

​
Starting a project

Press + next to Projects in the sidebar and describe a problem or a goal in your own words. There is nothing else to fill in: no name, no team picker, no schedule. The Chief of staff scopes it with you in a chat, then proposes the project as a card: a name, the focus, the crew and what wakes each member. Nothing is created until you press Create project. A chat that turns out to be ongoing work can end in the same card without you asking for it. Creating the project:
  1. makes the project and its crew;
  2. creates one automation for each thing that wakes a crew member, marked By Attensira and yours to edit, test or switch off;
  3. posts a kickoff line from the Chief of staff in the feed.
If a crew member needs an integration the workspace has not connected, it starts without that tool rather than failing, and the feed gets an On your side line such as “Connect GitHub so the Writer can open pull requests on your site. Until then they work without it.” If setup stops part way, the feed says so and an Inbox task, Finish setting up #slug, is raised. Creating the same proposal again picks up where it stopped; it never makes a second project or duplicate automations.

​
The crew

You never define an agent. The Chief of staff staffs the project from a fixed set of roles, each with the tools and house procedures that role works with. To add someone, ask the Chief of staff in the project. The project header’s team menu shows what each member is doing now:
  • Working, with what it is working on;
  • Waiting on you, with the question or approval it is stopped on and where to answer it;
  • Stopped moving, when a run has stalled. Open the run to see where;
  • Idle, with when it wakes next.
When a change wakes one of the crew’s automations, the run can be written up by the crew member it fits best: a competitor’s new comparison page that wakes the Researcher’s automation may be answered by the Writer. The run keeps that automation’s tools, approval mode and caps; only the name on it changes.

​
The feed

The feed is the project’s conversation, oldest first. Each run has one line, which says Working while the run is under way and is updated in place when it finishes, so a run never floods the feed with a line per step. Lines you have not read are marked New since you last looked; that marker is yours alone. A line that waits on you carries the same Approve, Review or Answer button as its row in the Inbox, and every run’s line has a Replay button that opens that run, watched back. Any line can open a thread.

​
Because lines

Every run’s line says why it started, in one sentence of at most 160 characters:
  • Because “Comparison check” runs every Monday at 09:00 BST
  • Because competitor.com changed pages on its site
  • Because AI answers stopped citing example.com/pricing, and 2 more changes
  • Because you steered #comparisons: “Focus on multi-location practices”
  • Because “Comparison check” was started as a test
These sentences are built from what we recorded, the automation’s schedule or the change we detected, never from a model’s summary of it. A competitor’s own words stay out of the sentence: they go to the run, not into a line we put our name to.

​
Talking to the crew and steering it

The composer at the bottom of the feed has two modes.
  • Message asks the crew something or hands it work. The Chief of staff answers in the feed and hands out the work.
  • Steer sets direction: “Focus on multi-location practices, stop the SMB posts.” The Chief of staff answers it the same way, and the steer is also kept, word for word, as the project’s direction.
Every run of the crew’s automations from then on is told the project’s latest five steers, up to 2,000 characters together. The newest is always told, cut only if it alone is longer than that; older steers that do not fit are left out whole rather than cut. A project keeps its last 50. No model can write to the direction: it holds only what people typed. A post holds at most 4,000 characters. An archived project takes no posts.

​
Plan updated

A steer often means the crew’s standing work should change: a different instruction, a different schedule, different tools. The Chief of staff can propose those changes to the project’s automations, and what happens next depends on who wrote the automation.
  • By Attensira (created when the project was set up): the change is made under the run’s approval mode, the stricter of the workspace’s and the project’s. In Ask it waits for your yes; otherwise it is applied. Every applied change posts a Plan updated line saying what changed: the instruction before and after, the schedule, the tools, or that the automation was paused. Show the change expands it.
  • By you: nothing is changed. The Chief of staff shows the change as a card, and it is applied only when you confirm it.
Turning an automation back on is always your call, whoever wrote it. The Chief of staff cannot give an automation a tool that needs a stricter approval than anything it can reach today, and it cannot change the project’s approval mode, its cap or its direction. Those are yours, in the project’s settings and your own steers.

​
The project panel

Beside the feed, the panel has three tabs:
  • Open work: everything this project raised that waits on you or is moving. The same rows are in the Inbox.
  • Deliverables: what the project’s runs shipped, with where each one lives.
  • Automations: the crew’s automations, each with its author (By Attensira or By you), whether it is on, and the first tools it may reach for. Each opens the automation’s page, where it can be edited and tested.
Below 1280 pixels wide, the panel opens from a button in the header.

​
Project settings

Open Settings in the project header. Changes are saved only when the server confirms them; a refused change says why and saves nothing.

​
The monthly cap

A project can have a monthly cap of its own, in dollars, to the cent. Empty means no cap of its own: the workspace’s limits apply. The cap is a budget for the crew’s work in a month. It bounds what the crew spends, and it is not a promise of a result. Only an org admin can change a project’s cap, here or in billing settings; both edit the same cap. The settings show what the project has spent this month against it. When the project reaches its cap, its new work stops until the month turns or the cap is raised:
  • its scheduled and event runs do not start, and Test is refused;
  • the Chief of staff does not start on new posts either. Your post is saved, the feed says the reply could not start, and a steer is still kept as direction;
  • the feed gets one line for the month, such as “This project reached its monthly cap of $400.00 for October, so its scheduled and event work is paused. It resumes on November 1, or as soon as the project’s cap is raised in billing settings.”;
  • the Inbox gets one row, Scheduled work is paused: this project reached its monthly cap, naming the scheduled automations that did not run, with a Raise cap button. It closes itself once a run of that project is paid for again.
A run already under way always finishes, so a month can go over the cap by at most one run. Months are calendar months in UTC. See Credits for how the project cap sits beside the workspace’s.

​
Paused and archived projects

A paused project’s automations are off until it is resumed; anything you post to it still gets an answer. Resuming turns back on only the automations the pause turned off. An archived project is hidden from the sidebar, its automations are off, and its feed, runs and slug are kept as they were. It takes no posts until it is resumed. An automation whose project is paused or archived does not run, and a test of it is refused too. If we cannot read the project’s state when a run is due, the run is refused rather than risk spending on a project you stopped. A scheduled or event run skipped for any of these shows in loop health, with the reason work_area_inactive (paused or archived), work_area_unreadable (its state could not be read) or work_area_cap (at its cap). A refused test says why when you press Test.

​
Who sees a project

Everyone in the workspace sees every project in it. There are no per-project permissions. Unread counts and the New since you last looked marker are per person.

​
Projects, automations and the API

The workspace’s Automations page still lists every automation. Once the workspace has a project, a Project column says which project each belongs to, and a project’s automation opens inside its project. Over MCP, these tools reach projects:
  • list_projects lists the workspace’s projects, leaving out archived ones: each one’s id, slug, name, status, crew, goal, unread and needs-you counts, whether its crew is running, its autonomy and its budget_cap_usd (null when it has no cap of its own). With id it reads one project instead, adding its direction, its triggers, its automation_ids and the newest 50 lines of its feed, newest first. A read key is enough.
  • steer_project takes a project’s id and your text, at most 4,000 characters, and does what Steer does in the dashboard: the text is kept word for word as the project’s direction, posted to its feed, and answered by a Chief of staff run, which is paid work. It changes no setting and approves nothing, whatever the text says. It needs a read-and-write key. Pass an idempotency_key so a retry posts nothing twice; the same key with different text is refused.
Creating a project, its settings, and pausing or archiving it are in the dashboard only. The REST API has the same reads and the steer under /v1/work-areas: GET /v1/work-areas, GET /v1/work-areas/{id} and POST /v1/work-areas/{id}/steer. A project’s runs and automations still appear in list_sessions and list_automations like any other. Where a payload refers to a project it says work_area_id, because project already means the workspace on every tool and endpoint.