Skip to main content

​
Overview

When Dexter takes on anything non-trivial, it works out loud. Four surfaces make that visible in the conversation: the task list, review briefs, action cards, and question prompts. Together they let you follow what Dexter is doing, catch problems before they land, and answer the questions Dexter needs answered — without ever guessing at hidden state. This page walks through each one: where it lives, what it looks like, and how to respond.

​
The Task List

For any multi-step effort — cleaning a dataset, building out a simulation model, running an experiment sweep — Dexter creates a task list so you can see the plan and its progress in real time. Where it lives. The Tasks section of the Artifacts panel on the Dexter page — and, condensed, as a Tasks chip in the dock just above the chat input box, so the current plan stays in view while you type. Expand the chip to see the full list. What you see per task. Each task has a short, plain-language title (“Validate cycle times against historical data”, “Build the paint-line model”) and a status:
  • Pending — queued, not started yet.
  • In progress — Dexter is actively working on it (one at a time).
  • Completed — done.
A task can declare a dependency on another; Dexter won’t pick it up until the prerequisite is done. How it updates. Dexter flips a task to In progress the moment it starts, and to Completed the moment it finishes — not in a batch at the end. If Dexter hits a blocker mid-task, it creates a new task for the blocker and links it, rather than silently abandoning the work. If a pre-planned list turns out to be wrong, Dexter clears it and rewrites one that matches the actual work.
The task list is editable through chat. If you see a task that shouldn’t be there, or one missing that should be, say so — Dexter will restructure the list.

​
Review Briefs

Before Dexter commits to anything expensive or hard to undo, it stops and asks you to sign off with a review brief. Think of it as a one-page memo: what’s being decided, the assumptions behind it, and the evidence — inline in the conversation. What triggers one:
  • A produced piece of work is ready for your check — a completed analysis, derived numbers, a report about to land.
  • A plan is about to run that would be costly to unwind — a large model change, a data pipeline about to overwrite outputs.
  • Inside a Project, moving from one phase to the next — phase transitions are gated by a review brief.
What’s in one. A markdown card in the conversation, usually a page or less: the decision up top, then the open questions and assumptions the decision rests on, then the evidence — tables, numbers, diagrams. Everything you need to decide is inside the brief; you don’t need to open other files to evaluate it. How to respond. Two buttons:
  • Approve — Dexter proceeds with what the brief describes. Inside a Project, if the brief was about a produced artifact (a document, a report), approval is what moves it out of drafts and into its phase’s permanent home.
  • Request changes — opens a comment field. Say what needs to change; Dexter revises and re-presents.
Some briefs are freeform rather than approve/reject — Dexter is asking for open-ended feedback on work in progress rather than a go/no-go. These look the same, but the response is a comment box instead of two buttons.
After approval. Dexter continues the turn — the approved artifact lands, the phase advances, or the plan begins executing. The brief stays in the conversation as the record of what you approved and when.

​
Action Cards

An action card is a small call-to-action card that appears in the conversation with a title, a one-line reason, and a button that takes you somewhere in the app to act on it. When they appear. When the natural next step lives in a part of the app that you drive, not Dexter — Dexter surfaces the card instead of describing where to go in prose. They are non-blocking: Dexter keeps working (or closes out its turn) rather than waiting for you to click. Act on them when you’re ready. Common examples:
  • Start a project — after Dexter has scoped an effort large enough to warrant a Project, it points you at the page where you begin one.
  • Add data — after Dexter has identified data it needs but doesn’t have, it points you at the upload page.
Only one card at a time — Dexter picks the single most useful next step rather than stacking a list of options.

​
Question Prompts

When Dexter needs input from you, it uses a structured question. Four shapes, each rendered differently in chat: The freeform field is always there on select-type questions — you don’t need an “Other” option in the list. For heavier sign-offs on produced work, Dexter uses a review brief instead of an approval question. Batches. Dexter may ask several questions in one card when they’re related and independent — answer them together. If one question only makes sense after another is answered, Dexter asks the first batch, then a follow-up shaped by your answers.
You can answer later. All four types stay in the conversation until answered — scroll up and respond to an older question at any time.

​
Limits

  • Tasks are per-conversation. A fresh conversation starts with an empty list.
  • Review briefs and questions are pause points. While one is waiting on you, Dexter has ended its turn and won’t continue until you respond. Non-blocking action cards are the exception — they don’t gate progress.
  • Long conversations shed early context. Questions answered long ago may need re-answering in a fresh conversation — or, better, move the answers into Memories or Rules so every future conversation starts with them.
There is no undo on an approved brief. If you approved something that shouldn’t have landed, tell Dexter — it will roll the change back where possible, but some changes (data pipeline overwrites, external file exports, deletions) can’t be undone.