Architect

Ask for the outcome and constraints

A good request names the desired workspace result, the relevant business context, and any boundary that matters. For example, ask for a small scored worksheet sample rather than a generic people search. Lists only exist in a workbook, so the agent can create or use a workbook, attach one row source to a worksheet, and add columns that provide evidence or scoring.

Tell Architect what should not happen in the same request. A first session can build Context and a worksheet sample without sending, enrolling, publishing, or looking up contact data. A missing sender or LinkedIn account does not block that building work; it blocks the later step that needs the connection.

Confirm this workspace, read Context, create a small worksheet sample for our ideal customer, and do not send, enroll, publish, or look up contact data.

Use the app's Context screen to review facts before the agent treats them as a premise. Context is revisioned Markdown knowledge attributed to the member and client that wrote it. This is the place to keep product, ideal-customer, competitor, and tone facts that a sourcing or writing task needs.

Ask one clarifying question only when two reasonable readings would produce different saved work. Otherwise, prefer a small first result that you can inspect. This keeps discovery concrete and gives the next prompt a workspace object, source, result, or error to refer to.

Architect routes, searches, and checks contracts

Architect first identifies the pack that owns the job, then may load a skill that teaches the practice. A pack routes work and defines its boundary. A skill teaches an operating method, but neither a pack nor a skill grants authority. The exact capability contract controls the inputs, execution mode, cost policy, and scopes.

It uses the thirteen shared controls: identity, packs, skills, tool search, exact tool lookup, execution, and run inspection or cancellation. Search returns a turn token and matching runnable contracts. If a matching contract was already fetched, it can be run in that turn; otherwise Architect retrieves the exact contract before execution.

This is why a vague job can still become a precise action. It also prevents an earlier identifier from being treated as valid for a new request. The server returns capability_not_fetched if the contract was not delivered in the current turn, with repair information that tells the caller to search or get the schema.

Follow the plan and progress

Architect shows its plan as a checklist while it works. The checklist control is named plan_update inside Architect only. It is not part of the thirteen shared controls, so it does not add an extra CLI, MCP, or REST endpoint. Treat it as a visible progress aid rather than a separate execution authority.

Check each saved object after the relevant step. For a worksheet, inspect the source filters, evidence column, score rule, sample rows, and their reasons. If fewer than half of a first sample look right, change the source filter and run another small sample rather than adding more columns. For an asynchronous operation, inspect the run, its events, state, and receipt before you ask for a retry or cancellation.

Show the checklist, the saved worksheet, its sample rows, and the run result. If the sample is wrong, adjust only the source filter and validate another small sample.

State-bearing responses can include web_url. Follow it to the exact object in the web app, while retaining the JSON id as the source of truth. The link lets you review the same workspace result with a teammate instead of re-creating a copy from the conversation.

A completed checklist is not the final check. Read back what was created or changed and use a preview, test, or run output where it is available. Report the concrete result and any remaining blocker rather than only reporting that a capability call was made.

When it goes wrong

Mutating work must name a mode. Architect uses smoke_test for static schema and policy inspection, dry_run for validation against workspace state without business writes, provider spend, or outward action, and live to execute. A missing mode returns mode_required, so state the desired validation or live outcome rather than assuming the agent will choose one.

A live paid operation can return quote_required with an estimate. Architect can rerun the unchanged parameters with a max_credits ceiling. Within the server's row and provider-spend limit that ceiling is the only gate. Above it, or for a recurring trigger, the server answersapproval_required and the person approves on the proposal card in the app; Architect never sets approved. MCP and CLI callers send approved: trueonly after the user says yes. Use dry run when you need a real-state check without an outward effect.

Preserve the error code, message, repair, and trace details in a follow-up request. Ask Architect to inspect the failed run or the missing condition, correct the specific input, and verify the saved result. See Runs for run inspection and Owner actions for the security exception.

Do not try to compensate for an error by switching to another door. Architect, CLI, MCP, and REST share the same contract, workspace boundary, and capability rules. A repair found in Architect therefore describes the same missing schema, mode, or quote condition that a script would need to fix.

Keep the prompt attached to the workspace object you inspected. That gives the next turn a clear subject.

Open the saved object before you continue.