Chat & proposals
Project chat, agent conversations, lifecycle, and the proposal approval flow.
Chat & proposals
Project chat is where humans and configured agents discuss work in persistent conversations. Proposals are the approval gate for agent-suggested changes to tickets, knowledge, configuration, and relationships.
Project chat
Each conversation is bound to one agent at creation (OpenRouter, Cursor Cloud, or Claude Managed when chat capability is enabled). Messages stream or poll depending on provider; assistant output is saved on the conversation.
For Cursor Cloud, if the live stream ends while Cursor is still running, the chat shows Waiting for Cursor to finish and keeps reconciling in the background until Cursor reports a final result. Reload result can still pick up a late terminal answer without resending your message.
Chat can:
- Answer questions with project context
- Propose ticket drafts, comments, knowledge updates, and ticket links
- Include pinned knowledge when starting a conversation
Global chat agents appear only when an active installed content module provides them. Project-local chat agents are always available in their project.
Routes include project chat lists, and a cross-project chat launcher in the dashboard header. New chat and New helper chat from that launcher open conversations in an in-app modal overlay without navigating away from your current page.
Titles: New chats start as New conversation and receive an automatic title after your first typed message. Click the title in the thread to rename it.
Visibility: Choose Project (default) or Private when starting a chat. Private chats are visible only to you in lists, search, and agent tools.
Complete and archived lifecycle
Conversations can be marked complete when a thread is finished. Completed chats remain readable. Archived conversations are hidden from default lists but still searchable. Restore archived chats from the archived list.
Extraction candidates
During chat, agents can queue extraction candidates — short guidance about what to extract later. Candidates are conversation-scoped (no message link required). Each candidate has required text and optional plain supporting excerpts. Users select candidates and run focused extraction, which uses the bound agent's proposal workflow without a chat reply.
Conversational voice mode
In a chat thread, Start conversational mode keeps the microphone open until you end it. Dictation appears in the composer (you can edit before sending). Spoken commands include wait / hold on / don't send yet (pause auto-send), send / send now, and cancel / scratch that / never mind (clear the draft). Configure send timing and how the mic behaves during assistant replies under Account settings → Voice (/settings/account).
Proposals
Agents do not silently mutate tickets or knowledge. They call MCP propose tools; humans approve or reject in:
- Project → Proposals for project-scoped items (sidebar link for ticket managers; shows pending count)
- Platform → Proposals for global configuration proposals
Contextual Proposals panel
On ticket detail and scheduled task run detail, a Proposals panel toggle appears for ticket managers when pending agent-run proposals exist on that ticket or run. Review and approve without leaving the page.
Approved proposals apply the change; rejected or superseded proposals leave the system unchanged. Multiple pending creates each get distinct proposal IDs; updates supersede older pending rows for the same resource.
Agents can inspect and reject their own pending proposals in the current chat or run via MCP get_proposal_status, list_proposal_status, and reject_proposal. reject_proposal returns actionable text when a proposal is no longer pending (for example already approved or rejected). Configuration proposals may use same-context @ref:<alias> on module-action, project-template, and project-module fields; dependents stay Blocked until prerequisites are approved and cascade-reject when a prerequisite is rejected. Ticket drafts require a non-empty description; replacesProposalId supersedes an earlier pending draft in the same conversation. Ticket comment proposals are rejected at propose time when the target ticket is missing, archived, or in another project. Successful propose_* calls may return warnings[] only for fields that are truly unused by the tool schema (not for valid action-specific inputs on workflow tools).
Approve all on a connected set is all-or-nothing: if any item would fail, nothing is applied. Standard configuration proposals approve atomically — a failed validation or apply leaves every proposal pending and makes no catalog changes. GitHub sign-in and secret-entry configuration steps still require the full review page and are excluded from mass approve.
Configuration proposals from ArxDeck Helper follow the same flow and appear in History only after a successful approval — see Configuration revision history. Reviews show readable content diffs for workflow task-template steps, automation and field settings, scheduled-task steps, webhook extractions/tasks/routes, and project-template module lists (not counts only).
Setup & configuration
- Enable Use in project chat on agents that should appear in the new-chat picker
- Configure MCP allowlists so chat agents can read tickets, knowledge, and propose changes
- Review the Proposals inbox regularly when agents are active
Organization OpenRouter credentials (or platform defaults) power OpenRouter chat agents. See OpenRouter setup, Cursor Cloud setup, and Claude Managed setup.