Unit 02.02: Backstory as constraint rather than decoration

The backstory field is where most of an agent's actual behaviour is specified, and where most of the wasted tokens live.

Five lines, five testable behaviours

A useful backstory reads as a list of rules rather than as a character sketch. Each line should be something you could write a test for.

The code builds a policy reviewer and marks each line rule or fluff.

from crewai import Agent

agent = Agent(
    role="Policy reviewer",
    goal="Confirm a drafted reply matches the written policy",
    backstory=(
        "You compare a draft against the policy text you are given.\n"
        "You never approve a claim the policy text does not state.\n"
        "If the policy is silent, you say it is silent -- you do not infer.\n"
        "You quote the policy line you relied on for every judgement.\n"
        "You do not rewrite the draft; you approve or reject with a reason."
    ),
    allow_delegation=False,
)

print("each line is a rule you could test:")
for line in agent.backstory.splitlines():
    testable = any(w in line.lower() for w in ("never", "do not", "you say", "you quote"))
    print(f"  {'RULE ' if testable else 'FLUFF'} {line}")

# Five lines, five behaviours. Compare with "You are a meticulous reviewer with
# an eye for detail", which is one line and zero behaviours.

Every line changes an outcome. "You never approve a claim the policy text does not state" prevents the failure from Module 9 where a reviewer approves against the previous agent's output instead of the source. "You do not rewrite the draft" keeps the reviewer from quietly becoming a second writer.

"If the policy is silent, you say it is silent" is the one most often missing, and it is the difference between a reviewer that reports a gap and one that fills it.

The mistake this prevents

It is worth being precise about what this does and does not buy, because the two are easy to conflate. An *elaborate* backstory - credentials, career history, personality - shapes tone and framing and nothing else. It adds no knowledge the model did not already have and makes no output more reliable. What the five lines above do is different in kind: each one removes a class of output. Length is not the variable; whether a line rules something out is.

The mistake is treating backstory as flavour and putting the real constraints in the task description instead. The backstory travels with the agent across every task it runs; a constraint written into one task applies only there, and the next task quietly loses it.

Takeaway

Write the backstory as numbered behaviour, one rule per line. Constraints that must hold across every task belong here, not in an individual task's description.

Mark complete