Agent behavior
A framework for writing formal behavior specifications for AI agents using Markdown, treating agent conduct as documented contracts rather than just prompts.
Read Original Summary used for search
TLDR
• Introduces BEHAVIOR.md format - version-controlled specs that define when and how agents should act in specific situations
• Uses four dimensions: Evidence (what to gather), Decision (what to conclude), Execution (what to do), Recovery (what to do when things fail)
• Cost-sensitive actions example: agents inspect costs, determine materiality, surface thresholds to users, and handle uncertainty explicitly
• Specs are for humans reviewing traces and designing evals, NOT runtime prompt text
• Follows RFC 2119 keywords (MUST, SHOULD, MAY) for normative requirements like API documentation
In Detail
The framework treats agent behavior as formal specifications rather than ad-hoc prompts. BEHAVIOR.md files are Markdown documents that describe recurring agent conduct - when it matters, what's desired, and what constitutes failure. The format is intentionally minimal and free-form, allowing teams to organize behaviors using whatever headings and structure communicate clearly, while following RFC 2119 conventions for normative requirements.
The core framework uses four recommended dimensions: Evidence (what should the agent gather?), Decision (what should it conclude?), Execution (what should it do?), and Recovery (what happens when the first path fails?). The cost-sensitive actions example demonstrates this: agents should inspect or estimate costs and alternatives, determine if the action creates material tradeoffs, surface costs before crossing thresholds, and when cost is unknown, inspect more or ask for confirmation. These dimensions can be combined, renamed, or omitted when trivial.
The key insight is that behavior specs serve a different purpose than runtime prompts. They're designed for people who review agent traces, design evaluations, or align prompts - creating a shared language for defining and verifying agent conduct. A single spec can group related behaviors (like different aspects of a customer service agent), while separate specs handle behaviors needing independent ownership or reuse. This gives teams a way to specify agent behavior that's more rigorous than prompts but more flexible than hardcoded rules.