Ace Work

Get the execution surface for a workflow (documented process): its step-by-step checklist, or a run offer when the workflow is certified for automated execution. Use it when the user wants to do the work ('how do I do X?'), with the workflow id from a search_workflows lookup. If the workflow is certified for autonomous execution, the first call returns a run offer instead of the checklist: ask the user whether to run it now (autonomously or guided together) and call the matching tool only after they choose; pass view='checklist' once the user asks to read the steps or declines a run. Manual, thin, or not-yet-automated workflows return the step-by-step checklist: show it and offer a guided walkthrough with guided_session (action: start) if the user wants one. When presenting steps, copy every returned title exactly, including word order and grammatical voice; do not shorten, paraphrase, or convert titles into commands. Only workflows have checklists — reported workflows that haven't been turned into workflows yet will explain that instead. As they work, capture deviations with log_observation (type: deviation) and total time with log_observation (type: time_taken).

get_workflow_checklist

Walk a user through a documented workflow one step at a time with a persistent bookmark (survives conversation gaps and reconnects). action='start' (with workflow_id) begins a run and returns the first step's coaching packet: what to do, what to have ready, and what done looks like. action='current' resumes after a gap; action='advance' marks the current step done and serves the next (only after the user confirms — completing the last step completes the run); action='back' revisits the prior step; action='abandon' stops without finishing and returns stoppedAtStepTitle plus workflowModified=false. In an abandon response, name that exact stopping step and say the workflow itself was not modified. Present one step at a time, never the whole workflow. Name each step with currentStep.title exactly as returned; do not shorten, paraphrase, or convert the title into a command. Starting a new run ends any previous unfinished one on this connection.

guided_session

List the company's registered assets — the databases its workflows depend on — with status (planned / being built / live), the tool each lives in, and which workflows and roadmap projects they're linked to. 'Live' assets exist and can be used today; 'being built' means an Ace project is delivering them; 'planned' is intent only. Read-only: assets are created and edited by managers on the Assets page in Ace Work, never from here.

list_assets

List your company's departments so you can orient which team owns which processes.

list_departments

List skill packs available on this connection: company context, shared standards and approved workflow knowledge. Managers can load company background, offerings, priorities and systems; team members retain their authorized shared guidance. Load one with get_skill. Skills are knowledge only — live execution always goes through guided_session / autonomous_run / get_workflow_checklist.

list_skill_packs

Record an observation about how work really happens, for human review — it never edits workflows or confirmed data directly. A request to edit or delete a documented workflow or step does not authorize this tool: first explain the limitation, and call this tool only after the user later explicitly accepts an offer to submit feedback. Pick the type: 'deviation' = the real process differed from a workflow (extra/skipped step, different tool or order, workaround; requires workflow_id — classify with deviation_type and capture what the person actually did in actual_process when you can); 'time_taken' = how long a real run actually took (requires workflow_id + minutes); 'note' = general tribal knowledge about how work happens (workflow_id optional); 'signal' = a passing operational mention caught while talking about something else — friction ('the export always breaks'), a tool in use, a handoff, a time/volume estimate — also the way to flag a documented workflow as outdated or wrong (signal_type sop_issue + the workflow's workflow_id routes the fix to whoever maintains the playbook; never just apologize for a stale workflow without flagging it). Capture signals only from what the user has already said in the conversation, after finishing their actual request; tell the user what was recorded and never interrogate them for more. Everything lands as a pending item for the operations team; nothing is changed or confirmed automatically.

log_observation

File and track requests with the Ace team, and check the status of everything the user has submitted. For a complete support-ticket request, the assistant's next action is the first my_requests file_ticket call; do not ask for a go-ahead or read drafted details back first. That first call files nothing and returns the one approval where the user reviews the exact details. Pick the action: 'file_ticket' = file a support ticket on the user's behalf (something broken, a product change request, or a question about a built automation; it is not for editing or deleting documented workflow content — such an edit request does not authorize a ticket, and a ticket may be prepared only after the user later explicitly accepts a separate offer; requires title + description, derived from the user's own words when possible; ask a clarifying question only when a required field cannot be derived; creates a real ticket the team triages; can never edit, close, or cancel one); 'list_tickets' = list the workspace's support tickets with status and priority (when the user asks about one specific ticket, answer about it in a sentence or two rather than presenting the whole board); 'my_submissions' = everything you have submitted through this copilot and its review status — captured signals (pain points, deviations, time logs, notes) and reported workflows — for 'what happened to the things I flagged?'.

my_requests

Create a new reported workflow, or — when workflow_id is provided — attach follow-up details to an existing one instead of creating a duplicate. This is not an edit surface: a request to edit or delete a documented workflow or step does not authorize this tool. First explain that limitation; use this tool only if the user later explicitly accepts an offer to submit feedback. create mode (no workflow_id; name + description required): call it only after the user has agreed to capture the process — if they mention a repeatable process in passing ('every month we…', manual multi-step routines, copying between tools), finish their actual request first, ask once whether they'd like it captured, and drop it if they decline. Gather at least one operational-signal field first or the submission stays an invisible draft: runs_per_month, minutes_per_run, tools, or pain_points (ideally all, plus the owning department — ask conversationally, not as a form). It lands as a reported workflow pending human review — never auto-confirmed, and it does not create a documented workflow directly. Before creating, check search_workflows for an existing workflow with the same name; if one exists, call this tool with its workflow_id (or use log_observation) instead of creating a duplicate. attach mode (workflow_id set): lands frequency (runs_per_month), duration (minutes_per_run), tools, pain points, additional steps, or a clarifying note on the existing record — frequency + duration are the most useful pair to land together — those two numbers drive the ROI estimates. Draft/pending workflows are gap-filled directly (existing values never overwritten); approved workflows and documented workflows get a pending suggestion for human review.

report_workflow

Search what Ace already knows about this company by keyword: captured pain points, accepted company facts (from discovery), and previously captured signals (notes, deviations, flagged friction). Returns matching entries with their content and source. Invoke it to check whether a question is already answered by existing workspace knowledge, or to ground advice in what has already been reported.

search_context

Search the company's documented workflows by keyword. Returns matching ids, titles, departments, and tools. With mine=true, lists the connected user's reported workflows plus visible company workflows. Use it for this company's own documented processes; a generic industry or best-practice question is not a reason to call it. search_workflows returns matches only, not a workflow card. For search-only requests, present the matches without opening a workflow. When the user already asks to open a workflow, see its steps, learn how their company does it, or run it (for example, 'Can you run my expenses?' or 'How do we onboard a new client here?'), use a clear matching workflow id to call get_workflow_checklist in the same turn and show its checklist or run-offer card. Do not require a separate request or the word 'card'. If several workflows are plausible, ask the user to choose; if none match, explain that honestly. Fetching this read-only card does not start a run or authorize a write: preserve the run-offer choice and all existing execution confirmations.

search_workflows