Policies

Policies define explicit rules, limits, and boundaries that DelegateZero must respect. They are the strongest form of context. When a policy applies, it overrides most other signals.

Some examples of basic policies that you might add include:

• I generally don't approve new tools or subscriptions without first checking whether we already have something that does the same thing. If it's unclear, escalate.
• When replying to clients, keep the tone professional and concise. Avoid humor or casual language unless the client initiates it.
• Do not commit me to meetings outside of 9am–5pm unless it's already marked as urgent or pre-approved.
• Every time we communicate with ABC Company, address messaging to Melissa
• Sign off every email with "Thanks, -Tyler"

These policies are fine for basic ideas, but they should really be fleshed out a good deal more. Below are some better examples.

Client-specific communication policy:

For ABC Company:
-Always use a formal tone
-Do not mention internal tools or processes
-Avoid sharing raw metrics unless they have already been discussed
-If a request involves scope or pricing changes, acknowledge receipt and escalate instead of responding

This works better because: it is scoped to a specific entity, it covers tone, content, and escalation, and it prevents common mistakes.

Platform-specific response rules:

-In Slack, responses should be brief and task-oriented.
-In email, provide more context and complete explanations.
-Never send long explanations in Slack — if more detail is needed, suggest moving to email.

This is helpful because it differentiates communication by channel, improves response quality, and is easy to apply consistently.

Content approval and publishing policy:

Do not publish or send externally facing content unless:
-The information is already public or approved
-The tone matches previous communications
-No speculative claims are included
If content is informational but not time-sensitive, generate a draft and request review instead of sending.

This policy helps to protect against reputational risk, distinguishes draft vs execute, and applies across many content types.

Conservative default behavior:

When context is incomplete or conflicting, default to escalating instead of making assumptions.
If a decision would materially affect a client relationship, err on the side of asking.

This policy is pretty conservative, but it aligns with human risk tolerance, improves trust early on, and helps to reduce false positives.

Policies are best used for hard constraints and non-negotiable rules, but some other things you should keep in mind:

• Policies aren't just numeric thresholds
• They can be scoped by client, platform, or content
• They encode judgment, not just rules