Agents build the screens. Models write the sentences. This is an article about the one governed system that keeps a product recognizably, accountably itself while both of them work.
A brand used to be enforced by the people who produced its surfaces. Every screen passed through a designer, every sentence through a writer, every release through a review, and coherence arrived as a side effect of the bottleneck. The work was slow, and the slowness was doing a job nobody had named: it guaranteed that everything a customer saw had been touched by someone who knew what the product stood for.
The bottleneck is gone. Two different machines now generate a product's surfaces. At design time, an agent in a terminal writes the screens: it scaffolds the flow, styles the components, drafts the copy, and opens the pull request. At runtime, a model inside the product writes the sentences: it explains a fee, composes a reply, and increasingly draws the interface itself, differently for each person and each channel. Both machines are fluent. Neither one knows what the product must never say.
This article is about the layer that knows. It argues that coherence, the quality of being recognizably one product across every screen, sentence, channel, and language, stopped being a matter of discipline and became a matter of architecture. The style guide that lived in a designer's head, or in a PDF nobody opened, has to move into a form that generators can read and validators can enforce: tokens, behavior definitions, contracts, profiles, and evaluations, all living in one governed place that feeds the agent that builds the product and the model that runs inside it.
One product threads through the whole argument. Corredor is a composite: a WhatsApp-native remittance product serving Latin American corridors, assembled from patterns observed across real products so the examples can be concrete without pointing at anyone. Corredor appears twice in every chapter that needs it, once as a product running in front of a customer, and once as a codebase in front of the four-person team that builds it. That doubling is the point. The same system has to govern both.
Each chapter closes with a law: a one-sentence constraint that can travel into a design review without the chapter attached. Long arguments rarely survive contact with a roadmap meeting. Short ones sometimes do.
01
PART I
The Argument
Why coherence became an architectural problem.
CHAPTER 1 · Part I
The Bottleneck Was the Brand
Coherence was never designed. For most of the history of software it was enforced, and the enforcement mechanism was scarcity. Screens were expensive to produce, so few people produced them, and those few people carried the brand around in their heads. A style guide existed, but it worked the way etiquette works: as a written reminder of judgments that were really transmitted person to person. When a company wanted more coherence, it hired more reviewers and slowed down. The brand was the bottleneck, and the bottleneck was the brand.
AI removed the bottleneck twice in quick succession. The first removal happened at design time. An agent working in a repository can produce a competent screen in minutes, which means screens are no longer scarce, which means the review capacity that used to touch every surface now touches a fraction of them. The second removal happened at runtime. A model embedded in the product composes sentences, and soon interfaces, on demand, per person, per moment. No reviewer will ever see most of what a generative product shows its customers, because most of it did not exist until the moment it was shown.
What grows in the absence of the bottleneck is not chaos exactly. It is sprawl. AI features tend to grow the way weeds do: a team adds one, and someone writes a prompt. The prompt works, so it is copied into the next feature and edited a little. Six months later the product speaks with eleven slightly different personalities, none of them chosen. The design-time version of the same weed is the almost-component: every generated screen slightly different from its siblings, each difference individually defensible, the sum unmistakably incoherent.
The costs are not hypothetical. In February 2024 a Canadian tribunal ordered Air Canada to honor a bereavement discount its support chatbot had invented. The airline argued, remarkably, that the chatbot was a separate legal entity responsible for its own statements. The tribunal disagreed: the product spoke, so the company promised. Every generated sentence is a commitment made on the company's behalf, and every generated screen is a brand decision published without review.
The missing abstraction is a governed layer above both generators: a single place where the product's identity lives in machine-readable form, compiled into context before anything is generated and checked against contracts after. The rest of this article is an account of that layer, what goes in it, and what it costs. What the bottleneck used to enforce by accident, the system now has to guarantee on purpose.
CHAPTER 2 · Part I
From Screens to Behaviors
When production becomes cheap, the unit of design moves. It has happened before. Print designers once specified pages; web designers learned to specify templates, because the page count had become unbounded. The same promotion is happening again, and it is larger. When an agent can produce any screen on request and a model can rephrase any sentence per reader, the screen and the sentence stop being designable objects. They are outputs. What remains designable is the behavior underneath: what the product is trying to accomplish in this moment, what it must include, what it must never claim, and what a good outcome looks like.
Old unit
New unit
Why it matters
Screen
Behavior
The surface is generated per person and per channel; only the behavior is stable enough to design.
Style guide
Governed context
Taste the generator reads before producing beats taste a reviewer applies after.
Handoff
Pull request
The design and its specification become the same artifact, one merge from shipping.
Brand review
Contracts and evals
Coherence gets checked by the system on every generation, not remembered by the team on some.
The unit of design, before and after
The designer's job moves with the unit. Producing five plausible directions for a screen now costs minutes. Knowing which one is right, and why, is the craft that remains, and it is the scarce input the whole system is organized around. The division of labor is clean: the machine handles divergence, generating options faster than any team could, and the human owns convergence, the selection and the reasons for it. A team that lets the machine converge, accepting the first plausible output, has not automated design. It has abandoned it.
It is tempting to treat this as a story about chat, since chat is where most teams first met a generative surface. Chat forced the issue, but conversation is just one renderer. The same behavior, explaining a delayed transfer, can render as a chat reply, a status banner, an email, or thirty seconds of a voice call. A product that designs the reply has solved one surface. A product that designs the behavior has solved all of them, including the surfaces it has not shipped yet.
CHAPTER 3 · Part I
The Adoption Threshold
Every serious proposal needs a chapter that argues against itself, and this is that chapter. For many products, at many stages, building the full system in this article is a mistake, and not because the ideas are wrong. A three-screen prototype does not need behavior contracts. A product whose AI writes nothing more consequential than a caption does not need an authority model. A team of one with good taste and a small surface area can hold coherence in their head, which is where it has always lived most cheaply. A product that does not have a coherence problem yet is buying insurance against a fire that is not burning.
The threshold is not company size. It is exposure, and it scales with two multiplied quantities: the cost of a wrong sentence, and the number of surfaces that can produce one. A solo designer shipping a marketing site sits near zero on both axes; a written brand file and a weekly critique are the whole system that situation deserves. A four-person team whose product moves money through a chat thread sits high on both, whatever its headcount, because a generative surface in a regulated category manufactures commitments at conversational speed.
Adoption is therefore a ladder, not a leap. The first rung is a brand file the agent reads before generating anything, which costs an afternoon. The next is tokens as the single source of visual truth, then extracted components with names, then contracts on the behaviors that can do harm, then evaluations, then traces. Each rung is useful without the ones above it, and each is justified by a coherence failure the team has actually had, not one it can imagine having. The same logic governs headcount. A team that feels the pull to hire a second designer usually wants the system, not the person: written taste, enforced tokens, a decision log. If none of that exists, the hire will not fix it. Do not hire; build.
There are also exit conditions, and naming them early is part of the honesty. If the models become reliable enough that a plain instruction holds across a million generations, some of this scaffolding should be dismantled, and Chapter 13 describes how to tell. A system that cannot say what would make it unnecessary is a belief, not an architecture.
02
PART II
The System
The artifacts a brand needs when models write its sentences and agents build its screens.
CHAPTER 4 · Part II
One Source of Truth
Systems drift when their truth is stored twice. The traditional design stack stored it at least twice by construction: once in the design tool, once in the code, with a human translation step between them, and the two copies disagreed within a sprint of any release. The first structural decision of an adaptive brand is to collapse the copies. Tokens, components, screens, copy, and decisions live in one repository, and everything else, the style guide site, the exported specifications, the agent's instructions, is generated from it. When the repository changes, the derivatives change. Nothing is maintained by remembering to maintain it.
Tokens carry the visual half of the truth, and their structure matters more than their format. Three layers, each answering a different question. Primitives name what exists: the palette, the scale, the family. Semantic tokens name what things mean: surface, accent, warning, the vocabulary a screen is actually built from. Component tokens name exceptions, and their scarcity is a health metric. A generator styling a screen touches only the semantic layer, which is how a rebrand becomes an afternoon and how a thousand generated screens stay siblings.
The semantic layer is the only one a generator may touch.
The less obvious half of the decision is who the design system is for. It used to be documentation for people. It is now, first, context for machines: the agent scaffolding tomorrow's screen and the model rendering tonight's answer both consume it, and its quality is measured by what they do with it. A style guide site still matters, but as a projection for humans of a system whose native form is machine-readable. The two audiences read different surfaces of the same truth, which is the only arrangement under which they cannot diverge.
CHAPTER 5 · Part II
Semantic Components
Component libraries standardized the nouns of interface: Button, Card, Modal. Adaptive products need a vocabulary one level up, for the verbs. When a model decides how to respond and an agent decides how to compose a screen, the reusable unit is the interaction behavior itself: Explain, Clarify, Confirm, Compare, Recommend, Repair, Warn. Each is a designed object with a definition that does not mention any particular surface. A Confirm names the facts it must present, the explicit consent it must collect, the actions it may offer, and the evaluations that decide whether an instance of it succeeded. How a Confirm looks in a chat thread versus a web form is a rendering question, and rendering comes later.
The vocabulary is discovered, not invented. The reliable moment is the second flow. The first flow establishes candidates; the second reveals which parts recur, because the agent, asked to build it, will reproduce the first flow's patterns almost correctly, and the almost is the signal. At that point the team runs an inconsistency audit, promotes the recurring patterns to named components, and replaces the inline variants with the canonical ones. Names should describe function, never appearance: a TransferSummary survives a redesign, a BlueFeeCard does not.
Once behaviors have names, everything downstream gets simpler. Prompts stop describing what a response should be like and start naming what it is. Evaluations attach to behaviors instead of to prose. And the two generators finally share a vocabulary: the agent composes screens out of the same Confirm the runtime model expresses in a chat thread, which is the first concrete payoff of governing one system rather than two.
CHAPTER 6 · Part II
Brand as Governed Context
Ask a team what their brand voice is and someone will say warm but professional, and everyone will nod, and no two of them will mean the same thing. That ambiguity was survivable when every sentence passed through a writer. It is fatal when sentences are generated, because a model given warm but professional will decide for itself what warmth means at three in the morning to a customer whose transfer is stuck. The brand has to move from adjectives to constraints: written down, versioned, and compiled into the context of every generator before it produces a word.
The written form has two halves. The first is the brand file: identity, voice, tone shifted by context, terminology, and the never-say list, which does more work than everything above it. Its entries are not stylistic preferences. Each is a commitment: a sentence shape the product will not produce, in any language, on any surface, no matter how fluent it would sound. The second half is the contract, the enforcement mechanism the brand file compiles into. A conversation contract bounds a behavior's speech: allowed facts, required disclosures, forbidden claims, output shape. The brand file teaches the generator. The contract checks its work.
Skillskills/brand.md
## Voice
Plain, warm, direct. Money talk is calm talk.
Short sentences around numbers. No exclamation
points within two sentences of an amount.
## Tone by context
- Delay or hold: lead with what is true now,
then the next step. Never open with an apology.
- Success: quiet confidence. One sentence.
## Never say
- "Oops" or "Uh oh" anywhere in a payment flow
- Any arrival promise not present in the
rate object ("guaranteed", "instantly")
- "Trust us"
What makes this bearable to maintain is that the same files serve both machines. The agent reads the brand file before drafting interface copy at design time. The context compiler loads it, with the contract, before the runtime model explains a delay. One edit to the never-say list propagates to every future screen and every future sentence, which is what it means for a brand to be on by construction rather than by review.
CHAPTER 7 · Part II
Every Surface, One Promise
Cross-platform used to mean responsive: the same layout, gracefully squeezed. An adaptive product faces a harder version, because its surfaces do not share a layout to squeeze. A behavior renders as a chat message, a form, an email, a voice turn, or an interface the model composes on the spot. What holds these together cannot be visual sameness. It is the promise underneath: the same facts, the same disclosures, the same available actions, wearing whatever clothes the channel requires.
The instrument for this is the renderer contract, and the useful analogy is accessibility testing. Nobody tests a screen by asking whether the disclosure exists somewhere in the markup; they test whether a person using a screen reader actually encounters it. Renderer contracts make the same demand of every surface: the fee is stated before the confirm control is reachable, the warning has salience appropriate to its severity, the cancel action is never more than one step away. Placement and reachability, not mere presence. A rendering that cannot satisfy the contract on some channel does not ship on that channel, and every behavior carries a deterministic fallback layout for the day the generative path fails. The fallback will be plain. It will also be correct, and correct-but-plain is the right floor for a product that moves money.
Language is the other axis, and it is behavioral before it is lexical. Translating strings is the last step of localization, not the substance of it. A conversation profile localizes behavior: pacing, directness, formality, which examples land, how consent is asked for. The words change with the locale file; the disclosure changes with nothing. Copy itself is tokenized like color, stored as semantic keys with per-locale values, so the agent generating a screen and the model generating a sentence draw from the same vocabulary in every market.
CHAPTER 8 · Part II
The Control Plane, Twice
A fair question is where all of these artifacts meet. The answer is a control plane: the governed layer that, for each piece of work, decides what context is admitted, which capabilities are available, which policies apply, and what evidence is kept. The striking thing is that a well-run adaptive product ends up building it twice, in the same shape, at two different moments. The versions differ in stakes and in dress, but every component in one has a counterpart in the other, because both exist to solve the same problem: a fluent generator that must be briefed before it works and bound while it works.
Function
Design time (the repo)
Runtime (the product)
Brief the generator
Agent instructions and skill files, compiled per task
Context compiler admitting facts with provenance
Bound the actions
Review gates, branch rules, protected paths
Action contracts and the authority graph
Check the output
Hooks, audits, and evals on the diff
Validators on the rendered turn
Keep the evidence
Decision log, changelog, git history
Replayable traces of every governed turn
One shape, two moments
The design-time plane is humbler and worth describing plainly, because it is where most teams start. It is the repository itself, made legible: an instruction file stating what the project is and what may never happen, skill files carrying the brand and the patterns, and hooks that check the invariants on every change. The division between instructions and hooks is the important one. An instruction can be forgotten; a hook fires every time. Preferences belong in the instructions. Invariants belong in the machinery.
The runtime plane is the same idea with higher stakes: before a model speaks, the compiler assembles what it may know, the authority graph limits what it may do, contracts bound what it may say, and a trace records what happened, so that any turn can be replayed when someone asks why. Neither plane is the agent, and neither is the model. The generators are tenants. The plane is the building, and the deepest economy of the whole approach is that the two buildings share their load-bearing walls: the same tokens, the same brand file, the same behavior vocabulary, the same evaluations. A team that maintains them as one system pays for coherence once and collects it at both moments.
03
PART III
The Practice
Operating the system, week over week, without losing it.
CHAPTER 9 · Part III
A Flow, End to End
Before the practice comes apart into disciplines, it is worth watching one week of it run. The Corredor team is adding scheduled transfers: a sender sets up a recurring payment to arrive before her mother's rent is due. One designer owns the flow. The system owns the coherence.
One flow, from brief to governed behavior, as the system sees it.
Compile context
The agent loads the instruction file, the brand skill, the token set, the behavior vocabulary, and the decision log before generating anything. The brief is one paragraph; the context is the accumulated system.
Diverge
Five directions for the scheduling screen, generated in minutes, all drawing on semantic tokens and existing behaviors. Divergence is the machine's job, and five is the floor: one option is not a decision, it is an acceptance.
Converge
The designer picks the second direction, folds in the calendar treatment from the fourth, and writes two sentences on why. The sentences land in the decision log. Convergence stays human.
Complete the behavior
Happy path, empty, error, loading, and the 375-pixel screen, before the flow is called done. States skipped at design time become improvisations at runtime, made by whichever generator gets there first.
Bind the contracts
ScheduleTransfer joins the behavior vocabulary: required facts, consent shape, forbidden claims, a repair path, and the deterministic fallback layout for every channel it will render on.
Audit
The accessibility pass runs its two layers, scanners for the mechanical failures and the agent for judgment calls. The fee-before-confirm eval runs against twenty generated variants of the flow. Two fail. The contract is tightened, not the prose.
Open the pull request
The diff is the design, the description is the brief, and the decision log entry is linked. Engineering reviews integration and performance. Nobody translates anything.
Trace
The feature ships behind the runtime plane. Every scheduled-transfer conversation now compiles the same brand file the agent read on Tuesday, checks the same contract, and leaves a replayable trace.
On Friday a customer named Maria schedules rent for her mother in Oaxaca from a WhatsApp thread. The reply she gets is warm, short, states the fee before asking for consent, and promises nothing the rate object does not contain. She never sees the machinery, which is the point.
CHAPTER 10 · Part III
Evaluation-Driven Design
Taste that stays in a designer's head does not scale to generators, because generators cannot read heads. The practice that fixes this is older than it looks: it is the design critique, made continuous and partly mechanical. Every substantial piece of work gets options before commitment, a structured critique against written criteria, and a scheduled re-examination after it ships. What changes is who participates. The agent can run the critique too, against the brand file and the pattern library, and a different model makes a usefully disagreeable second reviewer precisely because it shares none of the first one's habits.
Beneath the critiques sits the harder discipline: writing the taste down as evaluations. An eval is a rubric made executable, attached to a behavior rather than to a prompt. Does the explanation state the fee before the consent control appears? Does the recovery message avoid opening with an apology? Is the warning's salience proportional to the money at risk? Each is checkable across a hundred generated variants, which is the only scale at which checking now matters. Product metrics complete the loop but cannot start it: metrics decide winners, evals decide entrants. A variant that converts beautifully while breaching a disclosure rule is not a winner. It is an incident with good numbers.
Evalskills/evals.md
## ConfirmTransfer / consent-is-explicit
Fail if consent is collected by any control
whose label does not name the action and the
amount ("Confirm $200 to Rosa") .
## Explain / no-blame-opening
Fail if the first sentence attributes the
delay to the customer, in any phrasing.
Design timeRuntimeBehavior-level
The uncomfortable implication is that the rubric is now a first-class design deliverable. A designer who can articulate why a direction is right, in criteria precise enough to run, has externalized the scarcest thing they have. The criteria are the craft. Everything else in the system exists so that the craft, once written, gets applied everywhere.
CHAPTER 11 · Part III
The Memory of the System
Technology scales through abstraction. Teams scale through memory. Every design decision of consequence gets made once, forgotten, and then made again by someone else, slightly differently, and the drift between the two answers is where incoherence enters a growing product. The countermeasure is unglamorous: a decision log, kept in the repository, written at the moment of convergence. What was decided, what was rejected, and why, in two or three sentences. The log is not documentation of the design. It is the design's reasons, which are the part the artifacts cannot carry.
Decisionskills/decisions.md
### 2026-06-19 — Fees shown as totals, not itemized
Chose a single all-in fee line on every summary.
Rejected itemization: it tested as more honest but
read as more expensive, and support tickets rose.
Sign-off: brand + compliance. Revisit if corridors
with tax line-items launch.
Design timeInstitutional memory
The log earns its keep twice. Humans query it when a settled question resurfaces, which happens on roughly a six-month cycle in any team large enough to have turnover. The agent queries it before every generation, which is how a new flow inherits last quarter's reasoning without anyone re-explaining it. In practice the log becomes the onboarding: a new designer who reads the decisions, the brand file, and the behavior vocabulary has absorbed the taste of the team in an afternoon, because for once it is written where the work happens rather than remembered near it.
Governance follows the same principle at team scale. Ownership attaches to artifacts, not to tools: someone owns the tokens, someone owns the behavior vocabulary, someone owns the contracts that carry legal weight, and the review gates encode which changes need whose eyes. The rest stays loose deliberately. Standardize the artifacts, not the tools, and let each designer keep whatever harness makes them fast, since everything of value survives in the files they all share.
CHAPTER 12 · Part III
Breaking It on Purpose
Every example so far resolved cleanly, and that frictionlessness is exactly what a skeptical reader should distrust. So this chapter breaks the system, with a failure assembled entirely from defensible decisions. A designer, moving fast on a Friday, lets the agent converge on a redesigned summary screen without the options pass. The screen is lovely. The agent, drawing on an older pattern, places the all-in fee below the confirm control instead of above it. The fee-before-consent eval would have caught it, but the eval is bound to ConfirmTransfer and the new screen quietly introduced a ConfirmScheduled variant nobody registered. The pull request is small, the reviewer checks performance, and the screen ships. For eleven days, on one surface, in one locale, Corredor collects consent before stating its price.
The interesting part is not the failure. Every system fails, generative ones faster. The interesting part is the shape of the failure, because the architecture spent all of its effort making that shape small and legible. The breach was one behavior variant on one surface, not a personality drift across the product, because everything else was contract-bound. It was found in an audit sweep, not in a courtroom, because the weekly screen-level pass walks surfaces the unit evals cannot see. And the trace answered why in minutes: the variant, the missing registration, the skipped options pass, each visible, each fixable at exactly one point. The postmortem produced a rule, the rule became a hook, and the hook now fails any pull request that adds a behavior without an eval binding. An instruction would have asked the team to remember. The hook removed the option of forgetting.
This is the honest promise of the whole system. Not that generation becomes safe, but that failure becomes local: one contract, one variant, one surface, one fix, instead of a diffuse off-brand-ness nobody can locate. A team that cannot say where a failure would surface does not yet have an architecture. It has confidence.
04
PART IV
The Test
The case against, and what survives it.
CHAPTER 13 · Part IV
The Case Against
The strongest objection deserves its strongest form. Models improve on a cadence measured in months, and much of what this article proposes is compensation for their present weaknesses. Contracts exist because instructions do not reliably hold; evals exist because judgment does not reliably transfer; fallback layouts exist because generation sometimes fails. Each artifact is scaffolding around a limitation, and scaffolding around a shrinking limitation is a depreciating asset. A team that spends this year building the full apparatus may spend next year maintaining machinery the models have made unnecessary, while a rival that waited simply writes better instructions to a better model.
Part of the objection is right, and the response is to plan the retirement rather than deny it. Every layer in the system should carry a sunset condition: the observable fact that would make it removable. When a plain instruction holds across a million generations, retire the contract that duplicates it. When the model's judgment matches the rubric nine hundred ninety-nine times in a thousand, thin the eval to a sample. The discipline is to review the scaffolding on the same cadence the models improve, and to feel no sentimentality when a layer comes down. Architecture must earn its keep annually.
But the objection proves less than it appears to, because it confuses two kinds of artifact. The scaffolding compensates for the generators, and it will depreciate with their weaknesses. The commitments do not compensate for anything. What the product promises, what it must disclose, what it may never claim, whose consent it needs, why the fee is shown as a total: no model improvement makes these decisions for a company, because they are not capability gaps. They are choices. Better models make expressing them cheaper and enforcing them lighter, and leave the deciding exactly where it was. The same logic settles the tooling anxiety. Harnesses, models, and vendors are the fastest-churning layer of the stack, which is precisely why nothing of value should live in them. The test is simple: if the favorite tool disappeared tomorrow, the team should lose a driver, not the brand, the decisions, or the taste. Everything in this article passes that test by construction, because everything in it is a file in the team's own repository.
CHAPTER 14 · Part IV
The Discipline
This article opened with a bottleneck and has spent thirteen chapters replacing it. The design system analogy carried most of the distance, and here is where it ends. Visual design systems asked for consistency: the same button, the same blue, the same spacing, everywhere. An adaptive brand asks for something harder, because its surfaces are not supposed to be the same. They are generated per person, per channel, per moment, in whatever language the customer thinks in. Buttons needed consistency. Generative products need coherence, and coherence is a property of what holds while everything else adapts.
What holds is short enough to list. The commitments, written as contracts. The taste, written as evaluations. The meaning, written as behaviors. The truth, written once, in a repository both generators read. Around that fixed core, everything is allowed to move: the words, the layouts, the pacing, the channel, the model, the harness, even the team. The discipline is refusing to let the two categories blur, because every incoherent product fails the same way, by letting something that should have been governed become something that merely tended to be true.
The next generation of products will not be distinguished by fluency. Everyone's model will be fluent, everyone's screens will be competent, and both will be cheap. Products will be distinguished by whether they can adapt everything and still be recognizably, accountably themselves: one promise, kept on every surface, in every language, by generators that never met the founders. That quality does not emerge from taste applied at review time. It is built, the way this article has described, and it is the discipline the name has been pointing at all along.
05
PART V
Appendices
The laws in one place, and the artifacts worth stealing.
Appendix A
The Laws
Every law from the preceding chapters, regrouped by what it governs. They are meant to travel without the chapters attached.
The argument
Generate every surface. Govern one system.Preface
What the bottleneck enforced, the system must now guarantee.Chapter 1
The screen is an output. The behavior is the design.Chapter 2
Adopt in proportion to the cost of an off-brand sentence and a wrong action.Chapter 3
The system
A design system the generators cannot read is a memo, not a system.Chapter 4
The channel changes the clothes, never the commitments.Chapter 7
The system that briefs the agent must bind the model.Chapter 8
The practice
Write the taste down, then test against it.Chapter 10
A decision that is not logged will be made again, differently.Chapter 11
Make failures small, legible, and repairable.Chapter 12
The test
Every layer is replaceable except the one that carries the promises.Chapter 13
Let AI adapt everything except what you must defend.Chapter 14
Appendix B
The Artifacts
The system is, in the end, a small set of files. These are Corredor's, trimmed to their load-bearing lines. Names and tools will date; the shapes should not.
InstructionsAGENTS.md
# Corredor
WhatsApp-native remittances, four-person team,
design happens in this repo.
## Absolute rules
1. Never hardcode a color or spacing value.
Semantic tokens only.
2. Every behavior ships with all states:
happy, empty, error, loading, 375px.
3. Every new behavior registers an eval
binding before merge.
4. Money copy follows skills/brand.md.
The never-say list is not advisory.
## Read before generating
skills/brand.md · skills/decisions.md ·
behaviors/ · tokens/semantic.json
Design timeVendor-neutral
The standing brief every agent reads first. Preferences live here; invariants live in hooks.
Placement and reachability, not presence. The fallback ships with the contract.
Promptprompts/weekly-critique.md
Review every screen changed this week against
skills/brand.md and the pattern library.
For each issue: severity, the rule it breaks,
and the smallest fix. Check the decision log
before proposing anything it already settled.
Generate nothing. This is a critique.
Design timeStanding ritual
The critique, made continuous. Quoted material keeps its own voice.