Most companies write their AI norms for people.
Tell the truth. Protect customer trust. Be honest about uncertainty. Keep humans accountable. Respect people’s time. Use AI to improve judgment, not avoid it.
That guidance can work when an employee is sitting in front of an AI tool. The person reads the answer, notices what seems uncertain, applies context, and decides what happens next. The values are carried by the person using the technology.
That changes when AI begins participating in the workflow itself.
One agent gathers information. Another interprets it. A third recommends what to do. A fourth takes the action. Some of those steps may happen without a person ever seeing them.
The company still expects its norms to apply, but the agents have never read the employee handbook.
If we want AI automation to behave according to the same standards we expect from people, those standards cannot remain general guidance. They need to become requirements for how the system uses evidence, handles uncertainty, passes work between agents, takes action, and decides when it needs a person.
Start with the behavior you actually expect
Suppose a company has a simple AI norm: Tell the truth. Don’t make something up when you don’t know.
For a person, that may be enough. People generally understand the difference between knowing and assuming. They can recognize when a claim might have consequences, look for more information, ask someone else, or say they don’t know.
An agent needs more direction.
What information can it trust? Which systems are authoritative? When does a claim need a source? What should happen when two sources disagree? How much uncertainty is acceptable? When should the agent keep researching, and when should it stop and involve a person?
Answering those questions turns the norm into something the system can apply:
Human norm → expected behavior → decision rules → system controls → evaluation
“Tell the truth” might become “claims used in customer-facing decisions must be supported by an approved source.”
That expected behavior leads to practical requirements. The system may need to identify authoritative sources, preserve the origin of each claim, flag conflicting information, distinguish fact from inference, and prevent unsupported claims from reaching an execution step.
Now the norm is doing real work. It is no longer something we hope the AI remembers. It is part of how the workflow operates.
Broad values create very specific design decisions
Human guidance is intentionally broad because people are good at applying principles to situations nobody anticipated. Automation requires us to make more of that interpretation explicit.
Take a norm like respect people’s time.
For an employee, that might mean avoiding an unnecessary meeting, irrelevant outreach, or a five-page explanation when one paragraph would do.
Inside an automated workflow, the same norm affects dozens of small decisions. An outreach agent should not contact someone simply because it can. A reporting agent should not produce 20 pages because producing 20 pages costs almost nothing. A notification agent needs some way to decide what deserves an interruption. Two agents should not independently contact the same customer because neither knows what the other has done.
Respecting people’s time might therefore require contact-frequency limits, duplication checks, relevance thresholds, output-length expectations, notification priorities, and access to recent customer history. It may also require a rule that the system can choose to do nothing.
The value has not changed. We have simply defined what it means when software is responsible for applying it.
The norm has to travel with the work
This becomes especially important in multi-agent systems because no single agent owns the whole decision.
Imagine a workflow that moves from research to analysis, recommendation, and execution.
The research agent finds a note saying that a customer mentioned a problem six months ago. It correctly records that we don’t know whether the problem still exists.
The analysis agent shortens that to “the customer has experienced this problem.”
The recommendation agent decides the customer is a strong candidate for a product.
The execution agent writes, “I saw you’re struggling with this.”
No agent intentionally lied. The system still turned uncertainty into certainty.
That happens because the conclusion traveled through the workflow, but the conditions attached to it did not.
Important context needs to move with the work itself. That includes the original evidence, its source, when it was collected, how confident the system is, what remains uncertain, what restrictions apply, and whether a person must approve the next action.
Each agent needs more than the previous agent’s summary. It needs to know how that summary can be used.
If uncertainty matters, it cannot disappear during a handoff. If a claim requires evidence, the evidence has to remain connected to the claim. If an action requires approval, an intermediate agent should not be able to remove that requirement by reformatting the output.
The standard has to survive the handoff.
Some values should become permissions
There is a meaningful difference between guiding a person and governing an automated system.
We often tell employees what they should or should not do because they need room to apply judgment. With agents, the better design is sometimes to control what the system can do in the first place.
If a person remains accountable for a high-risk decision, the agent should not have permission to execute it without approval. If customer information can only be used for a specific purpose, the agent should receive only the access required for that purpose. If an external message cannot include an unsupported claim, the sending system should reject claims that arrive without the required evidence.
The same applies to scale. If customer trust matters more than outreach volume, contact limits can be enforced before a message is sent. If certain information cannot leave an environment, that boundary belongs in the infrastructure rather than in a sentence every agent is expected to remember.
Some norms require judgment, so agents need instructions and examples. Others can be expressed as permissions, limits, or technical boundaries.
When a rule can be guaranteed by the system, it should not depend on an AI model remembering it.
The system needs a way to stop
Most automation is designed to complete a task. Every part of the workflow is trying to keep the work moving.
Following the company’s norms will sometimes require the opposite.
The right decision may be to gather more evidence, reject a recommendation, avoid contacting the customer, or stop and ask a person. If every agent is rewarded for moving the workflow forward, the system needs another layer with permission to interrupt that momentum.
That layer might evaluate a proposed action before anything consequential happens. It could check whether the supporting information is strong enough, whether uncertainty has been preserved, whether the agent has authority to act, whether customer information is being used appropriately, and whether the action creates unnecessary work or noise.
Most importantly, it needs authority. It should be able to block the action, request more information, send the work backward, or escalate the decision.
An evaluative agent may help when applying a norm requires context. Clear boundaries should still be enforced with ordinary software. Spending limits, required approvals, access restrictions, and contact-frequency caps should not depend on a model interpreting the rule correctly every time.
The goal is not to build an AI that can recite the company’s values. The goal is to build a system that behaves according to them.
Human review is part of the system design
Automation does not always remove human effort. Often, it moves that effort somewhere else.
A person may no longer research the account, assemble the context, write the recommendation, or update several systems. Instead, someone must review exceptions, resolve conflicting information, approve higher-risk actions, investigate failures, and decide what to do when the automation reaches the edge of its authority.
The repetitive work may fall dramatically while the remaining work becomes more mentally demanding. The person no longer handles ordinary cases throughout the day. They receive a queue containing only the strange, ambiguous, consequential ones.
That may be the right division of labor, but it is not automatically a good experience.
A poorly designed escalation forces the person to reconstruct everything the agents already knew. They have to find the customer history, check which sources can be trusted, understand what the system did, figure out why it stopped, identify the applicable rule, and finally make the decision.
The task was automated, but every remaining human interaction became harder.
A better escalation brings the reasoning with it: the relevant evidence, sources, uncertainty, actions already taken, reason for escalation, applicable norm, and the specific decision that requires human judgment.
The person should be deciding, not reconstructing.
This also gives the company a way to improve the workflow. If people repeatedly receive the same type of escalation and make the same decision, that pattern is useful. Repeated approvals may be ready to become a clearer decision rule. Repeated rejections may expose a bad assumption. Frequent escalations may point to missing information or a threshold that needs adjustment.
A useful measure of automation is not simply how many human steps disappeared. We should also ask where the human effort went, what kind of mental load remains, and whether the system is reducing that burden over time.
Overrides should teach the system
No company will translate every norm perfectly on the first attempt. Trying to anticipate every situation would produce an enormous rulebook that still missed the cases that matter.
The most useful moments often happen when the automation does something technically allowed and a person says, “That isn’t how we should behave.”
That disagreement reveals something the system does not yet understand about the company’s operating standard.
The company can capture the situation, the action the agent proposed, what the person changed, and why. Over time, those examples create a practical library:
Situation → relevant norm → expected judgment → acceptable action → unacceptable action
That library can improve agent instructions, evaluation scenarios, permissions, automated tests, escalation criteria, and employee guidance.
Human review then serves two purposes. It protects the current workflow when the system encounters something it cannot safely handle, and it helps the company design a better version of the workflow.
Humans and agents need the same definition of good
Translating norms into system requirements forces a company to become clearer about what those norms mean.
If five employees look at the same AI action and disagree about whether it violates a company principle, a better prompt will not solve the problem. The company has found an ambiguity in its own operating standard.
Resolving that ambiguity creates something useful for everyone. Employees get concrete examples of how the company expects a principle to be applied. Agents get the same lesson expressed through context, decision rules, evaluations, permissions, and escalation paths.
The implementation will be different because people and software are different. The expected behavior should still be consistent.
Writing AI norms is the beginning of governance. Once AI begins participating in workflows and taking action, every norm needs a second question:
What would have to be true about our system for this norm to hold even when no person is watching?
That question turns a value into an operating model. Evidence and uncertainty travel with the work. Clear boundaries become permissions and controls. Proposed actions are evaluated before they create consequences. Human judgment enters at a defined point with enough context to be useful. Overrides and escalations feed back into the design.
The result is not an AI system that perfectly understands the company’s culture. It is something more practical: a system in which following the company’s standards is the easiest path through the workflow, while violating them becomes harder, visible, or impossible.
If AI agents are going to work on a company’s behalf, they cannot receive tasks without also inheriting the standards that govern how the work should be done.