Asking good questions
The handful of habits that separate a useful answer from a plausible one.
You do not need to learn "prompt engineering". You need four habits.
1. Say what the thing is
Asteria sees your file's contents, not the context in your head. One sentence fixes it.
Weak: "What does this say about churn?"
Strong: "This is our monthly customer churn export for 2025. status=C means cancelled. What does it say about churn?"
Column names, codes and abbreviations are exactly where a confident wrong answer comes from.
2. Say who the answer is for
The same facts get written very differently for a board pack, a customer email and your own notes. Say which.
Weak: "Summarise the contract."
Strong: "Summarise this contract for a non-lawyer who has to decide today whether to sign. Lead with anything that would embarrass us."
3. Ask it to be sceptical
This is the highest value sentence in the guide and almost nobody types it:
Flag anything that looks like a data problem rather than a real result, and tell me what you are unsure about.
Asked plainly, Asteria will tell you that a column has 300 blanks, that two spreadsheets disagree, or that a document does not actually answer your question. Not asked, it will tend to produce a tidy answer that hides the mess.
4. Correct rather than restart
The first answer is a draft. Reply to it the way you would reply to a colleague: point at the bit that is wrong and say why.
Weak: starting a new chat and rewording the question.
Strong: "The 2024 figure is wrong. You used the calendar year and our fiscal year ends in March. Redo it and say which convention you used."
Starting over throws away everything it learned about your data. One correction is usually worth three rewordings.
Naming your sources
Asteria cannot guess where to look. Be explicit:
- A collection: name it. "Check the Supplier Contracts collection." See why.
- The web: say so. "Search the web for their latest published pricing."
- A file: attach it, or refer to it by name if it is already in this conversation.
Asking for a shape
If you want a table, a chart or a document, say so. If you do not, Asteria picks, and it usually picks sensibly.
Give me this as a table, one row per supplier, sorted by renewal date.
Draw a line chart of monthly signups for the last two years.
Write this up as a two page document I can send to the team.
The last one produces a real file in the Workshop rather than a wall of text in the chat.
What it can and cannot reach
Being clear about this saves a lot of frustration.
It can reach what you attached, the collections you named, the web, and anything your organisation has connected: your mailbox, your calendar, a shared drive. Connected systems need switching on by an administrator and linking to your own account under Profile then Connections. Until then Asteria will tell you it cannot get there rather than guessing.
It can also reach a summary of your past conversations. On the first message of a new chat, summaries of your earlier conversations that look relevant are pulled in automatically, and at any point you can ask it to go looking ("what did we decide about the pricing tiers last month?"). What it gets back is the summary, not the full transcript. See Searching your conversations.
It cannot see a file you forgot to attach, a collection you did not name, or a system nobody has connected. And when it can act somewhere (sending an email, editing a document), it asks you first.
Very long conversations
Asteria keeps the whole conversation in view until it gets close to the limit of what the model can hold. Then it compacts: the opening exchange and the recent turns stay word for word, and the middle is replaced by a summary. You will see a note saying so.
This is what lets a long conversation keep going instead of failing. But a summary is lossy, and the middle is where detail goes first.
So there is a balance to strike, and both extremes are bad:
- A new conversation for every question throws away the context that makes the answers good.
- One enormous conversation for everything costs more per message (the whole history is re-read each turn), gets slower, and eventually starts forgetting the middle.
The rule of thumb: one conversation per task, not per question and not per project. When you genuinely change subject, start a new one. If a fact from earlier is important and you have seen the compaction notice, restate it in a sentence rather than trusting the summary to have kept it.