Prompting tips

The Amara models follow instructions closely, which means the quality of a reply depends heavily on how the request is written. These habits help in almost every application. Because the models run with fixed sampling settings on Syntic, the prompt is also your main lever for controlling style and variety.

Start with a way to measure

Before tuning wording, decide what a good answer looks like and gather a handful of realistic inputs, including awkward ones. Then you can tell whether a change helped instead of judging by one lucky reply. See Test with real inputs.

Say who the model is working for

Use the system message to set the scene once: who the users are, what the product does and what a good answer looks like.

You answer questions from tenants of Harbor Lane Apartments.
Answer only from the house rules below. If the rules do not cover the question,
say so and suggest contacting the front desk.

The platform adds its own short instruction about the assistant’s identity at the top of every request. Write your system message so it stands on its own, and do not ask the model to claim a different underlying model or provider; it will keep describing itself as Syntic AI.

Be specific about the output

Vague requests produce vague answers. State the length, format and audience:

• “Reply in at most three sentences.”
• “Return a bulleted list, one item per line, with no introduction.”
• “Write for a reader who has never used a spreadsheet.”

Say what to do rather than only what to avoid. “Write in plain sentences” works better than “Don’t use bullet points”.

Explain the reason behind a rule

A rule with a short reason is followed more sensibly than a bare command. Compare:

Keep each answer under 40 words.

Keep each answer under 40 words: replies are read aloud by a car's voice assistant,
so long answers distract the driver.

The second version also tells the model what to do in cases the rule does not cover, such as avoiding tables or links.

Ask for structured data explicitly

The API has no dedicated JSON mode. When you need machine-readable output, describe the exact shape in the prompt, show one example, and validate what comes back:

Extract the invoice fields. Reply with JSON only, no commentary, in this shape:
{"invoice_number": string, "total": number, "currency": string, "due_date": "YYYY-MM-DD"}

If parsing fails, retry with the error message added to the conversation. For data the model must return reliably, tool calling with a strict argument schema is often more dependable than free-form JSON.

Give examples

One or two short examples of the input you expect and the answer you want teach the model the pattern faster than a long description. Make the examples varied, so the model copies the pattern and not one particular detail. You can write them as earlier user and assistant turns:

[
  { "role": "system", "content": "Turn customer feedback into a one-line ticket title." },
  { "role": "user", "content": "The app logs me out every time I switch to another app and back." },
  { "role": "assistant", "content": "Session lost when app returns from background" },
  { "role": "user", "content": "Export to CSV puts all the dates in the wrong column, really annoying" }
]

Separate instructions from material

When you include a document, email or transcript, set it apart from your instructions, for example with clear markers:

Summarise the customer email between the markers in two sentences.

<<<EMAIL
...
EMAIL>>>

This also makes it harder for text inside the material to be mistaken for instructions.

Put long material first, the question last

With long inputs, such as a contract or a set of support articles, place the material near the start of the request and the actual question at the end. Keeping that material identical from one request to the next also lets repeated input be billed at the cheaper cached rate (see Chat basics).

Let the model work in steps

For problems with several parts, ask the model to work through them in order: first list the relevant facts, then reason, then give the answer. When you need only the final answer, ask for the working inside a marked section that your code removes before showing the reply.

For larger jobs, split the work across requests instead: one request extracts, the next checks, the last writes the final text. Each step is easier to test and fix on its own.

Keep the conversation lean

Every request resends the whole conversation, and every token is billed. Drop turns that no longer matter, summarise long histories, and keep tool results compact.

Set a sensible max_tokens

max_tokens caps the reply, not the request. Set it high enough for a complete answer; if a reply ends with finish_reason: "length", it was cut off. Use the prompt, not the cap, to make answers shorter.

Test with real inputs

Collect a handful of realistic examples, including awkward ones, and re-run them whenever you change the prompt or switch models. Small wording changes can have large effects. Keep the inputs, the prompt version and the outputs together, so you can compare runs side by side.

A checklist before you ship

• The system message says who the users are and what a good answer looks like.
• Output format and length are spelled out.
• Outside material is clearly marked off from instructions.
• Structured output is validated, with a retry on failure.
• max_tokens leaves room for a full answer.
• A small test set passes after every prompt change.