Working with the assistant

The Stoa assistant is at its best when you treat it as a collaborator, not an oracle. The patterns on this page are how experienced users get high-quality output on longer tasks: anything that takes more than one prompt, anything you'll put your name on.

Break the task into steps

A long task is a sequence of small ones. The fastest way to lose an hour is to dump a complex ask into the chat and hope the assistant gets it right in one shot. Break the work apart first.

1. Plan first. Decide the shape of the output before writing any of it. What sections? What sources? What audience?
2. Then draft. Use the assistant to fill in each section, one at a time, with the relevant context loaded.
3. Then review. Read every section. Push back. Ask for revisions. Repeat.
4. Then assemble. Stitch the pieces together into the final deliverable.

This pattern works for grant proposals, policy briefs, research summaries, and almost any long-form deliverable.

Use the right mode for each phase

Stoa lets you pick how each message gets handled, and the modes are best at different things.

• Auto. The default. Stoa decides per message whether the question needs extra reasoning before answering. Good for general use when you don't want to think about which mode to pick.
• Instant. Skips extra reasoning and answers right away. Good for quick, low-stakes questions and simple rewrites where speed matters more than depth.
• Thinking. Reasons through the problem before answering. Good for anything with real logic to work through: comparing options, spotting inconsistencies, multi-part instructions.
• Research. A separate, deep multi-step investigation, chosen for one message at a time rather than as a standing mode. It scopes the question, plans the work, gathers evidence from your knowledge bases, and produces a structured, cited output, and can pause partway through for your approval on longer jobs. See Deep research.

Common pattern: use Research at the start of a long piece of work to scope it and gather sources, then switch to Auto or Thinking to draft and iterate section by section. See Chats for how the everyday interface works.

Keep the assistant grounded

The assistant is genuinely useful on facts that come from your documents. It's much less reliable on facts it makes up. Your job is to keep it grounded.

• Cite or don't trust. If the assistant makes a claim that matters, look for the citation. No citation means no source. Treat unsupported claims as drafts to verify, not facts to use.
• Use the right knowledge base. Pick an agent whose knowledge base actually contains the answer. Asking the legal agent about budgets disappoints everyone.
• Don't ask it to invent data. If the document doesn't say what you need, the answer is "the document doesn't say." Tell the assistant explicitly: "If you don't know, say so."

If your team has built skills for the task, run the skill instead of hand-rolling a prompt. Skills bake in the right grounding and tools.

Iterate, don't restart

When a draft is close but not right, iterate inside the same chat. Don't open a new one and start over.

• "Tighten the second paragraph."
• "Replace the example with one from our 2023 annual report."
• "Make the tone less formal."
• "Cut the length by a third without losing the conclusion."

The assistant keeps the context. Each revision starts from the previous draft, which is faster and more coherent than restarting. Copy each section out as you finish it.

Fact-check what matters

Three categories of claims always deserve a second look.

• Numbers. Dollar amounts, percentages, dates, deadlines, sample sizes. Click the citation and confirm against the original.
• Names and titles. People, organizations, programs, statutes. Easy to get subtly wrong, and the wrongness lands hard.
• Cause-and-effect claims. "X led to Y." Confirm the source actually says that, not a softer version paraphrased into something stronger.

This isn't a vote of no confidence. It's how serious work gets shipped.

Keep institutional knowledge in the loop

The assistant doesn't know what your team already knows. You do. Push that knowledge into the loop deliberately.

• Link the right documents. If a project has prior briefs, decisions, or templates, make sure they're in the knowledge base before you start.
• Run team skills. A skill your team built is a packaged version of how your team does this task well.
• State what's already decided. "We've chosen approach A, draft the next section assuming that." Saves a round of back and forth.

Good and bad patterns

A bad collaboration: a long prompt with vague goals, no source documents, no review, and a copy-paste straight into a final deliverable. The result reads fine and is wrong in ways nobody notices until later.

A good collaboration: a clear scope, the right knowledge base loaded, Research for planning, Auto or Thinking for drafting, every section read and revised, every claim that matters fact-checked. A draft you'd be proud to put your name on, in a fraction of the time.

Next

• Chats for the everyday interface.
• Deep research for the research pipeline.
• Knowledge bases for grounding the assistant.
• Citations for how to read and verify them.