Chapter 7

Write Clearly and at the Right Altitude

The contract's skeleton is assembled, but it is easy to ruin with wording. A good instruction lives between two bad extremes: a vague wish and hand-programming every step in natural language.

It helps to keep these extremes in view.

  • Too high - "help the customer". The source of truth, the allowed actions, the format, the escalation, and the decision criterion are all undefined. The model guesses almost everything.
  • Too low - fifty if/else branches. The prompt copies business logic, becomes self-contradictory, and breaks on the first new route.
  • The right altitude - heuristics and invariants. Concrete enough to make a decision, and free enough to understand a user's new phrasing.
  • Mandatory code - verifiable rules. Permissions, amount limits, ownership, and parameter format are not delegated to probabilistic text at all.

In practice, rising to the right altitude is a rewrite: from "be polite and helpful" into a concrete goal, criteria, and boundaries.

Bad:
Be polite and helpful. Try to solve the problem correctly.

Better:
Goal: resolve the issue in the fewest turns without guessing.
- Use policy_search for rules and account_read for account facts.
- Ask a single question only when no action can be chosen without the answer.
- Don't promise a refund before the preview_refund result.
- If the policy and account data contradict each other, hand off to an agent.
- Answer: up to 4 short sentences, then one next step.

And one more thing that noticeably improves behavior: important rules are worth explaining.

Explain the reason for an important rule. Anthropic specifically notes the value of context and motivation. "Don't list internal IDs, because the customer can't use them" usually works better than a bare prohibition.

Links