The public braintrustdata/agentbehavior repository published documentation defining Agent Behavior as an open standard for expected agent conduct across a whole trajectory. Its Apache-2.0 reference implementation proposes a small artifact for that job: a versioned statement of recurring conduct at .agents/behaviors/<name>/BEHAVIOR.md. Reviewers can compare a trajectory with it; eval authors can derive rubrics and judges from it; prompt and skill authors can see what needs to change after a failure.
An agent can reach the correct answer and still have behaved badly. It can cite the right tax rule without opening the authority, deploy a working change before checking the environment, or recover from a failed tool by quietly changing the user’s goal. A final-answer score can call each run a success.
The important negative is as useful as the proposal. Agent Behavior is not a runtime, an orchestration framework, a permission system, or a scorer. Its client guide says behavior specs are not primarily runtime activation material and warns against automatically injecting them into prompts. The file is an answer key: a reviewable statement of what should count as acceptable conduct before a particular implementation turns that statement into a score.
Put the rule somewhere the machinery cannot quietly own it
The project’s specification deliberately uses a familiar, modest shape. A behavior gets a stable directory name, YAML frontmatter with a name and description, and a free-form Markdown body. Optional references can hold rationale, examples, or domain context. The format does not force every policy into fixed fields or one universal vocabulary.
That choice allows a behavior to outlive a tool or prompt rewrite. “Call search_tax_code” describes an implementation. “Consult relevant primary authority before deciding a substantive tax answer” describes a decision a reviewer can still recognize when the search stack changes. The suggested dimensions—intent, evidence, decision, execution, recovery, and failure modes—help authors find that level without turning the prose into a database schema.
The accompanying TypeScript validator enforces the portable shell: location, canonical filename, YAML shape, name grammar, directory-name matching, description length, and metadata. Invalid specs produce diagnostics. It does not claim to decide whether a rule is wise, observable, non-conflicting, or accepted by the people it governs. That boundary matters: syntax can be deterministic; policy quality cannot.
The strongest example lets a right answer fail
The project’s clearest receipt is a primary-source tax-research behavior and the runnable judge built around it. The behavior asks an agent to read the relevant research skill and then consult primary authority before deciding. Its fixture set includes ordinary passes, a skill read too late, a secondary-source-only run, an outside-scope task, and the revealing case: a correct answer reached without the required research.
That last trajectory fails. The example judge works from recorded events, cites event IDs, distinguishes true, false, and not applicable, and rejects citations that do not exist in the trajectory. It is not a universal judging protocol—the project leaves labels, folding rules, human review, and grading models to clients—but it makes the intended division of labor tangible. The standard says what was expected; the harness says how evidence becomes a judgment.
That division is a healthy challenge to the first reading of the project as “another eval format.” An eval contains sampling choices, labels, scorer prompts, and model versions. If the behavioral standard exists only inside that machinery, a test change can silently become a policy change. A plain-language source file gives reviewers something different to inspect: not merely whether the score moved, but which conduct was newly required, relaxed, or left unmeasurable.
The hard problem is adjudication, not Markdown
The public repository is still early: its current public head is a July 28 README change, and the project’s own source establishes a working reference implementation, not broad adoption or consensus. That is not a flaw in the idea. It is a limit on the claim this article can make.
The deeper limit is that natural-language behavior and an LLM judge can share the same ambiguity. A beautifully consistent verdict can still be consistently wrong. The project’s authoring guidance points toward the right defense: calibrate a behavior against a normal pass, a realistic failure, a lucky-correct failure, and an outside-scope case. But the format cannot create telemetry that a trace never recorded, settle conflicts across project and organization rules, decide who owns a policy change, or enforce a high-risk boundary at runtime.
Those gaps are where a useful ecosystem could form: trace viewers that show a behavior beside cited spans; behavior-diff review that explains a changed trigger or recovery expectation; conformance fixtures that do not import one vendor’s judge semantics; provenance and conflict checks across scopes; and a pre-judge warning that says the available trace cannot prove the behavior at all.
Start with the failure a final answer cannot reveal
A team does not need to translate an entire runtime guide into behavior files. Start with one frequent or high-impact choice whose outcome hides the required process. Write the narrowest trigger, expected conduct, negative boundary, and recovery rule that could survive a tool change. Then calibrate it against real trajectories and instrument the events a reviewer needs to see.
For example, a reporting workflow might say: before publishing a specific factual claim about software, inspect a relevant public primary source and preserve a direct link; if the evidence is insufficient, narrow or hold the claim. The crucial negative is not a factual error. It is the lucky-correct article written from memory. That is the case a final-answer score misses, and the case a behavior review can expose.
This is useful even before a model judge exists. It forces a team to agree whether source inspection is a real standard or merely a preference, and it reveals whether the trajectory records enough to check. If a trace cannot show which source was opened before the claim was decided, the behavior has found a telemetry problem rather than solved one.
Agent Behavior will matter if it makes disagreements locatable: the expected conduct was missing, the trace could not prove it, the judge drifted, or the team never agreed on the rule. That is more ambitious than a Markdown convention and more modest than enforcement. It is exactly the sentence a growing agent stack needs before it can treat a score as evidence.