Writing instructions
Instructions are the whole product. A good agent and a useless one usually differ by a paragraph of text, not by settings.
The agent does nothing unless told
Before your instructions, every agent is given a standing rule: do only what the instructions describe, never invent tasks, never reply to anything unless told to, and when in doubt do nothing. This is deliberate - an agent that improvises with your inbox is worse than one that does too little.
The practical consequence is that vague instructions produce an agent that reports back and stops. If your agent seems to do nothing, the instructions are almost always the reason.
What a good instruction block contains
- The job, in one line. “You triage email.” Start there so everything after it has context.
- When to act and when not to. Define your terms. “Urgent means a customer complaint, a failed payment, or a direct question from a client” is usable; “handle important emails” is not.
- Exactly which tool to use for what. Name the action: “send me a Telegram message”, “reply to the sender”, “archive it”.
- What to do when nothing matches. Say “if nothing is urgent, do nothing and say so”. Without this, some models will try to be helpful in ways you did not ask for.
- Limits. “Never send more than three messages in one run”, “never reply to newsletters”, “never promise a refund”.
Write the negative rules too
Most unpleasant surprises come from something the instructions never forbade. Spend a line or two on what the agent must never do - it costs nothing and it is the cheapest safety mechanism available to you.
Referring to tools
You do not have to use exact tool names, but it helps to be concrete about the action and the account. If an agent has two Gmail accounts attached, its tools are suffixed to tell them apart - send_email_sales and send_email_support rather than two identical send_email tools. In that situation, say which account you mean.
Choosing a model
A cheaper, faster model is usually fine for routing, summarising and pattern matching. Step up to a stronger model when the agent has to exercise judgement over ambiguous text, or when it keeps making the same mistake no matter how you rewrite the instructions. Changing the model is one dropdown and does not affect anything else.
Iterating
Write, test, read the transcript, adjust. The transcript shows every tool the agent called and everything it got back, so when the behaviour is wrong you can usually see the precise sentence that misled it. That loop is faster than trying to write perfect instructions on the first attempt.