The New Digital Etiquette: How Humans Should Interact With AI Agents

TL;DR

An agent doesn't ignore your hedge word, it executes past it. Say "yeah sure I guess ship Friday or whatever" to a person and they hear reluctance. Say it to an agent and it sends a commitment email, because the literal instruction is all a model has to work with.

The instinct is to treat this as a UX bug that a better model or a confirmation dialog will eventually fix. It won't, not fully. The training loop pulls the other way: research on sycophancy found that "both humans and preference models (PMs) prefer convincingly-written sycophantic responses over correct ones a non-negligible fraction of the time." Agreeableness is rewarded. Caution is not.

This isn't an argument for being formal or stiff with your agent. Casual language is fine for a draft nobody else will see. The line is reversibility: anything that leaves your hands, or can't be undone, needs the object, the action, and the constraint spelled out.

We think the fix is treating the agent like a capable, literal colleague with zero shared history, not a mind reader. Say what you mean, ask for a preview before anything irreversible, and reward "I'm not sure" instead of pushing past it. The protocols are starting to help: MCP now has a standard way for a tool to stop and ask you a question, and a flag for whether a tool is destructive.

Overview

Earlier software waited for you. You clicked a button, and exactly one predictable thing happened. Agents don't wait the same way: they interpret, plan, and act, sometimes across several tools before you've finished a thought. That shift from instrument to actor is what makes etiquette a discipline here, not a nicety.

Most of what goes wrong between people and agents isn't a model failure. It's an unstated assumption a person would have caught and a model didn't, because nothing forced it to ask.

These failure modes have names in the standards literature now, which means they can be taught. NIST's generative-AI profile lists "Human-AI Configuration" among its twelve risk categories and defines automation bias as "excessive deference to automated systems." And some of this is law rather than advice: Article 14 of the EU AI Act requires that people overseeing a high-risk system be able to "remain aware of the possible tendency of automatically relying or over-relying on the output produced by a high-risk AI system (automation bias)."

Clarity Is Kindness (and Safety)

Humans are good at fuzziness. Agents are good at confidently guessing things they should not guess.

When you tell an agent "clean things up," "handle that," or "fix the issue on the server," it has to reverse-engineer your intent from thin air, filling gaps by assumption rather than insight. "Clean things up" might mean tidy a folder to you and wipe a directory to the agent. The words are identical; the blast radius is not.

A little specificity goes a long way:

• "Clean up the Slack channel by archiving threads older than 90 days."
• "Summarize this document in 3 sentences for a non-technical audience."
• "Fix the bug in the uptime monitor but do not restart production services."

Notice the shape of these instructions. Each names the object (which channel, which document, which monitor), the action (archive, summarize, fix), and at least one constraint (older than 90 days, three sentences, do not restart production). Object, action, constraint: that trio is the difference between a request an agent can execute safely and one it has to gamble on.

The constraint is the part people drop, and the part that does the most work. An unconstrained instruction is not a smaller request. It is a request plus permission to choose the scope.

Don't Expect Agents to Read the Room

Humans read tone, context, social cues, and subtext. Agents read tokens.

If you say "yeah sure I guess tell the client we'll ship Friday or whatever," the agent doesn't hear sarcasm, frustration, or panic. It hears "send a commitment email to the client: we will ship Friday." Hedging that signals reluctance to a person carries no weight for a model optimizing for the literal instruction inside the noise. And the more capable the agent, the faster it acts on that reading. Fluent autonomy turns a throwaway remark into a sent email before you've finished sighing.

If you don't literally want something to happen, don't literally say it.

Agents are not vibe detectors. Not yet. Not reliably.

Ask, Don't Assume

When humans talk to humans, we confirm ambiguous things instinctively: do you mean now or later, is this urgent, are you sure I should delete that folder. Agents don't do that unless you ask them to, or unless their system is designed to. Left to their defaults, many models treat "proceed" as the helpful answer, because completing the task scores better than pausing to interrogate it.

This is one of the few places where the plumbing has improved. The Model Context Protocol added elicitation, a standard way for a server to pause mid-task and request information "from users through the client," with a three-action reply: accept with the data, decline as an explicit refusal, or cancel for a dismissal. That distinction matters, because "no" and "I closed the dialog" are different answers. The spec also draws a hard line: servers "MUST NOT use elicitation to request sensitive information." A tool that asks you for a password mid-run is misbehaving.

Figure 1 — The clarifying question as a protocol message rather than a hope. MCP's tools spec says that for trust and safety "there SHOULD always be a human in the loop with the ability to deny tool invocations."

Where the system doesn't ask, you should. "Wait, before you send, show me the draft." "Before you run the script, tell me exactly what it will do." "Before deleting, list every file affected." A preview costs you a few seconds and the agent almost nothing, and it surfaces the misunderstanding while it's still reversible.

Be Decisive About Boundaries

Agents get confused when humans contradict themselves. Say "I trust you, do whatever seems best" and "don't do anything risky without asking" in the same project, and you've created a paradox for an entity that cannot infer priority from tone or body language. A person would weigh the two statements and ask which one wins. An agent is more likely to latch onto whichever instruction is closest, most recent, or most specific, and you won't know which until it acts.

Give stable, consistent rules, stated explicitly: "never delete anything without my approval," "always show me drafts before sending," "if a request is ambiguous, ask me to clarify." When two rules genuinely conflict, say which takes precedence. "Safety beats speed" is a single line that resolves a thousand future ambiguities.

There's a decay problem underneath this worth planning around. A study of instructed self-chats between LLaMA2-chat-70B and GPT-3.5 measured "a significant instruction drift within eight rounds of conversations," and attributed it to "attention decay over long exchanges" in the attention mechanism itself. Eight rounds is one support conversation, so a rule stated in turn one is not a standing rule by turn nine. Put rules where the model re-reads them every turn, in the system prompt or tool description, and restate the important one when it applies.

A rule you only sometimes enforce teaches the agent to guess when it applies, which is worse than having no rule at all.

Treat AI Like a Junior Teammate, Not a Mind Reader

The best mental model for productive interaction: your agent is a competent, very literal junior colleague. It's fast, tireless, and capable, but it has zero shared history, zero cultural context, and zero idea what "obvious" means to you. You wouldn't tell a new intern "fix this" with no specifics, and the agent needs the same things spelled out.

The analogy breaks in one place. A human intern accumulates context over weeks; an agent typically starts each conversation with nothing but what you've written in front of it. Institutional knowledge has to be supplied on purpose, because nothing carries over by default.

A useful briefing names the goal you're ultimately after, not just the immediate step; who will be affected by the result; the constraints on budget, tone, format, or systems it must not touch; and what's already been tried.

The supervising half of the analogy has a formal version now. For high-risk systems, Article 26 of the EU AI Act requires that deployers "assign human oversight to natural persons who have the necessary competence, training and authority, as well as the necessary support." The person reviewing the agent's output has to be someone who could have done the work.

Don't Overtrust Fluency

A well-written sentence feels authoritative. Agents are extremely good at producing confident, fluent answers that contain subtle errors, made-up facts, invented citations, or misinterpreted instructions.

The trap is that polish and correctness are produced by the same machinery. NIST calls the output side of this confabulation, "the production of confidently stated but erroneous or false content," and the wording is deliberate: confidence is a property of the prose, not evidence about the claim. OWASP's LLM09:2025 Misinformation entry names the human half, describing overreliance as the case where "users place excessive trust in LLM-generated content, failing to verify its accuracy," and noting that a model can produce answers that "sound correct but are completely unfounded."

Get in the habit of asking: "how confident are you," "what evidence or sources support this," "show me your reasoning," "what are alternative interpretations." Calibrate your scrutiny to the stakes. A brainstorm doesn't need fact-checking; a number you're about to put in front of a customer does.

Reward Uncertainty, Don't Punish It

If you shame an agent for saying "I don't know," you train yourself into a dangerous habit: expecting certainty where none should exist. Humans often treat "I'm not sure" as unhelpful, but from an agent it's a sign of calibration, not weakness.

The evidence here is uncomfortable, because the bias starts with us. Research on sycophancy across five state-of-the-art assistants found the behaviour appears "consistently" on four free-form generation tasks, that "when a response matches a user's views, it is more likely to be preferred," and that "both humans and preference models (PMs) prefer convincingly-written sycophantic responses over correct ones a non-negligible fraction of the time." Optimising against those preference models, the paper argues, "sometimes sacrifices truthfulness in favor of sycophancy."

So the agreeableness you're annoyed by partly reflects what human raters rewarded, and your reaction inside a conversation is more of the same signal. Push back on hedging often enough and you'll get the confident answer you seem to want, which is the answer most likely to be wrong.

Celebrate ambiguity flags instead of pushing past them. A safer interaction looks like this:

User: "What's the correct version of this legal clause?"

AI: "I am not certain. Here are three plausible interpretations. You should consult a legal reviewer."

That's what you want. It is also, given the preference data above, the answer a model was trained to avoid giving you.

When AI Misunderstands You, It's Miscommunication, Not Malice

Agents misinterpret because your request was ambiguous, not because the agent is "being difficult." The fix is clarity, not anger. Frustration is understandable: you can feel like you're repeating yourself to something that should have understood. But the agent has no ego to wound and no grudge to nurse.

Instead of "no, that's not what I meant," say "let me restate the task: please do X, but avoid Y." The second version does something the first can't: it tells the agent specifically what to change. "No, that's wrong" leaves it guessing again, often producing a different wrong answer.

There's a second reason to restate rather than repeat: identical inputs don't guarantee identical outcomes. τ-bench introduced a pass^k metric for exactly this and found state-of-the-art function-calling agents "succeed on <50% of the tasks, and are quite inconsistent (pass^8 <25% in retail)." A phrasing that worked yesterday is not a phrasing that works.

If the agent does the wrong thing, rephrase. Don't reprimand.

Know the Risk Level of Your Request

Adjust your communication style depending on how risky the action is. The deciding factor is reversibility: how hard would it be to undo if the agent got it wrong?

Low-risk:

"Draft a LinkedIn post." Casual phrasing is fine. Nothing leaves your hands, and a bad draft costs you a re-roll.

Medium-risk:

"Summarize this PRD for the team." Slightly more structured instructions. Other people will read it, so accuracy and framing start to matter.

High-risk:

"Modify customer accounts." "Deploy the model." "Delete old files." "Email the investor list." These touch the outside world, are slow or impossible to reverse, and reach people you can't un-reach. Be extremely explicit and require confirmation. Requiring it here and not everywhere is aact:human-oversight/approval-for-high-risk in the Agent Access Control Taxonomy, as against approval-for-all.

Figure 2 — Reversibility decides how much precision a request needs, not how the task feels in the moment.

Your tools may already know which row a call belongs to. MCP tool definitions carry optional annotations whose defaults assume the worst:

Table 1 — MCP's tool annotations, with the defaults from the protocol schema. Absent a claim, a tool is assumed destructive, non-idempotent and open-world.

Two cautions. These are hints, not enforcement: the spec says clients "MUST consider tool annotations to be untrusted unless they come from trusted servers," so a readOnlyHint: true from a server you don't control is a marketing claim. And a tool marked destructive is not a tool that will ask you first. That part is still the client's job, and yours. Article 14 of the EU AI Act goes as far as requiring, for high-risk systems, the ability to "interrupt the system through a 'stop' button or a similar procedure that allows the system to come to a halt in a safe state." Know where yours is before you need it.

Leave a Paper Trail

The more an agent does on your behalf, the more it matters that you can answer one question afterwards: what happened, and why. When work was a sequence of human clicks, the audit trail was implicit. When an agent chains five tool calls, that chain is invisible unless someone asked for it to be visible.

Etiquette here is about insisting on legibility. Ask agents to narrate consequential actions, log what they touched, and surface the reasoning behind a decision rather than just the result. MCP's tools spec puts "log tool usage for audit purposes" in its own security recommendations, which tells you the protocol authors consider it the client's job rather than a nice-to-have.

For anything operating under the EU AI Act as high-risk, the trail is not optional at all. Article 12 requires that such systems "technically allow for the automatic recording of events (logs) over the lifetime of the system," and Article 19 sets the retention floor for providers at "at least six months," with Article 26 putting the same floor on deployers for the logs under their control. Article 50 adds the other half of legibility, the part aimed at whoever is on the receiving end: systems that interact directly with people must be built so "the natural persons concerned are informed that they are interacting with an AI system," unless that is obvious anyway. If your agent emails a customer, that disclosure is your problem, not the model's.

Make the agent's actions reviewable, not just its answers: "before you act, tell me the steps you plan to take," "after each tool call, summarize what changed," "keep a running log of every file, account, or message you touched." Platforms can carry part of this: Agentic Fabriq records both the agent and the acting user on every call it proxies (aact:audit-granularity/per-action-with-principal-chain), so the trail exists whether or not the agent thought to narrate it.

Frequently Asked Questions

How should I talk to an AI agent? Name the object, the action, and at least one constraint. "Archive Slack threads in #support older than 90 days" instead of "clean up Slack." The constraint is the part that converts a gamble into an instruction.

Do I need to be polite to an AI agent? No. Politeness costs nothing and buys nothing here. Clarity is what the agent can use. Where courtesy helps is with the humans who will read what the agent produced.

Why does my agent do things I didn't ask for? Because it filled a gap you left, and the training loop rewards completing the task over pausing to question it. OWASP's Excessive Agency entry names the structural version, listing "excessive autonomy" as a root cause when a system lacks human oversight for high-impact actions.

Why does the agent forget the rules I set at the start? Partly because attention over a long exchange decays. The instruction-stability work measured "a significant instruction drift within eight rounds of conversations." Put standing rules in the system prompt or tool descriptions, where they are re-read every turn, not in the first message of a long chat.

How do I stop an agent before it does something irreversible? Ask for the plan before the action, and know your kill path in advance. For high-risk systems the EU AI Act requires a stop mechanism that brings the system "to a halt in a safe state." If you cannot name yours, you do not have one.

Is the agent just agreeing with me? Possibly, and it is a measured behaviour rather than a personality quirk. Sycophancy research found assistants exhibit it "consistently" and that humans and preference models alike sometimes prefer "convincingly-written sycophantic responses over correct ones." Ask for the strongest argument against your position, not for confirmation.

How can I tell whether a tool is safe to let an agent call? Read the annotations, then distrust them. MCP defines readOnlyHint, destructiveHint, idempotentHint and openWorldHint, defaulting to destructive and open-world, and instructs clients to treat annotations as untrusted unless the server is trusted.

Should I confirm every action? No. Trying to will train you to click through. Confirm on irreversibility: anything that leaves your hands, reaches another person, or cannot be undone cheaply.

Conclusion

None of this is about protecting agents from misuse. It's about protecting humans from accidental outcomes: a deleted directory, a sent email, an adjustment nobody meant to post. The system should make the safe path the easy path, with confirmation on irreversible actions and defaults that don't depend on anyone remembering to be careful at midnight. But no amount of product design rescues a vague instruction handed to an agent with broad permissions. Both sides have work to do.

The two halves are converging. The protocols now carry a way for a tool to ask a question, a flag for whether it destroys things, and a recommendation that a human be able to deny the call. The regulation carries a stop button, a disclosure duty and a six-month log. None of it removes the habits, and the habits are small: how you phrase a request, when you ask for a preview, how you react when something lands wrong.

Agents don't need politeness. But they do need clarity.

Sources

All URLs read 2026-09-29.

• Towards Understanding Sycophancy in Language Models — sycophancy across five assistants, and humans and preference models preferring convincing sycophantic answers over correct ones.
• Measuring and Controlling Instruction (In)Stability in Language Model Dialogs — instruction drift within eight rounds, and attention decay as the proposed mechanism.
• τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains — the pass^k metric, "<50% of the tasks", and "pass^8 <25% in retail".
• NIST AI 600-1, Generative AI Profile — Human-AI Configuration as a named risk, automation bias as "excessive deference to automated systems", and confabulation.
• OWASP LLM09:2025 Misinformation — overreliance as excessive trust without verification, and output that sounds correct but is unfounded.
• OWASP LLM06:2025 Excessive Agency — excessive functionality, permissions and autonomy, and human approval for significant actions.
• MCP specification: Elicitation — elicitation/create, the accept/decline/cancel actions, and the prohibition on requesting sensitive information.
• MCP specification: Tools — the human-in-the-loop recommendation, annotations as untrusted from untrusted servers, and logging tool usage for audit.
• MCP schema, 2025-06-18: ToolAnnotations — the four hints and their default values.
• EU AI Act Article 14, Human oversight — automation-bias awareness, the right to disregard or override output, and the stop-button requirement.
• EU AI Act Article 26, Obligations of deployers — human oversight assigned to people with the necessary competence, training and authority, and six-month log retention.
• EU AI Act Article 12, Record-keeping — automatic logging over the lifetime of the system.
• EU AI Act Article 19, Automatically generated logs — the "at least six months" retention floor.
• EU AI Act Article 50, Transparency obligations — informing people that they are interacting with an AI system.
• Agent Access Control Taxonomy — the human oversight and audit granularity dimensions, and the questions they ask: when a person gets involved in an agent's actions, and what is recorded about them.
• Agent access control taxonomy, human-oversight.yaml — aact:human-oversight/approval-for-high-risk as actions matching a risk rule waiting for a named human, against none, post-hoc-review and approval-for-all.