I love Claude. I hate Claude Code (and other "agents"). Is ...
Based on an r/ClaudeAI community discussion
The frustration is real, but the cause is almost always a mismatch in mental models. Claude in the chat app and Claude as an agent share the same underlying model but operate under completely different constraints. Conversational prompting relies on real-time feedback loops; agentic workflows require explicit scope, structured outputs, and designed failure handling before you run a single step.
The gap between the two experiences traces back to a single architectural difference: the chat interface gives you an immediate feedback loop, while an agent must be designed to succeed or fail at each step without your intervention. This tension comes up repeatedly in the r/ClaudeAI community, and the pattern in almost every frustrated post is the same — someone applying conversational prompting logic to a system that requires engineering design.
Claude the chatbot and Claude the agent share the same underlying model. [1] What changes is your responsibility as the person building the system. Talking to Claude in the app is like pairing with a skilled colleague in real time. Building a Claude agent is like writing a detailed operations manual for that same colleague to execute independently while you are away. The colleague does not change — the design burden does.
Two root causes account for most Claude Code frustration: context drift and ambiguity tolerance.
Claude's context window is large, but large is not infinite working memory. [2] As a coding session grows, the model's attention distributes across more tokens, and early instructions receive proportionally less weight than recent ones. The result is code that is locally coherent but globally wrong — the agent interpolates where it should be retrieving, and small misalignments compound across steps.
In chat, "clean this up a bit" is fine — Claude makes a reasonable interpretation and you adjust on the next turn. In an agent pipeline, that same instruction may trigger a cascade of file modifications with no easy undo. [3]
| Design dimension | Claude Chat (app) | Claude Agent / Code |
|---|---|---|
| Prompt style | Conversational, flexible | Precise, schema-driven |
| Error handling | Correct on the next turn | Must be designed in advance |
| Context management | Handled by the interface | Your responsibility to architect |
| Ambiguity tolerance | High — clarify in real time | Low — ambiguity produces unpredictable behavior |
| Output format | Whatever Claude decides | Explicitly specified per step |
| Testing approach | Read and adjust | Unit-test each step independently |
| Failure mode | Bad answer, easy to spot | Cascading errors, hard to trace |
If you are curious how other practitioners have navigated this divide, the writeup on building 18 AI marketing agents for Claude Code covers real workflow structures worth studying.
---Reliable agents share one trait: every step has an explicit input definition, a single task, an expected output schema, and a defined failure behavior.
Before writing a single prompt, define what success looks like for each step independently. A simple framework:
The instinct is to give Claude a large goal and let it figure out the steps. This works in chat; it fails unpredictably in agents. Instead, map the full workflow before writing any prompts, identify natural breakpoints where output can be validated, and build and test each step individually before chaining them together.
In building Buddy, the open-source Google Ads agent, early versions tried to handle campaign analysis, keyword research, bid recommendations, and copy generation in a single sprawling prompt. The output looked impressive but was unreliable. Breaking it into discrete steps — each with defined inputs and outputs — made the system dramatically more stable and auditable. You can explore how that agent works at Buddy, the AI Google Ads agent.
In Claude Code and API-based agents, the system prompt does the heavy lifting that conversational context does in the chat interface. [3] It should specify: the agent's role and operating constraints, what it should and should not modify, how it should handle uncertainty (ask vs. assume vs. skip), output format expectations, and any domain-specific guardrails. A well-written agent system prompt is something you could hand to a new team member and have them understand exactly what the agent is supposed to do.
---For any workflow longer than three or four steps, build in explicit checkpoints where the agent outputs a structured summary of what it has done and what it is about to do. This forces coherent state and gives you a natural debugging surface. In marketing automation workflows — for example, an agent that pulls campaign performance data, analyzes it, and drafts optimization recommendations — a structured state summary before any write operation means nothing gets modified until the analysis step has been confirmed. This pattern alone eliminated roughly 80% of frustrating edge cases in my own production agents.
In long Claude Code sessions, the model can gradually shift its interpretation of its own role as context accumulates — a phenomenon sometimes called persona drift. Counter this by restating the core role and constraints at key transition points, not only in the initial system prompt. Something as simple as "You are [agent role]. Your job in this step is [specific task]. Do not [key constraint]" costs a few tokens and prevents significant drift in longer workflows. [4]
When giving Claude tools — function calls, API access, file system access — follow the principle of least privilege. Only expose the tools needed for the current step. An agent that can simultaneously read files, write files, execute code, and call external APIs has a much larger surface area for unexpected behavior than one restricted to reading during analysis and writing only during output. This is not about distrust; it is about reducing the state space so that when something goes wrong, it is easy to identify what happened.
For agents touching real systems — ad platforms, CRMs, databases — build a validation layer between Claude's output and any action. Claude proposes, your code or a human reviewer validates, the system executes. This keeps Claude in the "intelligent recommendation" role rather than the "autonomous actor" role, which is both safer and easier to debug.
For a deeper look at how agentic tooling connects to external systems, the Model Context Protocol integration docs explain how agents like Buddy expose tools to Claude in a controlled, step-scoped way.
---Claude Code earns its place when the task is well-defined, repeatable, and benefits from auditability. The standard Claude app is often the better choice during exploration and design.
The most effective approach is to use both in sequence. Use the chat interface to explore the problem space and identify the key steps, then systematize that logic into a proper agent. The chat interface is an excellent prototyping environment for what will eventually become agent architecture. Marketers who have made this shift share their experience in the thread on marketers using Claude Code in production workflows.
---No. Claude Code runs on the same underlying Claude model available through Anthropic's API. [3] What differs is the execution environment: Claude Code operates with file system access, tool use, and multi-step autonomy, whereas the chat app is a single-turn or short-session interface. The model's capabilities are the same; the design constraints are entirely different.
Length matters less than completeness. A system prompt should specify the agent's role, what it may and may not do, how it handles uncertainty, and the expected output format for each step. In practice, effective agent system prompts for non-trivial workflows tend to run several hundred words — closer to a technical specification than a one-line instruction.
Yes, through mechanisms like the Model Context Protocol, which standardizes how agents connect to external data sources and tools. [5] The key to doing this safely is scoping tool access to only what the current step requires — read access during analysis, write access only during a validated output phase — and routing all consequential actions through a validation layer before execution.
Yes, for tasks that are well-defined and repeatable — performance data analysis, structured report generation, or drafting optimization recommendations from structured inputs. The pattern that works best in advertising contexts is: Claude analyzes and proposes, a validation step confirms, and a separate process executes. This keeps costly mistakes out of live campaigns while still capturing Claude's analytical capability. See what agents with Claude actually enable for a plain-English breakdown.
Persona drift is when a Claude agent gradually shifts its interpretation of its own role as context accumulates across a long session. Early constraints lose salience relative to the most recent prompts. The fix is to restate the agent's role and key constraints at the start of each major phase — not just in the initial system prompt — so the model re-anchors its behavior at each transition point.
It depends on the use case. For Google Ads specifically, purpose-built agents like Buddy already encode the propose-validate-execute architecture and step-level output schemas described in this article. Building from scratch makes sense when your workflow is genuinely novel or requires deep customization. For most advertising optimization tasks, starting with a validated agent and adapting it is faster and more reliable than building from zero. The getting started guide walks through setup.
More answers in this topic: Claude & Anthropic