@@ -1,18 +1,18 @@
 # Agent Behavior
 
-An open format for recording selected, recurring agent conduct that teams want to review and preserve.
+An open standard for defining and evaluating how an agent should behave across a trajectory.
 
 ## Why it exists
 
-Doing serious, long-horizon work reliably at scale requires more than checking the final answer. An agent may research, call tools, edit files, make judgments, and recover from failures before producing one result.
+A modern agent can work for hours. Over a single trajectory, it may research, call tools, edit files, and make hundreds of decisions before producing one result.
 
-Outcome evals assess the result. They are essential, but an endpoint score often gives limited evidence about which decisions made the work reliable or caused it to fail. Teams also hold product- and domain-specific opinions about the approach. A team may require its presentation agent to inspect the deck the user will actually see; an accounting firm may require its tax agent to ground conclusions in primary authority.
+Outcome evals matter, but on long trajectories they are expensive to run, and the result is often difficult to verify. A pass or fail also cannot tell you which decision went wrong. Even a correct result can hide a broken process you would not want to repeat.
 
-`BEHAVIOR.md` makes selected, recurring conduct explicit. Teams can compare it with recorded trajectories, use the resulting signal to diagnose failures, improve prompts, skills, tools, models, or the harness, and check whether conduct improved.
+To build long-horizon agents you can trust, you have to supervise the process, not only the result. A behavior spec makes the expected behavior explicit. Teams can judge it against recorded trajectories, identify which behavior failed, update the agent's prompts, skills, tools, model, or harness, and test whether the change worked.
 
 ## What a behavior looks like
 
-Behavior specs live under `.agents/behaviors/`. Each spec is a directory containing a `BEHAVIOR.md` file:
+Behavior specs capture a team's point of view on how an agent should operate. They live under `.agents/behaviors/`, with each spec in a directory containing a `BEHAVIOR.md` file:
 
 ```text
 .agents/behaviors/
@@ -41,23 +41,25 @@ look at what the audience will actually see.
 
 For a domain-specific companion, see [Primary-source tax research](examples/.agents/behaviors/primary-source-tax-research/BEHAVIOR.md).
 
+A behavior spec defines the intended behavior so a team can align on it and measure against it. It does not prescribe how training, runtime context, or tools produce that behavior.
+
 A `BEHAVIOR.md` file has YAML frontmatter with a `name` and `description`, followed by free-form Markdown. It may describe one behavior or a related group. The headings and `Why` label above are optional; the format requires no body template or assessment method. See the [specification](docs/specification.mdx) for exact structural requirements.
 
 ## How it fits
 
-Runtime context, including prompts and skills, helps produce agent conduct; models, tools, and the harness also shape it. `BEHAVIOR.md` separately records the conduct a team wants to review. A human or automated evaluator can compare that intent with a recorded trajectory using any suitable assessment method.
-
-For an independent evaluation of an existing agent configuration, do not add the behavior file to the agent's runtime context solely for the test. Teams may include it there intentionally; that tests a different configuration.
+You already encode behaviors today in prompts, skills, and tool descriptions. Models and the harness shape them too. `BEHAVIOR.md` records the few recurring choices you care enough to measure.
 
-The questions are complementary: did the result meet its target, and did the approach match the team's intent?
+`BEHAVIOR.md` is not a runtime prompt. For an independent evaluation, it stays out of the evaluated agent's context and acts as the standard used to judge the trajectory. Teams may intentionally include it in runtime context, but that tests a different configuration.
 
 ## Getting started
 
-1. Pick one recurring choice that matters enough to review. Do not turn every instruction, tool procedure, or desirable quality into a behavior.
+A behavior spec is an opinion, formed from experience, about how the agent should work. Evals can tell you whether the agent followed it, not whether the opinion was good in the first place. Your team still decides which behaviors are worth requiring.
+
+1. Pick one behavior that governs a recurring choice, can be evaluated from a trajectory, and matters enough to test continuously.
 2. Create `.agents/behaviors/<name>/BEHAVIOR.md`.
 3. Describe when the behavior applies, desired and undesired conduct, and why it matters. When useful, say how a trajectory could show it.
 4. Review or evaluate recorded trajectories against it.
-5. When the agent misses it, update the prompts, skills, tools, model, or harness that produce the conduct, then evaluate again.
+5. When the agent misses it, update the prompts, skills, tools, model, or harness that produce the behavior, then evaluate again.
 
 For fuller guidance, use the [quickstart](docs/behavior-creation/quickstart.mdx) or the bundled [behavior authoring skill](.agents/skills/writing-agent-behavior/SKILL.md).