The Agreement Layer
Why AI work fails without context, constraints, and operating discipline
Most people do not get bad AI output because the model is useless.
They get bad output because they treat the model like a magic box.
They open a chat window, ask for help, and expect the AI to infer the project, the constraints, the history, the risk tolerance, the desired tone, the source of truth, the pacing preference, the technical environment, and the definition of success. Then they are disappointed when the answer sounds generic, overconfident, or misaligned.
That disappointment is real. But the failure is often not in the model alone.
The failure is in the missing agreement.
A powerful model without an operating frame is like a high-end table saw without a fence. The motor is strong. The blade is sharp. The cut may even look clean. But if nothing is guiding the material, speed becomes part of the danger.
The missing layer in serious AI use is not a clever one-line prompt.
It is an operating relationship.
I call this the agreement layer.
1. The basic claim
The more serious the work, the less useful it is to treat AI as a casual assistant.
For small tasks, casual prompting is fine. Rewrite this paragraph. Summarize this email. Give me five ideas. Translate this message. These do not require much shared context.
But project work is different.
A project has history. It has constraints. It has previous decisions. It has false paths already ruled out. It has source-of-truth rules. It has risk. It has user preferences that are not decorative but operational. It has a pace that should not be violated.
Without those things, the AI is not really helping with the project.
It is responding to a fragment.
The central claim of this paper is:
Serious AI work requires a reusable working agreement that defines how the AI should operate, not just what task it should complete.
The task prompt says what to do.
The working agreement says how to behave while doing it.
Both are needed.
2. Why normal prompting breaks down
Most AI failures in project work follow predictable patterns.
The AI jumps to tools before understanding the problem. It gives a giant command ladder when one verification step would be safer. It assumes a file path, runtime state, or business rule. It proposes a broad refactor when the problem needs a surgical fix. It changes labels or flows casually. It produces confident but ungrounded explanations. It forgets that the user values source-of-truth discipline more than speed.
None of these failures are strange.
They happen because the model has not been given an operating frame.
A normal prompt often carries only the immediate request:
Fix this.
Build this.
Review this.
Write this.
What do you think?
But serious work requires background rules:
- What counts as truth?
- What should not be touched?
- What is the current phase?
- What risks matter most?
- What style of communication helps the operator?
- Should the AI move fast or slow?
- Should it propose options or give one next step?
- Should it challenge the idea or execute it?
- What should happen when uncertainty appears?
If those rules are absent, the model fills the gaps with averages.
And averages are dangerous.
Average advice sounds reasonable. Average structure looks polished. Average code might run. But a project does not need average behavior. It needs behavior aligned to the actual work.
3. The agreement layer
The agreement layer is a reusable instruction layer that sits between the user and the task.
It is not a prompt trick. It is not a personality setting. It is not roleplay.
It is a compact operating constitution for how the AI should work with the user across projects.
A useful agreement layer defines:
- communication style
- pacing
- planning expectations
- source-of-truth rules
- scope guardrails
- code change discipline
- testing expectations
- documentation standards
- handoff rules
- research standards
- UI/UX preferences
- uncertainty behavior
- what the AI must not do
The point is not to make the AI obedient in a shallow sense.
The point is to make the AI predictable, inspectable, and useful inside the user’s actual operating environment.
A good agreement layer turns the AI from a clever responder into a disciplined collaborator.
4. Context is not decoration
Many users treat context as extra.
They give the model the minimum and expect maximum usefulness. This is backwards.
In AI-assisted project work, context is not decoration. Context is the work surface.
If the AI does not know the project charter, it cannot protect the project from drift. If it does not know the source of truth, it cannot protect data integrity. If it does not know what has already been tried, it will repeat dead ends. If it does not know how the user prefers to troubleshoot, it will overwhelm or under-explain.
The result is not simply a worse answer.
It is a different relationship.
A context-free AI behaves like a stranger giving advice from across the room.
A context-aware AI behaves more like a project partner who remembers the shape of the work.
The model may be the same.
The usefulness is not.
5. Source of truth is the first serious rule
The most important practical rule in AI-assisted project work is simple:
Never let convenience override truth.
Every real project has a source of truth. Sometimes it is a database. Sometimes it is a file. Sometimes it is a user workflow. Sometimes it is a production system. Sometimes it is a project charter.
The AI must know what is authoritative and what is only a view, cache, import, projection, or assumption.
Without this, AI creates dangerous shortcuts.
It treats partial data as complete. It treats UI labels as internal truth. It treats a screenshot as the system. It treats old documentation as live behavior. It overwrites durable structure with temporary convenience.
This is how projects get messy.
A working agreement should force the AI to ask:
- What owns the truth?
- What is downstream?
- What must never be overwritten?
- What needs auditability?
- What happens when two sources disagree?
This single habit changes the quality of AI work dramatically.
It makes the AI slower in the right places.
6. Pacing is a safety system
A common AI failure is not that it gives too little help.
It gives too much at once.
It provides five branches, three failure paths, twelve commands, and a future migration plan before the user has confirmed the first fact.
This feels helpful.
It is often not.
For troubleshooting, infrastructure, code changes, and operational work, pacing is a safety system. The AI should move in small verified steps:
- Explain the immediate goal.
- Give the smallest useful next action.
- Wait for the result.
- Interpret the result.
- Then choose the next action.
This is not bureaucracy.
It is how you prevent compounding assumptions.
When the AI gives a giant tree of commands, it transfers too much risk to the user. It asks the user to execute a plan whose branches may not apply.
A disciplined AI should prefer truth-revealing steps before modifying steps.
Look first. Touch second.
7. The AI should challenge drift
Good AI collaboration is not just execution.
The AI should protect the project from drift.
Drift happens when the work slowly moves away from the original problem. A small UI cleanup becomes a backend refactor. A troubleshooting session becomes a redesign. A useful feature becomes a platform. A project with one source of truth grows three parallel flows because each seemed convenient at the time.
Humans do this too.
AI accelerates it.
A working agreement should give the AI permission to say:
- This is becoming too broad.
- This is not the current phase.
- This adds maintenance risk.
- This creates a duplicate flow.
- This should be a future version, not v1.
- This needs a source-of-truth decision before code changes.
- This is not worth doing yet.
That kind of pushback is not resistance.
It is partnership.
An AI that only says yes is not a project partner.
It is a drift amplifier.
8. The difference between helper and reviewer
AI can play many roles, but those roles should not be blended casually.
Sometimes the AI should brainstorm. Sometimes it should architect. Sometimes it should review. Sometimes it should implement. Sometimes it should document. Sometimes it should slow the user down.
Each role has different rules.
A brainstorming AI should expand possibilities.
A reviewer should narrow them.
An implementation agent should stay inside scope.
A troubleshooting partner should verify before acting.
A documentation partner should preserve decisions clearly.
When these roles blur, the work suffers. The AI proposes creative additions during a surgical bug fix. It rewrites architecture when asked to polish copy. It changes behavior during a UI-only pass. It gives generic strategy when the user needed one command.
A good working agreement makes roles explicit.
It tells the AI what mode it is in.
9. AI without agreement becomes performative
One of the strangest things about AI output is that it can look useful before it is useful.
It can produce polished text, clean headings, confident explanations, and plausible plans. This creates a trap. The output feels professional, but it may not be grounded.
The agreement layer exists partly to fight performative usefulness.
It forces the AI to show its relationship to the actual work:
- What did it inspect?
- What changed?
- What was not changed?
- What tests were run?
- What remains uncertain?
- What is the smallest next step?
- What assumption needs verification?
This matters because AI can create the appearance of progress faster than most systems can create real progress.
A serious AI workflow must prefer durable progress over impressive output.
10. The working agreement as a memory substitute
A full personal AI memory system would know the user’s style, projects, prior decisions, risk tolerance, and operating preferences.
Most people do not have that system yet.
A working agreement is a practical substitute.
It compresses the user’s operating style into a reusable document. It can be attached to a project, pasted into a new AI session, given to a coding agent, or used as a review standard.
It does not solve memory completely. But it reduces the cost of reintroducing yourself to the AI every time.
It says:
This is how I work.
This is what I value.
This is where AI tends to go wrong with me.
This is how to be useful.
That alone can change the outcome.
11. Why this surprised me
I did not originally think of this as a paper.
I wrote these rules because I needed AI to stop drifting.
I needed it to slow down when the work was risky, move faster when the scope was clear, avoid vague confidence, respect source-of-truth boundaries, and create handoff notes another AI could actually use.
Then I showed friends how I work with AI.
The surprising part was not that they liked the document. The surprising part was that many of them had never thought to define the relationship this explicitly.
They were using powerful models with almost no operating frame.
That is like hiring a smart contractor, handing them a key, and saying, “Improve the house,” without telling them which walls are load-bearing.
The result might be impressive.
It might also be expensive, confusing, and hard to undo.
12. A public signal
After I had already been working this way, a friend sent me Marc Andreessen’s public X post about his current AI custom prompt.
I am not citing it as an authority that settles the question. I am citing it as a signal.
Andreessen is a useful public reference point because he is not a casual observer of software history. His official a16z biography describes him as a cofounder and general partner at Andreessen Horowitz, and notes that he co-created Mosaic and co-founded Netscape.
But his status is not the main point.
The interesting point is convergence.
People who use AI seriously are discovering the same thing from different directions: the chat box is not enough. The model needs an operating frame. The user must define expectations around precision, uncertainty, verification, reasoning style, and collaboration norms.
I am not reproducing his prompt here, and I do not think the right lesson is that everyone should copy any one person’s prompt.
The better lesson is this:
Serious AI users are moving from prompts toward agreements.
A prompt asks for an answer.
An agreement defines the working relationship that makes the answer trustworthy.
13. What a good AI working agreement should contain
A useful working agreement does not need to be long, but it should cover the real failure modes.
At minimum, it should define the following.
13.1 Communication
How direct should the AI be? Should it challenge weak ideas? Should it avoid cheerleading? Should it give short answers unless asked for depth?
13.2 Pace
Should it give one step at a time? Should it avoid giant command trees? Should it wait for verification before branching?
13.3 Planning
Should it define the problem, goals, non-goals, risks, source of truth, and success criteria before implementation?
13.4 Source of truth
What data is authoritative? What is cache? What is a view? What must never be overwritten by partial information?
13.5 Scope
What should the AI avoid touching? What belongs in v1? What is explicitly out of scope?
13.6 Code discipline
Should it inspect first? Explain root cause? Propose minimal fixes? Avoid broad refactors? Report changed files and tests?
13.7 Documentation
Should it maintain handoff prompts, decision logs, setup notes, and project charters?
13.8 Research
Should it verify current facts, cite sources, and separate assumptions from confirmed information?
13.9 UI and UX
Should it prioritize operator clarity, empty states, consistent terminology, and visual trust over cleverness?
13.10 Uncertainty
What should it do when it does not know? Guess? Ask? Search? Inspect? State uncertainty?
These rules are not theoretical.
They prevent real mistakes.
14. The agreement should be reusable but not rigid
A working agreement should travel across projects, but it should not replace project-specific instructions.
There are two layers:
- The universal working agreement
- The project charter
The working agreement defines how the AI collaborates.
The project charter defines what this specific project is.
Confusing the two creates problems. If the universal agreement tries to contain every project detail, it becomes bloated. If the project charter has no working rules, the AI may understand the product but still behave badly while helping.
The best pattern is layered:
- universal working agreement
- project-specific charter
- task-specific prompt
- final acceptance criteria
This makes the AI easier to steer and easier to review.
15. This is not prompt engineering as usually described
The term “prompt engineering” often makes this sound smaller than it is.
This is not about finding magic wording to trick the model into a better answer.
It is about designing the human-AI work relationship.
A prompt asks for an output.
A working agreement defines a collaboration.
That distinction matters.
If AI becomes a serious part of how people build software, run businesses, write papers, manage operations, learn, research, and make decisions, then the agreement layer becomes part of the work system.
Not a hack.
A system component.
16. Objections
16.1 “This is too formal.”
For casual use, yes.
For serious work, no.
The level of structure should match the cost of being wrong. A birthday message does not need a source-of-truth map. A production system does.
16.2 “A good model should infer this.”
Some preferences can be inferred. Many cannot.
A model cannot safely infer what data is authoritative, what should not be touched, what level of risk is acceptable, or what kind of pacing helps a specific user.
Inference is not a substitute for agreement.
16.3 “This slows things down.”
It slows down the beginning.
It speeds up the work.
Without an agreement, the user pays correction costs later: re-explaining, undoing, redirecting, clarifying, recovering from drift, and cleaning up confident mistakes.
The agreement moves that cost forward and makes it explicit.
16.4 “This only matters for technical projects.”
No.
It matters anywhere the work has context, constraints, and consequences: medical questions, business planning, legal prep, writing, research, operations, finance, customer communication, personal knowledge systems, and long-term projects.
The shape changes.
The need remains.
16.5 “This is just better prompting.”
No.
Better prompting improves the immediate answer.
The agreement layer improves the working relationship.
That difference becomes more important as the work becomes longer, riskier, and more dependent on memory, constraints, and judgment.
17. The practical conclusion
If AI is only used for small isolated tasks, casual prompting is enough.
If AI is used as a serious project partner, casual prompting is not enough.
The user needs an agreement layer.
The AI needs to know how to work, not just what to produce.
The working agreement does not make the model intelligent. The model already has intelligence. The agreement makes the intelligence usable inside a real workflow.
It turns raw capability into disciplined collaboration.
That is the difference between a model that answers and a system that helps.
18. References
- Marc Andreessen, “Current AI custom prompt,” X, https://x.com/pmarca/status/2051374498994364529
- Marc Andreessen biography, Andreessen Horowitz, https://a16z.com/author/marc-andreessen/
Draft note
This paper grew out of an actual working document I use across AI-assisted projects. The original document is more operational and direct. This version abstracts the reasoning behind it.
It is a draft. It should be argued with, tested, and revised by people using AI for real work.
← Back to Papers