Most AI agent reports read like they were written for an engineer, even when the person reading them runs a 40-person company and just wants to know what happened yesterday. We've watched this happen inside more than one client build: an agent that reasons well produces a summary nobody on the team actually reads, because it's dense, hedged, and full of terms nobody asked for. The fix isn't a smarter model or a longer prompt. It's a settings problem, and it has a precise, verifiable answer.
Two failure modes, one root cause
When we audit an agent system that's underperforming, the complaint is almost never "the agent got it wrong." It's "nobody reads what it sends." That breaks down into two patterns. The first is jargon density: the agent assumes the reader knows every acronym and technical term in the domain, so a simple question gets an answer full of vocabulary the reader has to look up before they can act on it. The second is the wall of text: a yes-or-no question gets a five-paragraph essay, which is fine for a debugging session and useless for a daily briefing an owner reads on their phone between meetings.
Both patterns are avoidable, but not by adding a line to your instructions file that says "be concise." We tried that first too. It works for a turn or two, then drifts. The reason it drifts is structural, and it's documented by Anthropic if you know where to look.
Why CLAUDE.md alone doesn't hold
If you run Claude Code, you probably have a CLAUDE.md file with project rules, conventions, and maybe a line about tone. According to Anthropic's own documentation on how Claude Code loads memory, CLAUDE.md content is delivered as a user message after the system prompt, not as part of the system prompt itself. It's real context the model reads and tries to follow, but it's one message among many others competing for weight as a session runs long.
That single fact explains a lot of what we'd been seeing. A rule buried in a project instructions file is context. A rule baked into the system prompt is closer to identity. Those are not the same strength of signal, and over a long agent session, the difference shows.
The setting that actually holds: output style
Claude Code has a separate mechanism built for exactly this problem: output styles. Per Anthropic's output styles documentation, an output style directly modifies the system prompt. Claude Code adds the style's instructions to the end of the system prompt, and critically, all output styles trigger reminders for Claude to keep following those instructions as the conversation continues. That's the mechanism CLAUDE.md doesn't have. It isn't just loaded once and hoped for; it's actively reinforced turn after turn.
You can also choose whether an output style keeps Claude Code's built-in software engineering instructions active, using the keep-coding-instructions flag. Keep it on if the agent still needs to write and verify code but should communicate differently. Leave it off when the agent isn't doing engineering work at all, which covers most of the reporting and briefing agents we build for clients. Anthropic's system prompt documentation covers the underlying mechanics of how these prompt layers stack, if you want to go deeper than the Claude Code specific docs.
What we actually set for client builds
For any agent that produces a report, summary, or briefing a non-technical operator has to read and act on, we now set a dedicated output style before we touch anything else. The instructions are simple: lead with the answer, not the reasoning. State the one thing the reader needs to know in the first sentence. Cut jargon and acronyms unless the reader uses them daily; if a technical term is unavoidable, define it in five words or fewer. Default to short. If a longer explanation is genuinely needed, offer it as a follow-up rather than forcing it into every reply.
That's it. No clever prompt engineering, no fifteen-paragraph persona document. The output style is a markdown file with frontmatter, stored once, applied to every session, and reinforced automatically. It's a configuration decision, not a writing exercise.
One adjacent detail worth knowing if you're managing an agent's memory too: Claude Code's own auto-memory index, documented alongside the rest of Claude Code's settings, caps at 200 lines or 25KB, whichever comes first. Anything past that threshold silently doesn't load at session start. It's a small example of the same underlying lesson: know the limits and behavior of the specific layer you're writing instructions into, because every layer of an agent's configuration has different rules for what sticks.
Where this shows up in the systems we build
Every system we ship reports to a human eventually. An AI Chief of Staff that drafts a daily briefing, a automation agent that flags an exception in a workflow, a Second Brain that surfaces the three things that changed since yesterday: all of it fails quietly if the output is technically correct but unreadable to the person it's for. We run our own real estate group on these systems internally, and the test we apply is simple. If an ops manager with no AI background can't act on the report in under thirty seconds, the output style is wrong, not the model.
This is also why we don't treat "add AI to the business" as a single decision. The clients whose systems actually get used are the ones where we tuned the output layer to match who's reading it, not just the task the agent performs. That's part of what we scope in an AI Concierge assessment, where the €999 fee is credited to the build if you move forward: we look at what your team already has running and where the reporting layer is quietly costing you the value of a system that otherwise works. You can see how that's played out for other operators in our case studies.
What to do this quarter
- Audit every AI agent currently reporting to someone on your team. If the reader has to reread it twice to find the point, that's a tone problem, not a content problem.
- If you're on Claude Code, create one output style per audience: technical for engineering work, plain language for anything an owner or ops lead reads directly.
- Stop relying on a single instructions file to carry tone rules across a long session. Put behavioral rules in the layer built to hold them.
- Test the fix on a non-technical stakeholder, not on yourself. You already know the jargon; that's exactly why you're the wrong person to judge whether it landed.
- If you're not sure where your admin time is actually leaking before you automate it, run it through our revenue leak heatmap first.
The bottom line
Operators running 10 to 50 person companies don't need agents that sound impressive. They need agents whose output gets read, understood, and acted on the first time, because the whole point of an agent working 24/7 is that nobody has to translate its output back into plain language before they can use it. The businesses we've watched get real value out of AI systems this year are the ones with 10 or more hours a week of admin work already flowing through agents that report in language their team actually uses. Getting the first system live only takes days to weeks once the scope is right. Getting the tone right is a five-minute settings change most teams haven't made yet. Set the output style before you scale anything else, and read our blog for how we're tuning the rest of the stack this quarter.