Four Copies, a Greyed Out Save Button, a Misspelled Name
AI Team Build · Part 4 of 4
Four Copies, a Greyed Out Save Button, a Misspelled Name
Four things broke while building an AI team. Each one had the same cause, and the fix was never a better prompt.
In short
Four failures while building an AI team: the same rules copied into four places and drifting apart, a Save button that greyed out with no explanation, a misspelled company name repeating in every output for weeks, and a correction that reached one asset but not the others. Every one traces to the same cause, which is information living in more than one place with no agreement about which copy is right.
The frame
Not one of these was a prompting problem
Parts 1 through 3 covered the build. This part covers what went wrong, because the failures are more useful than the wins and almost nobody publishes them.
Every failure below looked like a Claude problem while it was happening. Every one turned out to be a documentation problem wearing a software costume. That distinction is the whole post.
An agent repeats what it was told, exactly, until someone changes what it was told. That is the feature and that is the failure mode.
Failure 1 | Four copies
The same rules lived in four projects and quietly stopped matching
A block of brand rules got pasted into four different agents, because four agents needed it. Over the following weeks each copy got edited in place, during whatever task happened to be running. A word added here. A rule tightened there.
Nobody edited all four. Within a month the four agents were following four slightly different versions of the same standard, and the only way to tell was to open them side by side and read.
The tell: two agents producing work that is almost consistent. Not obviously broken, just slightly off from each other in ways nobody can name. That is drift, and it compounds silently.
The fix
One document holds the rules. Every agent that needs them gets that document uploaded as project knowledge, not pasted into its instructions. Changing the rule means changing one file and re-uploading it, instead of remembering four places.
The instruction then says where the standard lives rather than restating it. One sentence pointing at the file beats four copies of the file.
Failure 2 | The greyed out Save button
The instruction would not save, and nothing said why
A long instruction went into a project instructions field. Save did nothing. Refresh, retry, retype, same result. The assumption was a bug.
The instruction was simply too long for the field. Anthropic does not publish the character counts. Like One's 2026 guide, which tracks these limits, puts the account wide field at 1,500 characters and project instructions at roughly 8,000 (Like One, Claude Custom Instructions Guide), and reports a live counter in the project field as you type (Like One, Claude Projects Custom Instructions Guide). Treat both numbers as a current reading rather than a promise.
The fix
The instruction field holds the job description. Everything long goes into project knowledge as a file. Role, Context, Task, Output format, written tight, will not come near the ceiling. If an instruction is running long enough to hit a limit, that is usually the one sentence mandate test failing: the agent has two jobs.
A limit you hit is usually a design problem announcing itself in the wrong language.
Failure 3 | A misspelled name
The company name was spelled wrong in the instruction, so it was wrong in everything
A typo in the company name made it into a job description. The agent did exactly what a well built agent does: it used the name it was given, consistently, in every output, for weeks.
Consistency is what made it hard to catch. An occasional typo gets noticed. The same spelling every single time reads like the correct spelling.
Worth knowing: for a business name, this is not cosmetic. A name that appears two ways across a website, a directory listing, and a social profile is a name an AI engine has to decide about. Spelling is entity resolution.
The fix
Proofread the instruction the way you would proofread a published page, because functionally it is one. Names, URLs, phone numbers, and email addresses get checked character by character before the instruction is saved.
An error in an output costs one correction. An error in an instruction costs every output until someone notices.
Failure 4 | A correction that only reached one place
This one happened while writing this series
Part 2 of this series corrected a naming error. Earlier drafts used older names for Claude's instruction layers, and Anthropic's current documentation names them Instructions for Claude, project instructions, and skills (Claude Help Center, Understanding Claude's personalization features).
The posts were corrected. The supporting assets built from the same source material were not, at first. For a stretch, the written series and the material beside it were teaching two vocabularies for the same three things.
Which is Failure 1 again, in a different costume. Four years of building habits did not prevent it. A checklist did.
The fix is a question, asked every time something is corrected.
Where else does this exact information live, and who is updating those copies today?
The pattern
All four, side by side
Read the last column down the page. It is the same rule four times.
| What broke | What it cost | The rule now |
|---|---|---|
| Four copies of the same rules | Weeks of almost consistent output nobody could diagnose | One file holds the standard. Agents reference it, never restate it |
| Save button greyed out | An afternoon spent debugging a limit instead of reading one | Instructions stay short. Long material goes in project knowledge |
| Misspelled company name | Weeks of outputs carrying the wrong name, consistently | Proofread the instruction like a published page before saving |
| A correction that reached one asset | Two vocabularies taught for the same three things | Every correction names every place the information lives |
What stayed human
Four things never moved to an agent, and never will
The question is not what an agent is capable of. It is what should carry a human name on it.
Final approval. Nothing reaches a customer without a person reading it first. Every agent on the team ends its output with a line asking for approval, written into the output format on purpose.
The relationship. A discovery call, a hard conversation about a result that missed, a decision about whether a client is the right fit. An agent can prepare for any of these and should sit out all of them.
The standard itself. An agent applies a standard well. It cannot tell you the standard is wrong. Deciding what good work looks like is the job that does not delegate.
The decision to say no. Scope, capacity, and whether a piece of work should exist at all. An agent optimizes the work in front of it. It will never tell you the work should not be done.
The work changed shape rather than disappearing. Less producing, more reviewing, and more writing down what good looks like so something else can produce it.
That shift is harder than it sounds. Reviewing is a skill, and nobody warns you that you will need it.
The through line
Every failure in this post is a management failure
Duplicate instructions that drifted. A job description too big for the role. An onboarding error repeated because nobody checked it. A correction that did not reach the whole team.
Replace "agent" with "new hire" in any of those sentences and they still read correctly. That is not a metaphor used for effect. It is the most accurate description of the work.
You are not prompting a tool. You are building a team.
The honest line
Reading four failures will not prevent your four
You will hit different ones, in a different order, in your own business. What this post can do is shorten the time between a thing breaking and understanding why, because the cause is almost always the same: something true was written down in more than one place.
What this does not do: none of this makes a small business bigger. It makes a small business able to do more without adding people. Those are different outcomes, and only one of them is being promised here.
Do this today, free, under five minutes
Find one rule in your business that is written down in two places. A refund policy, a service area, a set of hours, a brand rule.
Decide which copy is the real one and delete or redirect the other. That is the whole discipline, practiced once.
Common questions
What goes wrong, answered
Why do my AI agents give inconsistent answers to the same question?
Usually because the same rule is written in more than one agent's instructions and the copies have drifted apart. Put the rule in one file, upload that file as project knowledge to every agent that needs it, and have the instructions point at it rather than restate it.
Why will my Claude project instructions not save?
The most common cause is length. The field has a character limit and the Save control can simply stop responding rather than explaining why. Move long reference material into project knowledge files and keep the instruction itself to the role, context, task, and output format.
What should never be handed off to an AI agent?
Final approval on anything reaching a customer, the client relationship itself, the decision about what good work looks like, and the decision to decline work. An agent applies a standard well and cannot tell you the standard is wrong.
The series
All four parts, in order
- 1
Two People, Fifteen People Worth of Work. Why the team is the unit, not the prompt.
- 2
The Three Claude Settings Almost Nobody Touches. Three surfaces, three instruction layers.
- 3
Build One Agent, Chain Two, Connect One Tool. The ten minute build and the handoff line.
- 4
This one. What broke, and what stayed human.
Keep following the build
The next thing we break, you will read about too.
What we are building, what it cost, and what we would do differently. Written by the two people actually running it.
No spam. Unsubscribe anytime.
Start here
Walk through your first two agents with someone who has already broken theirs
A working session, not a pitch. You leave with two job descriptions written, a handoff line between them, and a list of the places your rules currently live twice.
Free. No obligation.