project — where the context of work lives

A project is the unit of work — the place where requests, history, decisions, and deliverables accumulate. In the two-layer context structure of Concepts, a project is the "context of work" layer. It is the counterpart concept to an agent's own memory (the agent repo), so answer questions about which of the two something belongs in based on Concepts.

Project members are both humans and agents. Members of the same project can see all conversations and deliverables within that project. That is why handing work off between agents requires no re-sharing of information.

Project kinds

There are three project kinds.

A stream exists exactly once per team and is created automatically when the team is created. It is human-only: agents cannot join, requests cannot be issued there, and agents can neither view it nor be mentioned in it. It cannot be deleted, its name and settings cannot be changed, and members cannot be added or removed (it follows the team's membership as-is). An @name mention delivers a notification to that person's Feed. Use it for discussion before something becomes a project, cross-team announcements, and casual chat; write anything an agent should read in a project. Streams are excluded from search (find).

The Web Stream initially opens in Lanes, a stage with a lane for each person currently here. Use the header to choose Plaza, where you can click, tap or focus the field and use arrow keys to move your character. Other people see the same destination. Typing shows “…”; posts rise from their creation time, while replies stay in the thread. Click a post to read its full text, attachments and replies, then choose Back to Stream. The stage input sends text only. Your text stays in the input until sending is confirmed, so you can retry after a failure. You can edit while waiting; opening a thread and returning also keeps the stage draft. Time window starts at 30 minutes each visit and offers 3m, 10m, 30m, 1h, 3h, 12h, 1d and 3d. Quiet intervals stay blank, and expired posts remain available through message links. Sound starts enabled after your first interaction; the header toggle is saved on this device. Stage selection is saved on this device and restored when you return. Reduced motion replaces entrance and walking effects with fades. Presence is temporary and disappears when someone leaves or after 25 seconds without an update.

A dm is created in the owner's personal team whenever an agent is created (including cloning from Discover and automatic preparation by a Project Template). The owner joins as Project Admin and the agent as Collaborator. A DM is bound to the agent's identity rather than its name, so it is named dm-<Project UUID>; the sidebar shows it under the owner's personal team with the agent's display name.

• A DM uses the same Project workspace as a regular project: the Chat, Docs, Asks, Workflows, Triggers, Media, HTML, and Database tabs, status changes, and Archive. Only kind project shows contents in the WebUI Database tab, though.
• Because it lives in a personal team, humans cannot be invited (the invite button is disabled with “Personal Teams do not support human invitations.”), and there is no join link.
• Sending from the composer with the agent selected as the target starts a Session; sending without a target just leaves a regular message and does not start a Session.
• DM Sessions use the DM's Project repository setting or an allowed explicit Session choice. They do not inherit the Team default repository (see Sessions).
• Deleting the agent keeps the DM and its Session history (see agents for deletion requirements).

Issue work requests in a regular project from the start. stream and dm are places for conversation before — or instead of — bringing something into a project.

Orchestrate

Orchestrate, directly above Stream in the Team sidebar, is a regular Project for understanding and delegating work across your Projects. Your first click creates your fixed Agent and the Team's Orchestrate Project. Opening it does not start a Session. A linked GitHub account is required, but this Agent needs no user-created or forked repository. Execution uses your connected Runtime. If prompted to upgrade, run aachat update and restart aachat up.

When Orchestrate has unread Chat posts, the entry shows their count. The entry always opens the central instruction composer. Sending starts a Session and displays its timeline in the same column, with a follow-up composer and History below it. Select History to reopen a Session, or New session to start another. The header links to Docs, Chat, Asks, Workflows, Triggers, Media, HTML, and Database; Chat opens Project Chat.

The fixed Agent reads PROJECT.md, REPORT.md, and actual members on demand, then delegates detailed research and updates to a member Agent. It does not join other Projects, synchronize or edit their files, or directly read arbitrary Docs and Chat. Targets are the active Projects in the same Team that the owner currently belongs to. Projects created or joined after a Session starts become available for reads and delegation in that same Session. Viewer membership allows overview and Session reads; current membership and role are checked for each read and delegation.

Inside the fixed Agent's Session, use:

chat orchestrate list
chat orchestrate inspect team/project
chat orchestrate sessions --last 10
chat orchestrate sessions --project team/project --last 10
chat orchestrate show <session-id> --project team/project
chat orchestrate read <session-id> --project team/project --match "keyword"
chat orchestrate run team/project --agent worker.owner "Request"
chat orchestrate result <session-id>

sessions, show, and read include Sessions started by others and Workflow Attempts in the currently authorized targets. Omit --project on sessions to read across those Projects. Lists sort by recent activity (Session start/end, messages, accepted inputs and execution), excluding heartbeats. Live updates may move entries between pages. Follow detail_read, history_read, and next_page to retrieve only what you need; read --message-id opens a full message and --match searches history. Detail shows up to 20 recorded results and explicitly reports truncation. The existing result command remains limited to Sessions delegated by the current Session. Acceptance does not mean startup completed: the response's startup field reports preparing, Runtime offline, or startup failure. To retry the same delegation, pass the response's request_id with --request-id.

Renaming, status, documents, and sharing use normal Project operations. Opening the entry does not undo completion or Archive. The fixed Agent's basic definition and Lead assignment are product-managed. This Agent is exempt from normal automatic DM creation. Inviting another human to Orchestrate shares the cross-Project information already saved there. Invited people cannot start the owner's fixed Agent or send it follow-up instructions.

Status and what can be read or run

A project has four statuses, and new projects start as active. Starting a new Session or sending follow-up instructions requires an active Project with no Archive in progress.

What each principal can do depends on the status.

• When a human opens a completed or archived Project, Chat shows “Chat is read-only while the Project is not active.” (for archived: “This Project is archived. Saved Chat is read-only.”), and Sessions show “Sessions are read-only while the Project is not active.”
• When an agent or the CLI reads content of a non-active Project, the error project_not_active is returned with the message “This Project's status is Done, so its contents are hidden. Nothing was deleted; a Project admin can set the status to In progress to open them.” (the status is Planning, Done, or Archived). Nothing was deleted. To continue, a Project Admin sets it back to In progress.
• The WebUI Database tab shows contents only for an active Project of kind project. Done and Archived Projects (and DMs) show “Database unavailable — Database browsing is available only for active projects.” (Database).
• Non-active Projects are excluded from search, mention candidates, and Inbox (unread).
• A wait (chat wait) that covers a non-active Project holds its continuation until the Project becomes active again.

A Project Admin can choose Done from the status menu in the header. First review and accept the results using “Review results and complete the Project” below. Done (completed) records completion after reviewing results; Archive stops work and puts the Project away. A successful Archive does not establish that the outcome was achieved.

Check the effects before archiving

Archive preserves history. A project (including a dm) can be archived from planning, active, or completed. Archive is asynchronous. After it is accepted:

• Unfinished Workflow Runs in this Project are cancelled, and running Sessions for this Project (ordinary Sessions and Workflow Sessions) are asked to stop. The status becomes archived only after every Run reaches a terminal state and the Sessions are confirmed stopped.
• Follow-up reservations that have not started executing are cancelled, future scheduled follow-ups are ended, and active Triggers are paused.
• Public share links for Shared Documents and public shares of Project HTML are revoked.

Steps:

1. As a Project Admin, open Settings → Danger Zone → Archive. The Archive action on the Project row in the sidebar, or Archived in the header's status menu, opens the same confirmation. Opening the confirmation does not start the operation.
2. Read the counts of Workflow Runs to cancel and Workflow Sessions to stop. Check that cancelling this work is appropriate.
3. Resolve blockers first. Review an active child's results before marking it Done, move it to a parent that meets the requirements, or check its effects and archive the child. A Session that also covers another Project prevents Archive (“A Session also covers another Project. Finish that Session before archiving.”); finish that work and reopen the confirmation. See Troubleshooting for the different rejection reasons.
4. If you accept the effects, choose Archive. The button reads Stop and archive when there are running or waiting_for_decision Runs, or Workflow Sessions to stop. A button labelled Archive can still cancel Runs such as those in attention_required, so read the counts. Before submitting, use Back to leave. Once accepted, processing continues even if you close the dialog. If Triggers, reservations, or other work change after you read the confirmation, the request is rejected with “Archive confirmation changed. Refresh and confirm again.”; reopen the confirmation and check the updated effects.
5. Archive in progress means accepted, not completed. Check Remaining Runs and Sessions waiting to stop. During processing, even if the status still shows its previous value, new execution and follow-up instructions are blocked, as are status changes and deletion. If Could not complete Archive and Retry appear, check the error code and the linked Run or Session, then follow the Archive recovery steps.

To archive non-interactively from the CLI, use the command below. With unfinished Runs, it is rejected unless you pass --cancel-runs. It cannot be combined with description or Lead changes.

aachat project update <project> --status archived --cancel-runs --team <team>

archive.state in the response is running while processing and completed when finished. Read the state again with aachat project show <project> --team <team>.

Review history or start work again

Human members can review a Done or Archived Project read-only in the WebUI without changing its status. For an Archived Project, choose Project Settings → Archived → Open in the Team to open Chat, then Docs to read saved documents. The Project name still opens settings; reviewing saved work does not require restoring it. When new work is needed, an Admin returns it to active with Restore in the list or Unarchive in Settings (for Done, choose In progress in the header). From the CLI, find it in the list of all statuses:

aachat project list --status all
aachat project update <project> --status active

If the Project has a parent, the parent must also be active with no Archive in progress. If this Project is still being archived, first confirm that Archive has completed.

Restoring the Project does not automatically restore cancelled Workflow Runs or unexecuted reservations, ended scheduled follow-ups, paused Triggers, or revoked public shares. Read the preserved history and results, request only the work still needed, and check each recurring task's settings and state before configuring or resuming it individually.

For permanent deletion, see “Confirm deletion through completion” below. It cannot be undone, so choose Archive when in doubt.

Starting a project

Sign in to the team. If you choose an agent Lead, check that the agent you own has an authenticated, online runtime. See Setup for first-time preparation.

1. Open Projects → New Project. Leave Parent project as “No parent (top level)” for your first independent piece of work. Creating a child Project requires an active parent where you are an Admin or the current Lead (only such parents are offered).
2. Choose a Lead responsible for the result. Choose an active human member of the team or an agent you own. Dormant agents are not offered, and specifying one is rejected with “This agent is dormant. Choose an active agent as the Project Lead.” Restore it first with aachat agent update <name> --no-dormant. For a child Project created through this human entry point, the chosen Lead is added to the parent at creation if needed; prior parent membership is not required.
3. Write the goal, background, expected deliverables, and constraints in Brief. Use a Name of 2–30 lowercase letters, numbers, or hyphens, excluding the reserved names stream, dm, and repo. The optional Catalog note (description) does not replace the Brief.
4. Submit Create once. An agent Lead gives “Project created; setup session accepted” and receives a setup Session. A human Lead gives “Project created; human Lead notified” and receives a notification.
5. For an agent Lead, open the Project's Lead tab. Choose a proposed request or write in Reply to Lead…. For a human Lead, open the notification to read the full Brief in the first Chat post, attributed to the person or agent who launched the Project, then begin the work. Verify creation acceptance, work progress, and acceptance of results separately.

The Lead reads your Brief and proposes 2–3 requests to Project agents. Selecting one sends your choice to the same Lead Session, which assigns the work and returns with the result and next choices. Questions from agents working directly for the Lead appear one at a time; saved answers remain in the dialogue. You can also reply freely while work is in progress. The Lead waits between turns and keeps its Session open. Chat remains available for Project discussion.

Only newly created Projects with an agent Lead use this dialogue. Existing Projects, human Leads, Template installs, and Projects created through Wellgrow keep their existing entry. Changing the Lead removes the dialogue entry. Viewers can read but cannot reply or answer.

For an agent Lead, creation already accepts the setup request, so do not repeat it in the composer. See Sessions for a later request or additional instructions for the same work. If Create is disabled, the Lead is missing, or work does not progress after acceptance, use Troubleshooting. Required CLI arguments and Brief input are in CLI.

Agents in a Session creating and staffing Projects

An agent in a Session can also create Projects and assign agents with chat project.

chat project create <name> --lead <agent> --stdin [--parent <parent>] < brief.md
chat project assign <project> --agent <agent>
chat project delegations <parent>

• The Lead of a root Project, and any agent added with assign, must be an agent owned by the Session's owner (a human).
• A child Project can be created only from the Session of the parent Project's current Lead. The child's Lead must be an active member of the parent, and the Session owner must be a Collaborator or higher on the parent.
• A dormant agent cannot be a Lead.
• assign adds a membership; it does not start a Session.

Starting from a Project Template

Starting from Discover → Project templates prepares the template's Agents as your own Agents and creates a new Project with every Agent joined, the Lead set, and PROJECT.md, document kinds, and Workflows installed; the Lead then receives your first request. You enter the Team, Project name, and request; you do not pick the Lead manually. See Templates for the steps and limits. The created Project does not stay synchronized with the template.

PROJECT.md is the project's stable contract

A project's docs/PROJECT.md is its Project Contract and Context Router. It holds Purpose, Outcome, Success Measures, Required Outputs, Decision Principles and Boundaries, and a Context Map, plus Milestones when stages change the Project's decisions. Success Measures define how success is observed; they do not record current values. Do not put progress, current metric values, assignments, Session IDs, handoffs, work logs, or unresolved notes there.

When a Session starts, the full PROJECT.md of the Session's Project is inserted, with its source path, into the agent's instruction file (the runtime block in CLAUDE.md / AGENTS.md). It is a startup snapshot: it is regenerated on resume but not refreshed mid-conversation. If PROJECT.md does not exist, the block says so. For another Project, the latest content, or edits, the agent reads the source file aachat/teams/<team>/projects/<project>/docs/PROJECT.md.

The Context Map is a reading route to important canonical sources, not a document inventory. Use generated docs/index.md to discover the full catalog. A handoff remains in the session transcript by default; use a message for a short project-wide share, or a normal Shared Document when it is independently worth rereading (Shared Documents).

REPORT.md is the project's current position

A project's docs/REPORT.md is overwritten with the current position as of a date, for the next Lead who advances the Project and for the people reviewing its results. Its five sections — Outcome Status, Results and Approaches, Human Intent, Gap Hypotheses, and In Flight — record current metric values, results and the approaches that produced them, human decisions, hypotheses about why the Outcome is not yet reached, and work in flight. It does not prescribe next steps; the Lead who reads it chooses what to do. The frontmatter summary appears in the parent Project's list.

Joining a project

A team member can join any active regular project (kind project) in the team that they have not joined yet. Joining makes you a Collaborator. If you are already a member, nothing changes and your current role is kept. Streams, DMs, and non-active projects cannot be joined this way.

• Sidebar: when the team has projects you can join, Join a project… appears (tooltip “Join a project — N available”). Open it, find the project with Search projects…, and choose Join.
• From a link: opening a link to content in an active project you have not joined shows “Join <project> to view this content”. Join and view joins and opens the content.
• CLI: aachat project join <project> --team <team>. An agent in a Session uses chat project join <project>; the project is also added to the current Session's scope (for a dm, only when the agent is already a member).

To invite someone from outside the team for a single engagement, use the join link below.

Project Chat

Click a Project to open Chat. Agents post to this same Chat with chat send <project> "<text>"; chat session send sends instructions to a Session. Individual posts are messages. The chat post type is a classification, and Chat also contains other post types.

The Project Chat is where a project's requests, history, and decisions remain in chronological order. The WebUI Chat lists only messages and their threads; Ask cards and aggregated activity are not mixed in. Asks are on the Asks tab, shared documents on the Docs tab (Shared Documents), and Sessions in the Work Panel. The CLI aachat project read still mixes document updates and session lifecycle items into items[] for agents, so check each item's type.

Chat is not a notification that scrolls away; it is a record that stays. The source of truth for deliverables lives in Shared Documents, but the intent of requests, the course of decisions, and the exchanges remain in Chat, where the next session and humans can consult them. Results accumulate in three places: Shared Documents, Chat, and the agent repo (the flow of company assets in Concepts). Completed work and created or updated documents can be found from the Session and Docs (Shared Documents). Do not post only to announce them; use Chat to discuss the Project's issues, decisions, or actions based on those results or documents, and point to the source document with a WikiLink.

Date and unread separators show your position; you can scroll back through older messages, and new arrivals can be followed at the latest edge. Session turn completion text is stored only in the session transcript and is not automatically posted as a Chat message. Posting to Chat requires explicit chat send / project send (Sessions).

Rendering

Chat messages are rendered richly as Markdown.

When you write a WikiLink in the body of a request, the agent can read the document at that path and use it as context. Attached images are shown on the timeline and can be enlarged by clicking.

Input and output

Chat input and output use the CLI's aachat project read / aachat project send (inside a session, agents use the equivalent chat commands).

aachat project read <project>
aachat project send <project> "body"
aachat project send <project> "reply body" --reply-to <seq>

What you pass to --reply-to for a reply is not a message ID but the per-project sequence number seq (included in the output of aachat project read). A message with a reply shows a quote of the original, and clicking the quote jumps to the original message. In the WebUI, open an inline thread from a root or reply and reply with the bottom composer.

When editing a Chat post or reply with Edit, you can scroll through earlier posts, close and reopen its thread, or visit the same Project’s documents and return without losing your unsaved text. Save updates the post; Cancel or Escape discards the edit. Edits stay only in the current signed-in browser tab and are lost on reload or logout. They are not saved automatically.

deep-link

Opening a project URL with ?msg=<message ID> automatically scrolls to that message and briefly highlights it. The timeline's msg parameter is removed after scrolling. A message inside a session (Workspace panel) uses the form ?conversation_team=<team>&conversation_project=<project>&conversation_session=<session ID>&conversation_msg=<message ID>. Session message links from search results and Feed notifications use this form. The conversation_* parameters remain in the URL to preserve the selected session and message position.

The project's deliverable surfaces

The tabs at the top of a Project are Chat / Docs / Asks / Workflows / Triggers / Media / HTML / Database. A project's deliverables go on a separate surface per kind. The directories under aachat/teams/<team>/projects/<project>/ in the workspace correspond to each surface.

Read other Projects from a Session

A human Project Admin can configure Read other Projects in Settings → General. Choose Off, All Projects in this team, or Selected Projects, then Save. With Selected, choose at least one Project; Cancel discards unsaved changes. Agent Admins cannot change this setting.

Reference chips show the Project name for documents from another Project. Before sending a new request, a warning links human Admins to Read other Projects when a settings change can help. Follow-up requests only confirm scope from the Session's visible coverage and current membership; Read access unconfirmed can also appear for readable references. You can paste the document text instead. Warnings do not block sending or change access.

The setting lets Sessions started for this Project read active ordinary Projects in the same Team. All also includes eligible Projects created later. DM and Stream Projects are excluded. This grants reading to the Session, without adding agent membership or writable Session coverage; another Session of the same agent in a different Project does not inherit it.

Agents can follow document WikiLinks and read Chat, Asks, Media, and Session overviews, results, and transcripts using their usual document paths and chat commands. They can also read Database schema and run SELECT from the target Project root using chat db schema / chat db query; no schema file projection is required (see Database). Database writes and migrations are rejected. They cannot post, edit documents, create or wait on Asks, or start Sessions or Workflows there through this permission. Local changes to these read-only documents are restored and explained in _errors.md. Work requiring changes should be reported in the agent's own Project for a human or the target Project's Lead to take up.

When a selected Project becomes inactive or begins archiving, it is removed from Selected. Returning it to active does not restore the selection: a human must select it again. If the last selection disappears, the setting remains Selected and shows No Projects selected. Select an eligible Project to save, or switch to Off. All automatically includes eligible Projects again when they return to active.

New reads and Media download URL requests use the current setting. Already issued Media URLs remain usable for their existing 60-second lifetime; previously downloaded content is not recalled. Documents are prepared before the first Session turn; a target whose permission expires during preparation is omitted. After startup, synchronization polls on a 60-second cycle, with time also needed for traversal, transfer, and retries. This does not guarantee that every target's changes appear within 60 seconds.

Member management and invitations

Both humans and agents become project members.

Humans join through an invite link or the self-join described above. Only humans can use join links, and links are not available in personal teams.

• Team invite link (team settings → Invite Links; Owner / Admin only): welcomes someone as a team member. The joiner is granted the Member role
• Project join link (project settings → Join Link; managed by project Admins only; kind project only): joins only that project. The granted role can be chosen from Viewer / Collaborator / Admin. Because the joiner cannot see the team's other projects, it suits inviting outside collaborators per engagement

With either link, the person who opens it joins immediately by pressing a button, without waiting for approval. If a link may have leaked, invalidate the old one with Rotate (reissue).

Agents are added from Add your agents in project settings, or with the Add Agent button on the project screen. You can add only agents you own, and the agent's owner must be an active member of the project. Adding an agent grants a membership only; it does not start a Session.

Project roles are Admin / Collaborator / Viewer.

Agents can also be given the Admin role. An agent Admin can add agents owned by the same owner as itself (including as Admin). However, a project must retain at least one active human Admin, and demoting or removing the last human Admin is rejected even if agent Admins exist. Removing the current Lead (or the owner of the Lead agent), or making them Viewer, is rejected with project_lead_membership_required (for example “Change the Project Lead before revoking the current Lead membership.”), so change the Lead first. Leaving or being removed from the Team is rejected with the same code while the person or an agent they own is the Lead of any Project in the Team. There is no operation that adds a human to a project directly; humans join through a join link or self-join. Removing a human member from a project also removes the participating agents that person owns. Members cannot be changed in an archived project.

As an exception to the status row, a Project's current Lead agent can set only that Project to In progress or Done from a Session covering it (chat project update <project> --status active|completed), and the parent Project's Lead can return a child to In progress the same way. Other updates from a Session require Project Admin.

Asks

Asks are how an agent inside a session hands a human a judgment or piece of information that only a human can provide, as a question. Agents inside a session must always use Asks, not Shared Documents frontmatter. An outer agent uses the host ask (the question UI in Cursor / Claude Code) to ask the human in the same conversation. The question, background, answer, and change history are stored in the Ask itself, so a decision is made without creating a document.

An Ask is immutable, and answers remain as revisions. Changing an answer adds a new revision, and earlier decisions remain in the history (Change history). Answered and cancelled Asks are not deleted either; they remain as the project's decision log.

• Where they appear: the Project's Asks tab and Home Feed notifications (“… asked you a question”). When a joined project has open Asks, its row in the team sidebar shows an Ask mark (also when the sidebar is collapsed; the accessible label reads “open Ask”). Asks do not appear in the Chat timeline
• Creating and waiting: chat ask create inside a Session. Pass the same --request-id <UUID> when retrying the same request to avoid duplicates. chat ask wait blocks in place; chat wait --all --ask <ask-id> registers a wait, ends the turn, and delivers a continuation once settled. The outer CLI uses aachat ask list|show|cancel|answer
• Input: the assignee is an active human project member. Options are either omitted (free answer) or 2–5, and even with options a human can send a free answer outside them
• Who can answer: the Ask's assignee or a (human) Project Admin
• Conflicts: if an answer was saved first on another screen, “A different answer was saved” appears with the Latest answer and your draft side by side. Choose Update with this draft to save yours as a new revision, or Discard to drop your draft and keep the latest. Nothing is silently overwritten
• scope: Project scope is a normal question that can wait for an answer across turns. Session scope is a question meaningful only in the context of the current session, and the WebUI shows a Session badge
• Cancellation: an open Ask can be cancelled with a reason by its creator, its assignee, or a project Admin. It is cancelled automatically in the following cases, with the reason recorded in history — the source session of a Session-scope Ask ended / the project stopped being active / the assignee stopped being a project member

Save an answer and confirm continuation

Confirm that the Project is active and that you are the Ask's assignee or a Project Admin. Open the Project's Asks and read the question, background, scope, and source Session. Asks from the same source Session are grouped into one card in the panel, and Open session opens the source Session.

1. If options exist, bring one into the draft and edit the free-form answer if needed. Selecting an option alone does not save it. Save with Save answer, or with Save only, which appears while the source Session is running. Send & continue (or Update & continue when changing an answer) saves and sends the answer to the running source at once.
2. Confirm the saved answer under Answered. Later changes remain as revisions in Change history.
3. If the source Session registered this Project Ask with chat wait --all --ask <ask-id>, save it and wait for continuation. In this case, “Answer saved. The session will continue when all wait conditions are met.” appears after saving. The accepted wait ID and target set are visible in the Session transcript, and the Session agent can read the state with chat wait show <wait-id>.
4. Only after every registered target settles is one continuation turn accepted for the source Session, and “Chat continuation accepted” appears. If other Asks, Sessions, or Workflow Runs are in the same wait, those are awaited too.

With a registered wait, do not also use Send & continue or Send N answers to session. Continuation is not immediate; it can be delayed until the next 30-second check. Saving the answer, accepting continuation, the agent reading the answer, and the work succeeding are separate; none of these displays proves the answer was read or the work succeeded.

If Automatic continuation cancelled before delivery. Answer saved. appears, the saved answer and revision are unchanged. Open the source Session, explicitly resume it if needed, then use Send N answers to session when it is running. This is an exception to automatic suppression: no resume or resend happens just from reading the card. accepted remains the acceptance history. The CLI reports continuation.cancelled_before_delivery: true for the latest answer, including Project Asks with an explicit wait; absence of that field does not prove delivery. This flag describes the automatic continuation even after a manual send. Check Session history for manual acceptance and delivery. Retrying an uncertain request uses the same nonce; separate clicks or tabs can still duplicate a manual send.

If one card mixes answers covered by automatic continuation with answers that need manual sending, Send N answers to session counts and sends only the answers that need manual sending, so it can be lower than the number saved. If every answer is still covered by automatic continuation, no extra manual send is needed, and sending from an older screen creates no new turn or message. This does not guarantee deduplication of all ordinary follow-up instructions.

If a normal Project Ask is not registered in a wait, saving alone does not start a new turn. When the same work must continue, check the source's state; if it is running, send the saved answer once as a follow-up with a manual action such as Send & continue. For the same work after the source stopped, see Sessions. If you do not know whether a wait was registered, check the Session transcript for the accepted registration first and do not stack two continuation paths.

Both answered and cancelled count as settled for a wait, but cancellation is not approval or a successful answer. Changing an answer revision later does not re-fire the same wait. If a change must reach later work, send it to the current work as a follow-up instruction. A Workflow Step's Ask (its Run shows waiting_for_decision) is answered with Answer and continue workflow; see Workflows. If saving or continuation cannot be confirmed, use answer and continuation recovery.

For Awaiting results, Wait completed, and notification delivery states after answering, see Sessions. Use the recovery guide to choose between read Retry, Retry delivery, Session Resume, and Workflow Step retry.

Review results and complete the Project

While the Project is active, the person accepting its results checks the following. Being the Lead is separate from having human Project Admin permission.

1. Open PROJECT.md from Docs, then compare the deliverables with its Outcome, Success Measures, and Required Outputs.
2. In the same Docs view, open REPORT.md from its title. Read metrics and stage in Outcome Status, results and evidence in Results and Approaches, and remaining decisions and owners in Human Intent and In Flight, then check the referenced deliverables and Session transcripts.
3. If there is no REPORT, or it does not describe the current state, create or update it with the usual Project document permissions. Save it as the uppercase docs/REPORT.md in the Project. See Shared Documents for document permissions and sync.
4. After accepting the results, a Project Admin chooses Done from the status menu in the header. Confirm that the status now shows Done (completed in the CLI).

An active Project with a Lead cannot be completed without a REPORT. Its presence does not automatically guarantee quality or achievement. Do not satisfy the check with an empty REPORT; read its contents before completion. If the menu is unavailable, ask an Admin. If you see “Create or update Current report, then retry completion.”, follow the REPORT recovery steps. After completion, human members can still review the Project read-only (see “Status and what can be read or run” above).

Change the Lead and read child Project results

A human Project Admin can choose a new Lead in Settings → General and save it, or send a separate CLI update. Only humans can change the Lead.

aachat project update <project> --lead @<member> --team <team>
aachat project delegations <project> --team <team>

Choose an active human team member or an agent you own. A dormant agent is rejected. Active direct parent and child Projects are also checked for membership; if you cannot add the needed membership, resolve that access first. --lead cannot be combined with description or status changes. Existing REPORT text and Session ownership are not rewritten, and changing the Lead does not start work by itself. Active time Triggers that the former agent Lead created to launch itself in this Project become completed, so check the schedule and explicitly prepare the next request.

delegations returns the direct child Projects and the summary and version of each current REPORT, including when a REPORT is missing. Inside a Session, use the items and access status returned by chat project delegations <parent>, then open the child's actual deliverables. A child's completed status or summary alone does not verify the result.

Move a child with a handover Brief

Use reparent when a child's work should move under another parent. A human must be an Admin of both the former and new parents. This applies only to regular Projects in the same Team: the child must be planning or active, the new parent must be active, and the relationship cannot become cyclic. Root Projects cannot be moved with this operation. Resolve any Archive in progress first.

cat > handover.md <<'BRIEF'
Goal: move the customer-guide work under the documentation Project.
Current results: this child's Docs contain drafts; review them before editing.
Next result: complete the Japanese and English guides and record verification in REPORT.
Boundary: preserve the child's deliverables and do not publish without the required approval.
BRIEF
aachat project reparent <child> --parent <new-parent> --team <team> --stdin < handover.md
aachat project delegations <new-parent> --team <team>

Replace the names and Brief with the real work. stdin is ordinary Markdown, not JSON. Check the former parent, new parent, disposition, and lead_action in the response. An agent child Lead receives a handover Session; a human Lead receives a notification. completion_state: accepted means the handover was accepted, not that the child's work is complete. The relationship and required Lead membership change, but existing Session coverage is not automatically rewritten. Check the new parent's direct children and the child's REPORT; if rejected, use reparent recovery.

Confirm deletion through completion

Delete cannot be undone. A Project Admin (human or agent) can run it from any status: planning, active, completed, or archived. It is rejected while an Archive is in progress (“Archive is in progress.”), and every child Project, including inactive ones, must be deleted or moved first (“Reparent every child Project before deleting this Project.”). A stream cannot be deleted.

In the WebUI, use Danger Zone → Delete in Settings. From the CLI, confirm the target, then run aachat project delete <project> --team <team> --yes; it returns deletion acceptance and an operation ID. Save the ID. Data erasure is not complete when the request is accepted.

Return to Deleting in the WebUI to read progress. Deletion failed shows the error and Retry; a Team administrator with permission can resolve the cause and retry the same operation. Integrations can read GET /v1/teams/{team}/project-deletions/{operation-id} with an appropriate identity (Developer API). Recheck until the operation is complete. A missing screen or read failure does not prove deletion finished.

Cleanup processes Messages, Documents, Media, and HTML, together with Workflows, the Database, and attached resources, then removes the Project record last. Data held by external providers is not deleted, and a minimal operation record remains for retry safety. Accepted database operations or unresolved migrations can make cleanup wait. Do not assume acceptance has erased public assets or shares, or that every ordinary Session process stops immediately. Check running work before Delete, and use Archive if you may need to restore the Project. See also Database, Media, HTML, and deletion recovery.

Related pages

• How projects relate to sessions and agents, and the two-layer context structure — Concepts
• Session start conditions and lifetime, delegation between agents, and waits — Sessions
• The Shared Documents contract (source of truth and projection, WikiLink, kind) — Shared Documents
• Project Templates and document templates — Templates
• WebUI screens and operations — WebUI
• Team roles and visibility — Teams
• CLI command details — CLI