Packs

Route work through four layers

The data layer contains tables and crm. Tables builds a scored working list from sources, columns, and row enrichment. CRM manages canonical records that are already saved in the workspace. This boundary means that an unsaved people search belongs in a workbook and a durable account, opportunity, or deal belongs in CRM.

The knowledge layer contains knowledge and visibility. Knowledge owns Context, documents, briefs, research notes, positioning, ideal customer profiles, personas, competitor intelligence, revisioned vault content, and governed knowledge changes. Visibility owns the evidence that shows how business content is seen, including attribution, SEO, AI answer-engine citations, share of voice, conversion measurement, meetings, and feedback.

The action layer contains sequence, social, workflow, unibox, and tasks. It covers work that changes a draft, a lifecycle, an assigned task, an automation, or an existing conversation. Publishing a social post and launching an outreach sequence are separate action outcomes.

The control layer contains integrations, senders, and workspace. It controls access and durable workspace policy: third-party provider connections, suppression and sender policy, and membership, credits, billing, notifications, and saved views. A control pack does not become the owner of the social, sequence, CRM, or knowledge result that uses it.

Choose by the owned outcome

Ask what durable result is needed, not which familiar product noun appears in the request. A connection behind a record is integrations work, but the record remains CRM work. A suppression is sender-policy work, but the outreach sequence remains sequence work. A reply in an existing thread is Unibox work, while a first outreach attempt is sequence work.

The pack boundaries prevent several common routing errors. Do not use CRM as a disposable prospect list, because tables owns working lists and their sources. Do not use a social pack to measure citations or SEO, because visibility owns measurement. Do not use a workflow to create a cadence, because sequence owns outreach timing and lifecycle. Do not use a sender policy to authorize a provider connection, because integrations owns external provider OAuth and credentials.

A pack can name related capabilities that live under another prefix when the outcome requires them. That does not transfer ownership. For example, a social outcome can surface related auto-engagement controls whose ids begin with sequence.; the scoped search includes the relationship so an agent does not conclude that the feature is absent merely because its identifier uses a neighbouring pack prefix.

In the app, workbooks are under Workbooks, Context is under Knowledge, sequences and workflows are under Automations, Inbox holds existing conversations, Tasks holds assigned work, and connection or sender policy lives in Settings. These locations help a user check the right screen after Architect has routed a goal, but the capability catalog remains the authority for a runnable operation.

I need to stop future outreach to acme.example, then inspect the current sequence for its contacts. Route each outcome to its owning pack and show the exact capability contracts before changing anything.

Pack control reference

packs_list is the index and packs_get is the full document. The list deliberately omits the complete capability array so the response foregrounds pack ids instead of burying routing metadata in a large catalog response. Use get after list when the agent needs the complete capabilities and skill briefs for one pack.

packs_route accepts one trimmed, non-empty goal. It returns an owning pack_id when the outcome has one, or a null route when no pack owns it. Route is a recommendation based on the current pack catalog, not an authorization decision and not a substitute for searching the capability catalog.

CLI commands are dreamstate packs list, dreamstate packs get <pack_id>, and dreamstate packs route --goal <text>. Each accepts optional --json-output or --json. The parser accepts no additional packs-specific flag. Its route form requires --goal, while get requires one positional pack id.

MCP uses strict empty input for packs_list, a strict object containing pack_id for packs_get, and a strict object containing goal for packs_route. Unknown fields are not part of these contracts. A missing pack responds with the canonical not_found error and a Pack not found message.

Skills teach practice, capabilities grant authority

A skill is practical guidance for a job. It can explain how to build a workbook, inspect a conversation, or plan a workflow, but it grants no authority and binds no tool. A pack card can associate skills with a domain, yet the association is not a permission grant and does not turn every skill instruction into an executable.

A capability is the authorization and contract boundary. Search returns candidates, get returns the exact schema, and run executes only a contract delivered in the current turn. The fetched descriptor states its required scopes, action policy, cost policy, asynchronous policy, and supported input and output shapes. Keep the distinction clear when explaining what Architect can advise and what it can actually execute.

Scope a tool search with a pack when the owning domain is known. Architect and MCP use pack_id; REST and CLI tool search use toolset. Without a scope, a goal is ranked against every catalog capability and shared words can surface an unrelated domain. A pack route followed by scoped tool search gives the agent a narrow, explicit starting point.

Packs do not bypass execution safeguards. Mutating calls must name a mode, the server never defaults to live, and paid live work can require a quote and a max_credits ceiling. Owner actions such as provider credentials or billing changes have their separate signed-in security flow. Read the exact capability contract, then use Credits and billing or Owner actions for the relevant boundary.

When it goes wrong

If packs_get returns not_found, call packs_list again and choose one id from the active response. Do not repair the error by guessing an old or human-friendly pack name. Pack ids are lowercase identifiers such as tables, sequence, and workspace.

If route returns no owner, describe the desired durable outcome more clearly and then search the catalog without pretending that an unowned request belongs to a neighbouring pack. A route is deliberately allowed to return null. It gives an agent evidence that it should refine the goal instead of executing the first loosely matching operation.

If a scoped tool search misses an expected result, verify the pack boundary and inspect related capabilities on the pack card. A capability prefix and an outcome owner can differ for a documented related capability. If the searched capability is not delivered in the current turn, search or get it again before run; otherwise the runtime returns capability_not_fetched with the required repair.

If the route is correct but execution fails, investigate the exact capability rather than changing packs. A missing provider connection belongs to integrations, a suppression belongs to senders, and an existing thread belongs to Unibox. A schema validation, cost quote, required mode, or required-scope failure belongs to the fetched contract and has to be repaired with the fields and state that contract names.

If a user asks for several outcomes at once, route them independently before combining them in a plan. A workbook can supply the audience for a sequence, a sequence can create work for tasks, and a workflow can coordinate an outcome, but those connections do not remove the ownership boundaries. Check each created object in its own app surface and keep each capability result with the run that returned it.

Use the pack id from the current response, then retain the returned result identifiers for later reads.

The result can also carry a web_url for the corresponding object in the app.