Abstract

“Ask finance before you do that.”

“That customer has a different agreement.”

“The system lets you change it, but you need the account owner’s approval first.”

Every organization runs on knowledge like this. Some of it lives in policy documents. Much of it lives in conversations, old tickets, and the experience of people who know whom to ask. New employees learn these rules over time, often by making a mistake and having someone explain the exception.

When we delegate work to an AI agent, we expose how much of the job was never written down.

An API can explain how to issue a refund. It rarely explains whether this particular refund is appropriate, who may approve an exception, or which customer commitment changes the answer. Connecting an agent to the right applications gives it access to only part of what a person uses to do the job.

This talk explores the organizational knowledge and decision rights behind apparently simple tasks. We’ll examine how to uncover unwritten procedures, distinguish an established policy from somebody’s remembered workaround, and give agents relevant context without treating everything they read as an instruction. We’ll then connect that knowledge to enforceable permissions, approval requirements, and clear escalation paths.

Knowing that finance should approve a refund does not prevent an agent from issuing it. The system needs to enforce the rule, and someone needs to own what happens when the rule is unclear.

Attendees will leave with a practical approach to making a workflow understandable and delegable, including what an agent needs to know, what it may decide, and when it must bring a person into the work.

Key Takeaways

• Identify the unwritten procedures and exceptions that people rely on to work across an organization.
• Distinguish knowledge about how to perform a task from authority to perform it.
• Preserve the source and ownership of operational guidance so agents can handle conflicting or outdated information.
• Translate decision rights into permissions and approval controls enforced outside the model.
• Design escalation paths for situations where policy, context, or authority is insufficient to proceed.

Questions

• What would an experienced employee know about this task that an agent could not learn from the API documentation?
• Which unwritten rules represent real policy, and which are habits or workarounds we should reconsider?
• How should an agent respond when a customer message conflicts with an internal procedure?
• Where should we enforce the difference between being able to take an action and being authorized to take it?
• Who is responsible for resolving an exception and updating the guidance for the next person or agent?