Chapter 7: Configuration Is Self-Knowledge
The first article I wrote with a model was competent, correct, and utterly hollow.
It was about a product strategy concept I had wrestled with for years and taught to dozens of product managers. I cared about it. I sat with the finished draft open and could not find myself in a single line of it. It read like every other AI-assisted piece on the internet: fluent, accurate, and indistinguishable from the output of someone who had never made the decisions it described. My first instinct was that the model had failed me. The model had not failed me. I had failed the model, and the gap between those two diagnoses is the whole subject of this chapter.
I had assumed that if I handed it a detailed brief, context, key points, some phrasing I liked, it would reverse-engineer who I was from the scattered pieces. It understood the ideas; surely it could match the voice. It could not, because that is not how these systems work. They do not assemble an architecture from fragments and hope. They work when you externalize the architecture and hand it over. I was asking the model to infer my reasoning from a few examples and a general direction, and what came back was the predictable result: a polished version of the average of everything, with the part that was supposed to be me sanded off.
This chapter is about the document that fixes that, and about the discovery, which surprised me more than it should have, that the document is not really for the model. It is for you. Writing it is where the self-knowledge happens, and the self-knowledge is the point. The configuration file, the voice profile, the CLAUDE.md, the team conventions doc, is the externalization of your own standards, and most product managers have never once written theirs down.
Configuration is onboarding
Start with the reframe, because the entire chapter rests on it and it is usually mis-seen as a prompt-engineering detail.
Every well-run team already has a version of the configuration file. The list of conventions, the style guide, the architectural decisions written as here is how we do it on this team, the explicit rules about what good looks like. On an engineering team these lived in a page new hires read in their first week, and then in the code-review feedback they got for their first three months, and gradually the new hire absorbed them and started producing work that looked like the team’s work. The document was never the whole onboarding. The gradual absorption was.
For the agent, none of the gradual absorption happens. There is no first three months. The agent reads the rules each session, follows them within the limits of its context, and starts again the next time, with no organic learning, no accumulation, no quiet drift toward your house style. So the onboarding has to be explicit, written down, and continuously present, because the part that used to happen by osmosis now happens only if you wrote it or does not happen at all. The configuration file is not a settings panel. It is the new-hire packet, and it is the entire onboarding, and the agent re-reads it every session because it never remembers the last one.
Which is why the line that should make you slightly uncomfortable is this: if you have not written it, your work is being produced by an employee you did not onboard. The codebase that quietly shifts toward the agent’s defaults over six months, the prose that comes back in the flat house style, the analysis that reaches the model’s conclusions instead of yours, none of that is the agent failing. It is the agent doing exactly what an un-onboarded hire does, which is fall back on the defaults it brought from the last chapter, the ones set by a company you do not work at. The drift you start to notice is not the agent getting worse. It is your standards never having been stated, so the agent supplied its own.
The profile is for you, not the model
Here is the part that changes what this exercise is.
When I finally built my voice profile, I did not write a style guide. I built what I came to call a knowledge graph of me, an explicit map of how I actually think, the connections that usually stay locked in my head. And the way I built it was not by writing down what I already knew about myself. It was by letting the model interview me, with questions structured to force specificity, and discovering that I did not know the answers until I was made to say them.
The questions were not about my background or credentials. They were about how I work, and they were deliberately uncomfortable. Not what is your writing style but if you found a sentence with Additionally or Furthermore in it, what would you do? The answer, which I had never articulated, is: delete it, because there is no thought that needs an Additionally, there is just the next thought. Not what is important to you but what would make you stop trusting someone who is supposed to know healthcare? The answer is specificity and citation and awareness of nuance, because anyone who says AI will solve healthcare has never sat with patients, and someone who knows healthcare says AI solves this specific problem in this specific context and can name the context. Not what is your style but, when you are editing your own work, what are you looking for, and what makes you close an article and stop reading?
These were not rules I knew I was following. They were visible only when something stopped to ask. I also had the model analyze my published work, not for what it said but for how it was built, and it extracted patterns I had been using for years without naming: short declarative contrast when I want to disrupt an assumption, scene before argument when I am asking someone to question something comfortable, a closing that does not summarize but implies what comes next. I learned things about my own thinking by reading them back off my own work.
This is why the deliverable is misnamed when you call it a profile for the AI. The hard part, the part that took me ten to fifteen hours, was not formatting anything for a model. It was answering questions about what I actually believe and how I actually reason, and most people never do that work, because the internet rewards speed and speed does not require knowing why you think what you think. The knowledge graph is not for the model. It is for you. The model is merely the first reader strict enough to expose the places where you had a preference but not a reason.
For a PM the questions are different but the move is identical. What trade-offs actually matter to you, and which ones do you pretend to weigh but always resolve the same way? What is your appetite for which specific kinds of failure, the ones you will tolerate to move fast and the ones you will stop a launch over? What is the question you always ask about user behavior that your peers do not? Where do you demand certainty and where do you accept a calculated guess? You cannot configure an agent to reason like you until you have made those answers explicit, and the discovery, every time, is that you were carrying preferences you had never once examined. The configuration is the audit.
What to encode, and what not to
Not everything that improves the output belongs in the file, and confusing the two is how a configuration rots.
Encode the standards. The rules that carry hard-won lessons, the trade-offs you have learned to weigh a particular way, the constraints that exist because something went wrong once and you decided never again. Encode what good looks like, in terms specific enough to act on, because a standard stated as an adjective is not a standard. Make it good is not a configuration. The retention number always gets checked against the dashboard, never against the model’s memory, is a configuration, because it encodes a judgment, and the judgment is yours, and it will still be your judgment a year from now.
Do not encode the perishable phrasing tricks. There is a real temptation, once you start tuning, to fill the file with the specific incantations that happen to produce good output from the specific model you are using this month: the magic preamble, the exact wording that gets this version to stop hedging, the prompt-shaped lever that works on this actor. Those are not standards. They are abstraction-layer artifacts, tuned to a model that will be replaced, and they obsolesce on the upgrade schedule of the underlying system, which is to say constantly. I have watched the model wars long enough to know what is durable and what is a lead time that erodes. The router I run treats the underlying model as interchangeable infrastructure precisely because the model is the transient layer. Your configuration should be written at the layer that does not move. A standard is geology. A phrasing trick is weather. If a sentence in your file would be wrong the moment you switched models, it was never a standard; it was a workaround wearing a standard’s clothes, and it will quietly invalidate itself and take your trust in the whole file with it.
The test is simple. For every line in the configuration, ask whether it encodes something true about your work or something true about this model’s current quirks. The first kind is the onboarding packet. The second kind is a sticky note on a machine you are about to replace.
Configuration drift
Which brings us to the failure mode the last chapter set up and this one inherits.
A configuration is tuned, whether you mean it to be or not, to the actor you wrote it against, and Chapter 6 told you what happens next: the upgrade swaps the actor. The file that used to produce work in your house style starts producing something subtly off, and the onboarding and the personnel change compound in your work before anyone realizes the house style has been quietly handed over. The validator atrophy from Chapter 5 makes it worse, because you are losing the skill to notice the drift at the same time the thing you are supposed to notice it against is itself drifting. Both reference points erode at once.
If the perishable tricks are in the file, the upgrade breaks them silently and you inherit broken output you did not author. If only durable standards are in the file, the upgrade still requires re-coaching, because the new actor expresses your standards through different defaults, but you have something stable to re-coach against, which is the difference between adjusting and starting over.
The insurance I found for this is cross-model coaching, and it is worth naming because it is the practical move. When I switched models and lost my voice, the fix was not to rewrite the profile from scratch. It was to hand the new model’s drafts back to the older instance that carried months of accumulated context on how I write, and let it name the tells. The new actor consistently opened with a setup sentence that explained what it was about to say and then said it; I do not, so cut the first sentence. The new actor closed paragraphs with fully formed complex sentences; I close with something blunt. Five concrete corrections came back from one pass, I gave them to the new model, and the next draft was materially closer to mine. One model coached the other on which costume to wear, and the coaching worked only because the standard underneath, the knowledge graph, was stable enough to coach toward. The configuration was the fixed point. The cross-model coaching was how I re-fitted a new actor to it without rebuilding it. That is what a durable configuration buys you on upgrade day: a thing to coach back to, instead of a hollow draft and no idea why.
One rule, with the lesson inside it
The configuration earns its weight one rule at a time, and the rules that matter most are the ones with a story underneath them.
There is a category of rule that is not a preference and not a phrasing trick. It is a scar. Some line in your file exists because a specific thing went wrong once and the rule is the lesson, compressed, so the agent never walks you back into it. The pricing structure always gets flagged when it looks like one I have seen kill a partnership before. The handoff sequence always gets checked for which region the data routes through, because routing it wrong once is the kind of mistake you encode forever. These rules look arbitrary to anyone reading the file cold, and they are the most valuable lines in it, because each one is an apprenticeship failure, the kind Chapter 3 said you no longer get to have organically, deliberately preserved so it keeps teaching after the original sting has faded.
One of mine looks trivial until you know what it is doing. The rule reads: any sentence that opens with “Additionally” or “Furthermore” gets deleted, and the thought it was carrying gets rewritten as the next thought, not an appended one. That is not a style preference. It is a standard I could not articulate for years and only found when a model interviewed me about my own writing and asked what I would do with such a sentence. The answer, once I was forced to say it, was that there is no thought that needs an “Additionally”; the word is a seam showing where the writer stacked two ideas instead of connecting them, and the moment I see it I know the underlying thinking has not been finished. The rule encodes a lesson about my own reasoning, not about prose, and writing it down is what made it explicit enough to enforce.
The PM version of the same category has more at stake and reads more arbitrarily. Consider a PM who works in a regulated, multi-region product and adds a rule to their configuration that flags any handoff design where data crosses a regional boundary without an explicit routing decision named in the spec, forcing the question before the design goes further. To anyone reading the file cold it looks like compliance boilerplate. It earns its place because routing data to the wrong region once is the kind of mistake that does not stay a technical footnote; it becomes a contract problem, a trust problem, and a very long week, and the rule exists so the agent surfaces the decision while it is still cheap to make rather than after it has been made silently and wrong. The pattern is general even when the specific rule is not yours: somewhere in your own work is a mistake you would encode exactly this way, so the agent can never walk you back into it.
Writing these down does something beyond instructing the agent. It forces you to articulate lessons you had absorbed but never stated, and an absorbed lesson is fragile in exactly the way Chapter 1 warned, because it lives only in a judgment that is itself perishable. A stated lesson, written into a configuration you re-use, survives the erosion of the judgment that produced it. This is the quiet thing the configuration does that nothing else in Part II does: it externalizes the part of your judgment that would otherwise decay silently, and it makes it portable. The standards you can write down are the one part of your judgment that survives you switching tools, because the model is the transient layer and the configuration is written at the layer that does not move.
The test of a good configuration
So how do you know the file is any good? Not by how the output reads to you, because you are too close, and not by whether it pleases the current model, because the current model is temporary.
The test is whether a stranger produces work you would sign. Hand the configuration to a model you have never tuned, or to a colleague who does not know your work, and see whether what comes back is something you would put your name on without rewriting it. If it is, the file is carrying your standards rather than your current model’s habits, and it will survive the next upgrade and the next tool. If it is not, the gap tells you exactly what you were relying on the model to supply by default, which is to say the part of your standards you never made explicit and have been quietly outsourcing. The test does not just grade the file. It surfaces the next thing you have to learn about your own judgment, which is the same thing the whole exercise has been doing from the first interview question. A good configuration is never finished, for the same reason self-knowledge is never finished.
Write yours. Start with the structured self-interview, sit with your best work and read it for how it was built rather than what it said, and turn what you find into an explicit document you hand to the model and re-use. It will take real hours and it will be uncomfortable in the specific way that examining your own reasoning is always uncomfortable, and it is another keeper of this part of the book, the one that holds the standards the others run against. Keep it. The book is building toward a moment when these kept things are revealed to be the same thing.
You now have the practice. Reps that built the intuition, the loop that structures them, the read on every actor you cast, and the configuration that encodes what good looks like in your own hand. The standards are written down and the practices are running. There is one thing left, and it is the least comfortable of all, because it does not ask you to build anything new. It asks you to prove that the operator running all of this still works, on a schedule, with a record, against the one piece of evidence that means nothing: your own confidence that it does.