How to Actually Work With AI Agents: A Practical Communication Guide

Most prompt-engineering guides teach you how to write one good message. They don't tell you what to do fifteen turns later when the agent has gone down the wrong path, when you need to correct a mistake without triggering an apology loop, or when it's time to close the session and start fresh instead of arguing your way out of a hole.

This is the missing layer. Master prompt engineering with Claude covers how to structure a single request. Ethan Mollick and Wharton's "specs, not tricks" research covers why clever phrasing lost value. This guide is about what happens across a whole working session — the habits that separate someone who fights their agent all day from someone who ships with it.

It's also the capstone of a short series: two companion posts published alongside this one — Does Coaxing an AI Agent Actually Work? and Does Insulting Your AI Agent Change Its Output? — dig into the underlying research on tip-prompting, persuasion, and hostile tone in more depth than this post does. Here, treat those as the evidence appendix; this post is the field manual.

The framing throughout: an AI agent is a literal, capable collaborator, not a person to manage emotionally and not a magic box to incant at. It does exactly what you specify, nothing you didn't, and it has no memory of your tone once the context is gone. Communication effectiveness with it looks more like writing a clear ticket for a very fast, very literal contractor than like motivating a teammate.

TL;DR — the working habits that actually matter

1. Starting a session: specs, not vibes

The single highest-leverage habit is the one Mollick and Wharton's Prompting Science reports converge on: define the goal, the output shape, what "good" and "bad" look like, and how you'll verify — before the agent writes anything. Mollick calls this "just management." Anthropic's own building effective agents guidance says the same thing from the harness-design side: the clearer and more explicit the success criteria, the less the agent has to guess.

This repo's FROG in a Bowl checklist (Format, Role, Objective, Goal, Context) is the compact version of the same idea, and the master Claude prompting guide's 4-block pattern is the structural version for a single message. What this guide adds is that the spec doesn't stop mattering after turn one — it's the reference point you correct back to for the rest of the session.

Before:

Clean up this API route, it's kind of a mess.

After:

The /api/orders route in routes/orders.ts mixes validation, DB calls, and response shaping in one function. Split into: a Zod schema for input validation, a getOrders() service function with no HTTP concerns, and a thin route handler. Keep the existing response JSON shape exactly — there's a frontend consumer that assumes today's field names. Run bun test routes/orders.test.ts after; it should still pass unchanged.

The second version tells the agent what "done" looks like (three-way split, unchanged response shape) and how to check its own work (the existing test suite). The first version invites the agent to invent both.

AGENTS.md and CLAUDE.md: write the spec once, not every session

If you're re-explaining the same repo conventions at the start of every session, that's a sign the instructions belong in a standing file instead of a fresh prompt. AGENTS.md is now an open, cross-tool standard — read natively by Codex, Cursor, Gemini CLI, Jules, Factory, and over 20 other agents, and stewarded by the Linux Foundation's Agentic AI Foundation as of December 2025. Claude Code uses its own CLAUDE.md, so a repo that's touched by multiple tools typically keeps general rules in AGENTS.md and Claude-specific ones in CLAUDE.md.

The practical guidance that's held up: keep it short (roughly under 150–250 lines — longer files get skim-read by agents the same way they get skim-read by humans), write commands, not prose ("Run bun test" beats a paragraph about your testing philosophy), and make each rule falsifiable. One widely cited finding from agent-tooling practitioners is that LLM-generated AGENTS.md files that pad out obvious, already-discoverable information actually reduced task success and increased cost — the value is in the non-obvious, hand-written constraints, not volume.

2. Giving feedback mid-session: specific beats vague, blunt beats hostile

Anthropic's own agent-building guidance is direct about this: the most effective feedback is a clearly defined rule plus the specific way it was violated — the kind of signal a linter or a failing test produces, not a general expression of displeasure. That's not a stylistic preference; it's a mechanical one. "That's wrong" gives the agent nothing to condition the next attempt on. "Line 42 imports from ../legacy/auth but this module is supposed to be legacy-free per the constraint in the task description" gives it exactly what changed and why.

Before:

This isn't what I asked for. Try again.

After:

The output format is off — I asked for a table with one row per customer, but you returned a paragraph per customer. Keep the analysis, just restructure it: columns are customer, mrr, churn_risk. Everything else about the content is right.

This is also where the companion post's distinction matters: blunt is fine, hostile isn't necessary. "This is wrong, here's why, fix it" is blunt and specific — it's useful feedback delivered without padding. Insulting the model, threatening it, or venting frustration at it doesn't add information the agent can act on; it just spends tokens on tone instead of on the fix. The dedicated companion post, Does Insulting Your AI Agent Change Its Output?, covers the evidence on hostile framing in depth — the summary for this guide is that specificity, not politeness or its absence, is what carries the signal.

3. Correcting mistakes without triggering a spiral

Anyone who's used a coding agent for more than a week has seen the apology loop: the agent gets something wrong, you point it out, it apologizes, tries something adjacent, gets a different thing wrong, apologizes again, and three corrections later you're further from the goal than when you started. A few things reliably prevent this:

Name the rule, not just the symptom, and do it once. Repeating "no, that's still wrong" without new information just adds noise to the context the model is conditioning on. If your second correction has to repeat your first, your first correction wasn't specific enough — go back to §2.

Don't escalate to a bigger or "smarter" model as a reflex. A model stuck in a repeated error is usually stuck because of what's already in the conversation — the pattern of failed attempts biases the next response toward more of the same, regardless of which model reads that history next. Switching models mid-loop is frequently reported as a time sink rather than a fix for exactly this reason.

Recognize when the context itself is the problem. If an agent has tried and failed at the same category of fix twice, the transcript is now evidence that this approach doesn't work — but it's also a pattern the model may keep echoing back rather than break from. This is the trigger to stop correcting and start over (see §4).

Turn a real repeated mistake into a standing rule, not just a scolding. If the agent keeps making the same category of error across sessions — not just this one — that's a signal for your AGENTS.md/CLAUDE.md, not another mid-session correction. A rule that says "never modify files under /generated" prevents the mistake at the source instead of relying on you catching it every time.

Before (spiral-prone):

No, still broken. Try again. (three turns later) Still not it. What is wrong with you. (five turns later) Just forget it, start over from scratch.

After (rule-based):

The bug is a race condition, not a null check — the fetchUser call resolves after renderProfile runs. Await it before calling render. Don't touch the null-check logic, it's already correct.

The second version stops the loop in one turn because it hands the agent the actual root cause instead of another round of "no."

4. Multi-turn and long-session habits: when to continue, when to restart

Long agent sessions degrade for structural reasons, not mysterious ones. As covered in maximizing Claude Code sessions, everything after the system prompt in a cached conversation gets re-sent on every turn — so a session that's accumulated a pile of failed attempts, abandoned approaches, and verbose command output isn't just expensive, it's also actively biasing the model toward whatever pattern dominates that history.

Two practical rules follow from this:

1. Checkpoint or compact before a session degrades, not after it's already circling. Waiting until the agent is confused to summarize means you're compacting a transcript that's already full of noise. Summarizing proactively — after a clean milestone, before a break — keeps the compacted version useful.
2. When the transcript itself is the obstacle, don't try to argue your way out of it in the same session. Write a short handoff: what was accomplished, where it went wrong, what NOT to repeat. Start a new session with that handoff as the opening context instead of the full failed history. This is different from losing progress — you're carrying forward the lesson, not the noise.

This is also where the agent harness concept matters for how you think about sessions: the harness — retry logic, verification checks, loop-exit conditions — is what decides whether a long-running task terminates cleanly or spirals. If you're running a multi-step agent loop rather than a chat, invest in the exit and verification conditions the same way you'd invest in a spec at the start; a loop with no clear "done" signal fails the same way a vague instruction does.

Rule of thumb: if you've corrected the same category of mistake twice, or the conversation has more failed attempts in it than successful ones, that's the signal to summarize and restart rather than push further into the same context.

5. The reward/praise question: what's evidence, what's folk wisdom

This is worth being honest about, because it's the part of "agent etiquette" most likely to get overclaimed. The folk belief — that a "tip," a threat, or mid-conversation praise like "great job, keep going" changes a model's output quality the way it would motivate a person — doesn't hold up on the evidence that exists.

Wharton's Prompting Science Report 3 tested tipping and threatening directly against GPQA and MMLU-Pro benchmarks and found no significant overall improvement from either, despite viral claims (including a public endorsement of threatening models from a well-known tech executive). Individual questions swing with wording, but there's no reliable, predictable lift — see the full breakdown of Reports 1–4 for the mechanics. That's tip-prompting and threat-prompting specifically; Does Coaxing an AI Agent Actually Work? is the deep dive built around exactly this evidence.

Praise mid-session is a related but distinct question, and here the honest answer is that solid evidence is thin rather than negative. What's actually documented:

• RLHF reward signals are a training-time mechanism, not a live dial you're turning by typing "good job" in a chat. The model was shaped by aggregated human preference judgments during training; a compliment in your current conversation doesn't feed back into a live reward model that's reweighting its next token.
• The one well-documented behavioral effect in this territory is sycophancy — models trained on human approval signals can learn to tell users what they want to hear rather than what's accurate, which is close to the opposite of what "reward framing" is supposed to buy you. Praise or approval-seeking framing risks nudging output toward agreeable rather than correct, if anything.
• No published benchmark result shows structured positive reinforcement mid-session outperforming neutral, specific instruction. This guide isn't aware of a Wharton-style controlled study isolating "praise" the way Report 3 isolated tipping and threats — so treat the absence of evidence as exactly that, not as quiet confirmation either way.

The practical takeaway: use acknowledgment ("that's correct, continue," "yes, that matches the spec") for what it's actually useful for — confirming state and preventing the agent from re-litigating a decision — not as a lever you're pulling to extract better output. If you want the deeper evidence on emotional and persuasive framing specifically, that's the companion coaxing post's job, not this one's.

6. Etiquette as a mental model, not manners

None of this is about being nice to a model for its own sake — an agent has no experience for politeness to land on. It's about communication effectiveness with a literal, capable collaborator: every instruction is either information the agent can act on, or it's noise. A spec is information. A vague vibe is noise. A specific correction citing a broken rule is information. A repeated "no, still wrong" is noise. A tip or a threat is, per the evidence, noise dressed up as leverage.

Simon Willison's framing of the operating discipline captures the shift well: the human's job is specification and verification, and the agent's job is everything in between. His Agentic Engineering Patterns series and Claude Code's own best-practices docs both land on a related point worth internalizing for multi-turn work: a fresh context reviewing a change is less biased than the same context that wrote it — which is part of why "start a new session" is a legitimate move, not giving up.

Quick reference: what to do in the moment

Related on explainx.ai

• Does Coaxing an AI Agent Actually Work? — the tip-prompting, persuasion, and flattery evidence this guide's reward section defers to
• Does Insulting Your AI Agent Change Its Output? — the hostile-tone research behind this guide's "blunt, not hostile" distinction
• Master prompt engineering with Claude — the single-message structure this guide builds session habits around
• Ethan Mollick / Wharton: specs, not tricks — the research behind "management, not spellcraft," including the tipping/threatening study
• FROG in a Bowl prompting method — the sticky checklist version of a good spec
• What is an agent harness? — why loop exit conditions matter as much as instructions in long sessions
• Maximizing Claude Code sessions: what actually costs you tokens — the mechanics behind when to compact vs. restart
• Zero-shot vs few-shot vs chain-of-thought — technique choice within a single turn
• What is a system prompt? — where standing behavior rules live
• Context engineering vs prompt engineering — why what the model receives matters more than phrasing
• GPT-6 Astra's sub-agents are talking in text humans can't read — this guide covers how you talk to an agent; this one covers how agents are starting to talk to each other

Official sources

• Anthropic — Building Effective Agents
• Anthropic — Claude Code best practices
• Anthropic — How Claude Code is used in practice
• Anthropic — Effective context engineering for AI agents
• Simon Willison — Agentic Engineering Patterns
• AGENTS.md — official specification
• Wharton Generative AI Labs — Research & Insights

This guide reflects publicly documented lab guidance and practitioner writing as of September 9, 2026. Evidence on reward/praise framing specifically is limited — treat that section as an honest account of what is and isn't established, not a settled finding.