Inbox

Inbox handles messages and replies inside existing conversations.

Inbox is where you read and reply in existing conversations. Use it after an inbound reply, not to begin net-new outreach. The app screen is /dashboard/unibox, and a reply belongs to the existing thread rather than a new sequence enrollment.

Architect uses the inbox-replies skill to understand conversation context. It uses the unibox pack for the actual reads and reply action, while sequences remain responsible for outreach cadence.

Read thread context first

unibox.context.threads_list lists LinkedIn DM conversations newest first. It is free and synchronous. The result does not contain status or assignee because those are stored separately.

Thread field	Meaning
`id`	The provider conversation URN.
`contact_id`	The linked contact identifier.
`unread_count`	The number of unread messages.
`last_message_at and last_message_preview`	The newest-message ordering information.

unibox.context.thread_messages reads the selected thread newest first. Each message has an id, direction, body, and sent time. It does not return a sender profile, attachments, or triage classification.

List the newest unanswered LinkedIn threads, read the full messages in the selected thread, and draft a reply. Do not send it.

Draft before sending

Read the complete returned thread before asking Architect to draft a reply. Check the recipient, the actual message history, and the sender identity in Inbox. A draft is a chance to correct tone or facts before the external action.

Send a thread reply

unibox.context.thread_reply_send is asynchronous and returns status, account_id, remaining_capacity, message, and provider_receipt after acceptance.

Use the full thread context

Inbox is for existing conversations, not net-new outreach. Start with unibox.context.threads_list to find the newest LinkedIn DM conversations, then read unibox.context.thread_messages for the selected thread. The message read is ordered newest first and returns message id, direction, body, and sent time.

Architect uses the inbox-replies skill to interpret the request and the unibox pack for the actual reads. The skill teaches how to reply in context, while the fetched capability schema governs the thread identifier and any send input. In the app, compare the returned messages with the selected conversation before asking for a draft.

The thread contract does not promise a sender profile, attachments, or triage classification. Use the returned conversation facts instead of inventing missing context. If a person, account, or related Record needs separate investigation, keep the thread read as the evidence for what was actually said.

Draft without delivery

Ask Architect to draft a reply without sending it when you need to review tone, facts, or the requested next step. A draft preserves the distinction between reading a LinkedIn conversation and taking a provider action. Check the recipient, message history, sender identity shown in Inbox, and draft text before you request live delivery.

Use Modes to understand the execution choice for a capability. A dry run validates and previews without business writes, provider spend, or outward actions when the contract supports it. Live is the only mode that can perform the reply action described by the fetched contract.

Inbox complements, but does not replace, a Sequence. A Sequence manages a paced outreach journey, while a reply belongs to an existing thread. Read Sequences and enrollment when the question is about an audience journey rather than a response to one person.

Check the send result

The reply-send capability is asynchronous. Its accepted result reports status, account id, remaining capacity, message, and provider receipt. Keep that response with the conversation, because it records the account context and the provider-facing result of the send request.

If the action returns a Run, inspect the Run instead of sending the reply a second time. A Run records completed and incomplete work and can have more event pages. The Inbox thread is the conversation view, while the Run is the execution record for work that was accepted.

A reply can reach a real person and there is no unsend. Treat the returned provider receipt as evidence of the provider request, then review the thread and Run if you need to determine the resulting state. Do not assume that a draft or a request receipt is equivalent to a delivered message.

When Inbox work fails

Search before selecting a capability and fetch its schema before running it. If thread data is incomplete, the contract does not promise sender profiles or attachments, so use the returned conversation facts rather than inferring them. Keep an unsent draft when the external send cannot proceed.

If sending cannot proceed, preserve the draft and resolve the missing connection or capacity issue in the relevant app settings before retrying. Fetch the current send contract again when its schema came from another turn. This avoids applying a stale input shape to an active conversation.

Start

What is Dreamstate - Dreamstate runs GTM work in one workspace across the web app, Architect, CLI, MCP, and REST.
Quickstart - Connect through Architect, the CLI, or MCP, then ask Dreamstate for the outcome you want.

Guides

Your first session - Build a first workbook from workspace context and a sourcing plan.
Warm network first - Turn post engagement into a worksheet and a sequence.
Run a 50-lead outbound pilot - Build a worksheet, validate a sequence, and prepare a small outbound pilot.
Build a founder posting system - Create a social drafting and scheduling system from workspace context.
Turn replies into meetings - Use Inbox context and CRM records to draft follow-up work.
Run a visibility sprint - Measure visibility evidence and save useful findings in Context.
Speed to lead - Build a workflow that connects worksheet, sequence, and trigger work.
Weekly review - Review runs, sequence activity, worksheets, and credit activity every week.
Set up cold email infrastructure - Prepare a separate sending domain, two mailboxes, DNS readiness, and warm-up checks before outbound.
Migrate one Clay table - Import one Clay table, rebuild columns, review ten pilot rows, and compare per-row cost.
Prioritize identified website visitors - Add identified visitors to CRM context and read a daily ranked contact queue.
30-day GTM review - Review monthly spend, campaign results, failed-run causes, and one verdict per live motion.
Launch a client workspace - Set up client context, review three plays, and quote first paid step.
Clean up a worksheet - Use worksheet state and provenance to clean up working rows.
Keep the CRM clean - Maintain saved records and their relationships in the workspace.
Find out why something failed - Inspect workflow, worksheet, and sequence evidence to diagnose a failed run.

Surfaces

Web app and deep links - Use web links in results to open exact Dreamstate objects in the app.
Architect - Architect works in the app with packs, skills, and the same controls used by other surfaces.
CLI - Use the dreamstate CLI to authenticate, select workspaces, and discover capabilities.
CLI reference - Review Dreamstate CLI commands and their documented syntax.
MCP server - Connect an MCP client to Dreamstate and use the canonical controls.
MCP reference - Review the controls exposed by the Dreamstate MCP server.
Connect Claude - Connect Claude to Dreamstate MCP with a browser OAuth sign-in.
Connect Claude Code - Connect Claude Code to Dreamstate MCP from the terminal.
Connect ChatGPT - Connect ChatGPT to Dreamstate MCP through a custom connector.
Connect Codex - Connect Codex to Dreamstate MCP with config.toml and OAuth.
Connect Cursor - Connect Cursor to Dreamstate MCP as a remote MCP server.
Other MCP clients - Connect another MCP client to Dreamstate with OAuth or an API key header.
REST API - Use the REST API to search tools, read schemas, run tools, and inspect runs.
Agent clients - Choose a Dreamstate MCP connection guide for Claude, ChatGPT, Codex, Cursor, or another client.

Workspace

Workspaces, members and roles - A workspace defines membership, permissions, billing, and the data boundary for work.
API keys and scopes - Use workspace API keys with explicit scopes and workspace boundaries.
Agency workspaces - Use Agency to manage client workspace work.
Tags, comments and saved views - Use workspace tags, comments, and saved views to organize shared work.

Knowledge

Context - Context stores revisioned Markdown documents attributed to the member and client that wrote them.
Skills - Skills teach practice and do not grant authority or bind tools.
Notes, inspiration and bookmarks - Use research screens for notes, inspiration, and bookmarks.
AI visibility and analytics - Use AI visibility analytics to measure business content evidence.

Data

Workbooks and worksheets - A workbook contains worksheets, each with one row source, columns, and optional score.
Row sources - A worksheet uses one row source to provide its working rows.
Columns - Columns enrich and judge rows in a worksheet.
Cells and provenance - Cells hold row values and their available run provenance.
CRM records - CRM stores canonical records already saved in the workspace.

Execution

Modes - Mutating calls name a mode and the server does not default to live work.
Runs - Runs record execution work and can expose links to exact app objects.
Sequences and enrollment - Sequences separate drafting, validation, publishing, enrollment, starting, delivery, and replies.
Workflows and triggers - Workflows organize automation graphs with scheduled and event triggers.
Social posts and publishing - Social work covers drafts, schedules, publish actions, accounts, and performance analytics.
Inbox - Inbox handles messages and replies inside existing conversations.
Tasks - Tasks manage assigned work, due dates, delegation, and review state.

Providers

Packs - Packs route work by domain and explain what each domain owns.
The tool catalog - Search the tool catalog, read an exact schema, then run a capability.
Integrations - Integrations manages third-party connections and connection diagnostics.
Senders and mailboxes - Senders manages suppression, mailbox health, sender identities, and sender policy.
Data providers and costs - Data providers can require a connection or your own key before they can run.

Plays and templates

Plays - A play is an advisory order of steps toward one outcome.
Blueprints and the marketplace - A blueprint installs a workspace system and supports saved snapshots.
Reply playbooks - Reply playbooks provide Inbox guidance for scenarios and sequence rules.

Safety and cost

Credits and billing - Credits and billing are managed at the workspace boundary.
Spend caps and budgets - Paid work can use a quote and a maximum credits ceiling.
Sending safety - Sequence work keeps publishing, enrolling, starting, delivery, and replies separate.
Do not contact - Do not contact rules suppress future outbound messages across channels.
Owner actions - Owner actions use signed-in sessions, fresh approval, and idempotency keys for sensitive workspace changes.

API reference

Capability ids and naming - Capability ids identify catalog operations across the Dreamstate surfaces.
Envelope and errors - The canonical envelope communicates success and failure information.
Pagination - Pagination uses cursors to traverse collections.
Rate limits - Rate limits describe request limits for API use.
Idempotency - Idempotency keys make owner action requests safe to retry.
Webhooks - Webhooks deliver signed workspace event callbacks.
OpenAPI explorer - OpenAPI shows generated request and response schemas for Dreamstate operations.