"The AI should behave responsibly" is not a definition, it is an aspiration. Most organizations start with something close to that when they first try to define acceptable AI behavior, and most discover fairly quickly that it gives an engineering team nothing to actually build against. A model cannot enforce "responsibly." A policy engine can enforce "refunds above a specific amount require approval." The difference between those two statements is the difference between a value and a rule, and only the second one can be checked.
Values inform rules, but they are not rules
Values like fairness, transparency, or user trust are useful for deciding what an organization cares about and why. They are not specific enough to implement, because two engineers can both sincerely believe they are honoring "fairness" while building very different systems. Turning a value into something enforceable requires translating it into concrete, checkable conditions: which specific actions are permitted, under which specific circumstances, and what happens when those conditions are not met.
This translation step is where most acceptable-use efforts stall. It is easier to write a values statement than to work through the specific scenarios that statement is supposed to govern, but the specific scenarios are the only part that an enforcement layer, or a developer building against the policy, can actually act on.
Write rules around actions, not intentions
A rule like "the agent should not do anything harmful" cannot be checked at runtime, because harm is not a property a system can evaluate directly. A rule like "the agent may not transfer funds to an account not previously associated with the customer without explicit approval" can be checked, because it names a specific action and a specific condition. Effective behavior definitions describe the action, the condition under which it is or is not allowed, and, where relevant, who or what can grant an exception.
This does not mean intentions do not matter. It means the intention has to be expressed as a concrete rule before it can do any actual work protecting the system, and vague language at the policy level tends to produce vague, inconsistent enforcement at the implementation level.
Scope rules to what the agent can actually do
A rule about "acceptable AI behavior" only needs to cover the space of actions the agent in question can actually take. An agent that can only answer questions from a fixed knowledge base does not need an elaborate rule set about financial transaction limits, because it has no path to trigger one. Spending effort writing rules for actions a system cannot perform distracts from the rules that actually matter for what it can do.
This means the process of defining acceptable behavior should start from an inventory of the agent's actual tools and capabilities, not from a generic template borrowed from a different system with a different risk profile.
Different agents need different thresholds
A rule appropriate for an internal documentation assistant, low thresholds for what requires approval, since the impact of an error is limited, would be far too permissive for a customer-facing agent that can issue refunds or modify accounts. Acceptable behavior definitions should scale their thresholds to the actual impact of the actions involved, rather than applying one uniform standard across systems with very different worst-case outcomes.
This also means the definitions need to be revisited whenever an agent's capabilities change. An agent that gains a new tool has effectively gained a new category of action that the existing behavior definition may not cover yet, and treating that gap as a routine update rather than a one-time exercise keeps the rules aligned with what the system can actually do.
Exceptions need a defined owner, not an ad hoc one
Every meaningful behavior rule eventually needs an exception process: a case where the default rule should not apply, approved by someone with the authority to make that call. Defining who that person or role is in advance, rather than improvising an approval path the first time an exception is needed, keeps exception handling from becoming an ad hoc workaround that quietly erodes the rule over time.
Test the rules against realistic scenarios before trusting them
A behavior rule that looks complete on paper often has gaps that only show up when tested against specific scenarios: an edge case where two rules conflict, a boundary condition where the amount is exactly at the limit, a sequence of smaller actions that together exceed a threshold no single action crossed. Running realistic scenarios through the rule set before relying on it in production surfaces these gaps while they are still cheap to fix.
Where TELEON fits
Once acceptable behavior has been translated into specific, checkable rules, TELEON provides a place to enforce them at the tool-call boundary, applied through the gateway or supported middleware, and to record the outcome of every decision for later review. This is the enforcement half of the work.
The translation from values and intentions into specific, scoped rules has to happen first, and it requires input from the people who understand the agent's actual capabilities and the business consequences of getting a rule wrong in either direction, too strict or too permissive.
A short checklist for defining acceptable behavior
- Translate each relevant value into a specific, checkable rule about
actions and conditions.
- Scope rules to what the agent can actually do, based on its real tools
and capabilities.
- Set thresholds according to each agent's actual worst-case impact, not a
uniform standard.
- Define who can grant exceptions before one is needed.
- Test the rule set against realistic edge cases before relying on it.
- Revisit the rules whenever an agent's tools or capabilities change.
Acceptable AI behavior only becomes something a system can actually enforce once it is written as specific, checkable rules about actions and conditions. Values are the reason those rules exist, but they are not a substitute for doing the work of writing the rules themselves.