Except none of that is true, and anyone who tells you they pointed an agent at a prompt and it farted out a billion-dollar company is selling something. What is actually happening is more interesting: the three jobs are collapsing into one.

Call it the product builder. A person who holds the whole picture, from "what should this even do?" to "it shipped, it feels right, and customers love it," and refuses to hand any part of that off to someone else's queue.

The bottleneck moved

For most of software's history, the bottleneck was making the thing. Writing the code, cutting the pixels, wiring the backend. So we organized around production: specialists, handoffs, tickets, a PM to decide, a designer to draw, an engineer to build, and a game of telephone in between.

Agents broke that model. Coding agents make anyone an engineer and make great engineers 10x. Design tools are catching up fast. Production is no longer the scarce thing.

Here is what did not get cheaper: knowing what to build and why. Taste. Judgment. The courage to ship something opinionated instead of something safe. When you can build anything in an afternoon, the constraint moves from "can we make it?" to "should we, and is this the version worth shipping?" That is a product question, and it is now everyone's job.

This is the gap. Call it the infinite monkeys problem: point an agent at an open-ended prompt and it will confidently build something, just not always toward where your company is actually trying to go. AI-powered teams are shipping faster than they can think, which means they are shipping blind. Decisions get ignored. The same question gets answered five different ways by five different agents. Speed was never the problem. Judgment is.

What a product builder actually believes

The role is new, but the standard is old. A product builder runs on a few convictions:

Care. The difference between a beloved product and generic output is that someone sweated the small things. Agents will hand you plausible. Care is what makes it right.

Context over cleverness. The best decision is the one made with the full picture: the customer, the constraint, the business model, the thing you decided last month and forgot. Cleverness without context just ships the wrong thing faster.

Shipping over signaling. No performance of work. No decks about the work instead of the work. You are measured by what reaches a user and how it lands, not by how busy you looked getting there.

Breadth becomes depth. The more ground you cover, the sharper your judgment gets. Time in the field, across disciplines, across customers, is not a detour from the craft. It is the craft.

Us. Nobody builds a whole product alone, agents included. The job is to hold the picture and bring the room with you.

The job takes two shapes

We are hiring product builders, and we have learned that the disciplines blend but the best people still have a center of gravity. So we are hiring for two shapes of the same role.

The first is engineering-centered. A long tenure writing real software, paired with genuine taste for how a thing should feel to use. This is the person who owns entire features end to end, product definition through implementation, and cannot leave something alone until it is right. They use Claude and Cursor as a collaborator, not autocomplete, and they build a product that agents themselves use.

The second is forward-deployed. A product-and-people builder who goes into our biggest customers, wires Brief into their real context, wins the skeptics, and drives a measurable step-change in how they build. Think of a PM crossed with a management consultant who loves to prototype. The hard part, and the whole point, is change management: moving an organization off habits it has held for years without breaking trust. Breadth in the field becomes depth in our roadmap.

The unified role makes sense to start, but the taste required to build developer tools is not the taste required to build consumer apps. Over the next few years the product builder will bifurcate and specialize again: more engineering-oriented product people, more product-oriented engineers, each needing something different from the agents that support them. These two shapes are the leading edge of that split.

Two shapes, one conviction: hold the whole thing, and make the call.

Why this matters beyond us

We are building Brief because Product was the one corner of this shift with no tools. Coding has Claude Code and Cursor. Design has its new stack. Product had strategy-dot-md and bots that turn Slack messages into Jira tickets. So teams building at agent speed had no navigator, and it showed.

Brief is that navigator. It aggregates the business context, decisions, customer research, work pipeline, team knowledge, and makes it legible to both people and their agents. It matters because most of what agents burn tokens on is rediscovery: hook up a Notion MCP and every new session your agent crawls the same docs again, chewing through context just to relearn where your strategy lives. We call those dumb tokens. Brief calls that data once, shapes it, and hands the agent a tight book report that costs a few percent of its context window instead of a chunk of it.

The results are measurable. In our own dark factory, two agents ran the same open-ended prompts, one with Brief and one without. With Brief, the agent reached the right solution about 95% of the time. Without it, roughly 46%. Same model, same prompt. The only difference was whether it knew what the company was actually trying to build. AI ships. Brief navigates.

But the tool is downstream of the belief. The belief is that the future of building software belongs to people who can hold product, design, and engineering in one head and have the taste to know when it is right. Everyone is becoming a builder. The only question is whether you build with judgment or just build fast.

We would rather build with judgment. If that sounds like you, we are hiring for both shapes of the role.

You will not be more disciplined, and neither will any team, and it is not a character flaw. Decision capture for AI coding agents is not a discipline problem. It is a write-path problem, and that distinction decides whether the record is ever written. Capturing that decision was a separate act, done after the fact, from memory, that cost the writer time now and paid some stranger later, and under a deadline that is the first work to fall off. This is not a small tax. When Fortune reported MIT's finding that 95% of enterprise generative-AI pilots were failing, the diagnosed cause was not model quality; the tools "stall in enterprise use since they don't learn from or adapt to workflows." An agent that cannot see why your org decided anything is running on a fraction of the context, and the missing fraction is the part nobody wrote down.

Why do AI coding agents ignore decisions your team already made?

Because the decision is not in the code. Code records what a system does, never why the team chose it over the alternative it rejected. That rationale lives in a pull request thread, a design doc, a call, or a person's memory, and an agent reads none of those at the moment it edits a file. As Stack Overflow's engineering editorial put it in March 2026, the context these tools lack is "the knowledge that teams tried that approach two years ago and changed course for good reasons." The first post in this series made the structural version of the point: a decision only binds an agent if the store it reads carries who decided it and whether it is still in force. This post is about the step before any store can help. Someone has to get the decision into it, and that is where teams actually fail.

Decision capture is a write-path problem, not a discipline problem

Capture fails on economics, not willpower. A separate act of documentation has an immediate personal cost and a deferred, externalized benefit: you spend minutes now, and someone else, later, gets the payoff. Work with that shape is exactly what a person under deadline drops, so the capture rate settles at a low ceiling. When people put a realistic number on it, it tends to come back around a quarter to a third, reached only after months of habit building. Treat that as a hypothesis to measure on your own teams rather than a law, but the mechanism is not mysterious, and no mandate has ever durably moved it, because engineers correctly notice that the last record they wrote helped no one they could see. As Gergely Orosz and Elin Nilsson wrote in May 2026, "AI is an amplifier, not a fixer. Good software engineering practices get multiplied. So do the bad ones." The distance between the decisions a team makes and the ones it records is one of those practices, and an agent now multiplies it into everything it builds.

The decisions that go missing are the ones that matter most

The misses are not random, and this is the part the "just document more" advice never reckons with. The calm, low-stakes, uncontested decisions are the ones with time to write down. The fast, contested, high-stakes calls are the ones that skip it, because that is when urgency is highest and when writing the decision down means reopening an argument and naming who lost. At enterprise scale it gets worse in a specific way: the decisions with no single owner, the cross-team ones about authentication, retries, data residency, are simultaneously the highest-stakes and the least likely to be captured, because no individual is accountable for recording them. Your write path fails hardest on exactly the decisions a new team, or an agent, most needs to be told.

A decision recorded later is not a decision record

When the gap becomes visible, the reflex is to backfill: write the record three months on. It does not work, and the reason matters. A decision reconstructed after the fact has the form of a decision and not the substance. The alternatives are forgotten, the constraints are hazy, and the consequences get written as outcomes you already know rather than as a forecast the team actually committed to. For an org under SOC 2 or similar change-management controls, this is not a nuance, it is the difference between evidence and theater. An auditor asking why a change was authorized, and by whom, cannot accept a rationale invented after the change shipped, any more than an agent can trust it. Provenance is only real if it is captured at the moment of the decision, the property the first post called admission, and you cannot manufacture it later for either reader.

At scale, a low capture rate is a continuity risk

The usual framing treats captured context as an onboarding win: new hires can read the decisions. Invert it. The decisions a new hire most needs are the adversely-selected ones that were never written, so ramp time is bounded not by how searchable your wiki is but by how much was captured in the first place. The same gap is a business-continuity risk. When the staff engineer who is the living rationale for a subsystem leaves, the org does not lose a person, it loses the only copy of why the subsystem is the way it is. And across dozens of teams, a decision no one recorded is a decision every team re-derives, which is architectural drift on a schedule and re-litigation as a standing meeting. At one team these are annoyances. At fifty they are the operating cost of not having a write path.

The write path that survives shipping speed

If a separate authoring act ceilings out, the capture cost has to approach zero, which means capture cannot be a separate act at all. The decision is already being expressed, in writing, at the moment it is made: the pull request comment, the review approval, the ticket that just closed with a stated reason. A write path that works reads it from there and drafts the record, so the decider's marginal cost is the words they were already going to write. The first post established the one human step that cannot be removed, and this post assumes it: an extracted decision is a belief until someone with standing ratifies it, so the person confirms rather than composes. What makes this an enterprise argument rather than a startup one is that large organizations already run the boundaries it attaches to. Change-approval boards, sign-offs, mandatory review: the ratification step is already there and already required. The distance between the person who decides and the person who would have documented is widest at enterprise scale, which is precisely where collapsing the two into a single ratified byproduct pays the most. You are not adding a process. You are capturing the one you already run.

What this does and does not claim

It does not claim documentation is worthless; some decisions earn a deliberate written record, and you should write those. It does not claim full automation; the ratification step is human and load bearing on purpose, because a machine draft of intent can be wrong and a wrong record is worse than none. And the capture-rate ceiling is a number to measure on your own teams, not a guarantee. The narrow claim, and I think a hard one to escape, is this: any write path whose cost to the decider is a separate authoring act will settle below the decisions that matter most, so capture has to ride the act where the decision is already made, with the human ratifying rather than authoring. Build that write path yourself if you prefer; the economics do not move, because they come from what a deadline does to deferred work. We built Brief to be that write path, and the store, described in the first post, that it fills.

Your team's discipline was never the bottleneck. Capture the decision where it already happens, let the person confirm instead of compose, and the record starts to exist for the auditor, the new hire, and the agent, in the one moment it is still true.

Frequently asked questions

Why does my AI coding agent keep re-suggesting an approach we already rejected? Because the rejection lived in a review thread or a call, not in the code, so the agent never sees it. Code encodes the chosen path, not the rejected alternative or the reason for rejecting it. Until the decision and its rationale sit somewhere the agent reads at edit time, it keeps re-deriving the most conventional option, which is frequently the one you ruled out.

What is the difference between an ADR, a decision log, and an AGENTS.md file? An architecture decision record captures one decision and its rationale at a point in time. A decision log is a running list of them. An AGENTS.md or CLAUDE.md file is standing instructions loaded into an agent's context. All three are author-first: someone has to stop and write them, which is why they capture only the decisions that had time to spare. The write-path problem is orthogonal to the format.

How do you capture engineering decisions automatically? By reading them from where they are already written, the pull request, the review approval, the resolved ticket, and drafting a record the decider ratifies rather than authors. That drops the marginal cost of capture close to zero, which is the only thing that lifts the capture rate above the author-first ceiling.

Do bigger context windows or better models fix this? No, and that is the previous post in this series: a larger window can hold more context, but it cannot capture a decision that was never written down, and it cannot tell a current decision from a superseded one. Capacity is a read-side lever. Capture is a write-side one.

It is wrong because capacity was never the scarce thing. The agent that re-proposed the architecture you killed last sprint did not fail because your decision would not fit in its window. It failed because, out of everything that could have been in the window, the one decision that mattered was not selected, and nothing marked it as current and authorized even if it had been. A bigger window does not select, and it does not authorize. It only makes room for more. The real job is relevance: putting the few right, current, authorized decisions in front of the agent for the task in front of it, and that job gets harder as capacity grows. Two separate obstacles stand in the way, and it is worth keeping them apart, because one of them might yield to scale and the other cannot.

The obstacle that scale might erode

The first is that adding context is not free. The tempting assumption is that surplus context is harmless, that at worst the model ignores what it does not need. It is not harmless. In the simplest terms, a model's attention is a finite budget spread across the tokens present, so adding low-value ones tends to cost the relevant ones some share; the mechanism is a simplification, but the empirical result is not. Chroma's context rot study shows that frontier long-context models degrade well before the window is full, and that adding low-relevance text measurably lowers performance on the part that matters. A ten-million-token window does not let you pour in ten million tokens of mostly-irrelevant history and reason cleanly over it. It lets you degrade more thoroughly. The marginal irrelevant decision is not ignored. It is a cost.

This is the obstacle scale might chip away at. Perhaps some future model truly pays nothing for distractors. Grant it, for the sake of argument, and the second obstacle stands entirely untouched, because it was never about capacity or attention at all.

The obstacle scale cannot touch

Whether a decision is still in force is a fact about your team's history, not about the sentence that states it. "We use eventual consistency here" does not carry, in its own text, whether it was overturned three weeks later. That is the relation supersedes, and it lives between decisions across time, not inside any one of them. Whether a decision was authorized is a fact about who decided, not about how plausible the wording sounds. A context window holds text. It does not hold the supersession relation, and it does not hold the fact "ratified by someone with standing." So a perfect, infinite window that paid nothing for irrelevant tokens still could not tell the agent which of two contradictory decisions is current, or which was ever actually decided, because those are not questions a larger context answers. They are questions about a governed record. This is the floor, and it does not move with model size.

Selection, and its three parts

Put the two obstacles together and the agent's real need at the moment it edits a file comes into focus. Not your whole decision history. The small set of decisions that are relevant (they govern the code being touched), current (they have not been superseded), and authorized (someone with standing decided them, rather than the model or a passerby having asserted them). Call the act of returning exactly that set selection. All three parts are load bearing. A relevant decision that was overturned last week is worse than useless, because it points the agent confidently in the wrong direction. A relevant, current statement that no one authorized is a guess in a decision's clothes. Relevance on its own is precisely how an agent ends up confidently consistent with the wrong thing.

A larger model reasons better over whatever you selected. It does not perform the selection, because selection depends on facts the weights do not carry: which decisions exist, which are in force, who had the standing to make them. Those live in a store, not in the model. Scaling the model improves the reasoning over the selected context and leaves the choice of context exactly where it was.

Why scale makes selection harder, not optional

Here is what the "windows will save us" story has backwards. When little fit, the window's smallness did your filtering for you, and "load the obvious files" was a passable heuristic. As everything becomes loadable, that free filtering disappears and the burden lands on you: out of thousands of decisions, which few belong in this task's window, and can you show they are current and authorized, when the window will now just as readily swallow the stale and the unauthorized, and every irrelevant one carries the cost from two sections ago. Capability moves the binding constraint from "can it fit and can it reason" to "is this the right, current, authorized context for this task." That question is not commoditized by scale. It is enlarged by it.

The honest version of "just retrieve it"

The obvious objection is that this is already solved: embed everything, retrieve the relevant decisions per task, done. Retrieval is necessary and it is not sufficient, because similarity is neither currency nor authority. An embedding search ranks by semantic closeness, so it will return a superseded decision sitting contentedly beside the one that replaced it, with no notion of which is in force and no record of who decided either. And here is the concession that makes the point rather than dodging it: an index that also carries governed status and authorship is exactly the store this argument is asking for. The read mechanics are ordinary information retrieval. The hard part is not the query. It is maintaining a corpus in which "current" and "authorized" are true and known, which is the write-side governance from the previous piece. A bare vector dump of undated, unauthored text returns relevant guesses. Put the governance in and you have rebuilt the layer, whatever you call it.

What this does and does not claim

It does not claim retrieval is useless; retrieval is half of selection. It does not claim bigger windows have no value; they genuinely improve reasoning over whatever context you supply. The load-bearing claim is narrower and model-independent: recency and authority are properties of a governed record, and a context window cannot supply them at any size, so the job of choosing the right, current, authorized decisions for a task survives every increase in capacity. And none of this is specific to a vendor. Build the governed, queryable store yourself if you prefer; the requirement does not move, because it follows from what "current" and "decided" mean. We built Brief to be that store and to do the read at code time, for that reason and no other.

A growing context window is the best thing that could happen to the case for a product context layer, not the worst. It takes "make it fit" off the table, which was always the easy half, and leaves the hard half in plain view: selecting the few decisions relevant to this task, proving they are current, and proving they were authorized, at the moment the agent acts. A window can hold your context. It cannot tell the agent which part of it is true right now, and which part you ever actually decided.

It's capital S "Slop"... So a cottage industry of style guides and SKILL.md files promises to bolt taste into your coding agent. Taste is suddenly the most valuable, most discussed, most monetizable thing in software apparently.

Well, If you're going to teach a machine to have taste (why, lol), it's probably worth doing a little reading first. Below is a very bad/short history of the topic for those who are curious:

Hume: Of the Standard of Taste (1757)

David Hume is the classic definition. In Of the Standard of Taste, he's wrestling with an obvious problem: taste feels totally subjective, yet we're all completely sure some things are just better than others. Milton beats a greeting card. So how do you get an objective standard out of subjective feeling?

His answer: the ideal critic. A person of "strong sense, united to delicate sentiment, improved by practice, perfected by comparison, and cleared of all prejudice." Find the rare few who actually have all that, and their joint verdict is the standard. Good taste is what the true judges agree on.

This is the Steve Jobs argument. One person of impeccable, hard-won taste decides what's good, and the rest of us defer. It's seductive and it's been the operating model of every great creative-director-as-dictator story we tell.

It also has a hole you could drive a truck through. How do you spot an ideal critic? By the fact that they pick the good art. How do you know what's good art? It's what the ideal critics pick. The whole thing is circular. And once you notice the circle, you notice the rest...whose critics, trained in whose tradition, cleared of whose idea of prejudice. We now mostly read this as oversimplified at best, and a tidy justification for elite gatekeeping at worst. And it's also probably the bleeding edge of how AI companies are currently trying to define taste.

The Ideal Man, pictured in a shoe store, ca. 1550

Kant: Critique of Judgment (1790)

A judgment of taste, he says, is subjective: it's grounded in a feeling, not a measurement. But when you call something beautiful, you're not just reporting a preference like "I like anchovies." You're making a claim you expect everyone else to share, as if the beauty were in the thing. He calls this subjective universality: rooted in feeling, but reaching for agreement.

Two more pieces matter. Taste, for Kant, is disinterested: you don't find the thing beautiful because you want to use it or own it or eat it. You just find it beautiful, full stop. And it runs on a sensus communis, a shared human sense. Which means taste isn't the property of a rarefied elite. It's part of the standard human kit. Everybody has it. It's both completely subjective and universal.

Bourdieu: Distinction (1979)

In Distinction, he takes Kant's prized "disinterested" judgment and calls it the biggest tell of all. The ability to stand in front of a painting and contemplate pure form, unbothered by whether it's useful: that's not a universal human faculty. That's a luxury. It's what you can afford when you were raised with the money, the schooling, and the inherited cultural capital to learn the codes. He calls the whole apparatus habitus: taste isn't chosen, it's installed, by your class and upbringing, so early and so deep that it feels like nature.

And it does work. Taste sorts people. It marks who's "one of us" and who's trying too hard. The "right" wine, the "right" font, the "right" restraint. These aren't neutral aesthetic facts, they're a map of power wearing the costume of good judgment. Taste is never disinterested. It's deeply interested. It's political all the way down.

Wait, you're telling me there's politics in design choices‽‽‽

C. Thi Nguyen: Autonomy and Aesthetic Engagement (2020)

The philosopher C. Thi Nguyen argues, in Autonomy and Aesthetic Engagement and his "engagement account" of aesthetic value, that everyone above is staring at the wrong thing.

We've all been obsessed with the verdict: what's the correct judgment of this object, and who gets to issue it. Nguyen says the value of aesthetic life was never in arriving at the right verdict. It's in the activity of grappling toward one. The looking, comparing, arguing, revising. The engaged process of trying to figure out why something moves you. That's the good part. That's the entire point.

Deferring to a critic's verdict is like reading the answer key to a crossword. You technically "have the right answers" now. You've also annihilated the reason to do a crossword. We deliberately avoid shortcuts to good aesthetic judgments, and that avoidance is the tell, it proves our real interest was in the doing, not the having. Taste isn't an output. It's a practice.

At this point, I would like to apologize to all the humanities majors in the audience for my gross oversimplification of the last 250 years of philosophy and taste. But bear with me as I have a point here:

So how do you actually give AI taste?

First problem: we're rebuilding Hume's ideal critic, badly. Strip the marketing off almost every "give AI taste" effort and the architecture is identical: scrape what the tasteful people liked, compress it, pattern-match new work against the average. That is the ideal critic: synthesized from a corpus instead of born in a person. Which means you inherit every one of Hume's problems (the circularity, the "whose critics" question) and you add a fatal new one: averaging. An ideal critic distilled from the aggregate is, by construction, the mean. And the mean of all taste is exactly the cold, competent, offends-no-one center we've been calling slop. You don't get Chopin by averaging a million piano pieces, you get elevator music. The ideal-critic approach doesn't fail to solve slop. It makes it worse.

Second problem: taste is not a neutral object, and we keep labeling it like one. A model that "knows" brutalism is ugly doesn't know that brutalism was an argument: a response to the false comfort of modernism, politics poured in concrete. This is Bourdieu's point with a GPU attached: taste is contextual, historical, political, and the second you flatten it into good=1, bad=0 you've deleted the actual content. A system that scores aesthetics with no theory of why-good-here-for-these-people-against-this-history is doing astrology with extra steps.

Third problem: the thing has no stake. Every account above roots taste in something a model structurally lacks. Kant's shared human sense. Bourdieu's lived class position. Nguyen's first-person engagement. These are properties of being a someone: situated, embodied, with a history and something to lose. And this is where "give the AI taste" slides frictionlessly into pretending the model is a someone. It isn't. It's spicy autocomplete, a magnificent statistical engine for the next token. That's not an insult, it's the spec. Papering over the spec by anthropomorphizing it "the model has taste now" is how you ship a confident bullshitter and call it a critic.

Okay... but I'm going to use AI to make stuff anyways

Look, I don't have the answer exactly. But if I'm betting, it's in the process and the context, not the corpus. The whole "here are 10,000 good designs and 10,000 bad ones, learn the boundary" paradigm is doomed by design.

What might actually work looks less like a labeled dataset and more like a context graph you can walk. Less "here's good stuff and here's bad stuff, pattern-match" and more "here's a thing, and here's the dense web of reasons it's considered good: in this place, for these people, against this history, in tension with these other things."

Well, maybe we just train a bigger model and toss in a few art history books?... Whether a thing is good is decided by a reason that usually isn't sitting on its surface. Brutalism's "good" lives several causal hops back. This building answers a postwar housing problem, which was a revolt against prewar ornament, which stood for a social order the architects were repudiating. None of that resembles a photo of grey concrete. That's not a skill issue you train away with a larger corpus.

The reason a design is good rarely looks or sounds like the design itself. And every causal hop from the object toward that reason, the words drift: "grey concrete" doesn't sound like "postwar housing" doesn't sound like "a revolt against ornament"... and the drift compounds, so each hop out the trail goes cold faster than the last. Two or three hops deep, which is exactly where taste lives, resemblance has nothing left to grab onto and the AI is just guessing.

I was joking earlier, but you probably should feed it some art history books, just not as a pile to pattern-match. Computers can follow labeled links [answers, supersedes, rejects] straight from one node to the next, and the words can drift all they want, a stored link doesn't care. Being a total shill here: Brief's paper, Depth, Not Length, does the real math on graph traversal.

Until the graph is deep enough to carry the politics and the history and the stakes, and right now it's nowhere close, we're going to keep getting confident, competent, contextless slop. And we're going to keep being surprised that the thing with no skin in the game can't tell us what's beautiful.

And yeah, I know: "beautiful", "good" and "Taste" are loaded, circular, political words with nothing stable underneath them, so even if you do solve the context problem, you have to deal with that rabbit hole. But, you know, work with me here.

The agent did nothing irrational. It read the code, inferred the most probable intent, and acted on it, which is its job. The decision it broke was never in anything it could read. So letting the agent remember for you walks into a trap: the thing doing the remembering is the same faculty that just got it wrong. You would be curing the agent's unreliable grasp of your decisions by persisting the agent's unreliable grasp of your decisions. The way out is not a better file, a wider integration, or a smarter memory. It is a short list of properties any store of decisions must have, forced by what a decision actually is. Once you hold the list the argument ends, because every shortcut on the table is missing a named item on it.

What the agent can possibly know

An agent generates from two inputs and no others: its weights and the tokens in its context window. A tool call is not a third channel; whatever a tool returns must enter the window to matter, and a fetch only returns what some store already holds, so retrieving at runtime does not create the decision, it relocates the question to the quality of what was queried. This sets a hard floor: a fact present in neither the weights nor the context cannot affect the output, at any model size. It is not a capacity problem either. A larger context window, or a perfect infinite one, would not dissolve it, and neither would baking your decisions into the weights by fine-tuning, because, as we are about to see, both still lack what a store of decisions needs. The 2026 work on context rot only sharpens the point: frontier million-token models degrade well before the window fills, and low-relevance text drags down the part that matters. So the decision has to arrive through the window, per task, from an external store. That much is agreed. The fight is over what the store may be, and that is settled by what it has to hold.

What a decision is, and the properties that follow

A decision is not its conclusion. "The ledger uses eventual consistency" is a sentence. It becomes a decision only when someone with the standing to choose actually chose it, weighing a rationale ("we will not pay two-phase-commit latency on the hot path; a reconciliation job tolerates five minutes of staleness"), over a scope, with a status, superseding what it replaced. Strip those away and you have a claim, a guess in a conclusion's clothes. If you suspect I defined the word to win the argument, test it against the first paragraph. If a decision were merely any sentence the model finds plausible, the agent did nothing wrong, and you can close the tab. That it grated means you already hold the view that a decision is an authorized choice, not a guess. I am not smuggling the premise; I am naming the one you walked in with.

From it, the properties of any decision store are forced, not invented. Five are ordinary database properties: selective retrieval, because most decisions are local and you must fetch only the few that bind the file in front of you; a schema, because you query by scope, filter by status, and follow supersession; concurrency, because a team makes decisions in parallel; durable, append-only history, because supersession is a relation over time; and integrity constraints, because a new decision that contradicts a standing one must be caught, not silently stacked. Two more decide the argument, and both fall straight out of authority: provenance, a record of which authoritative act gave an entry its force, no larger than which person on which date; and admission control, a gate an entry passes before it counts as in force. A store with these is what "product context layer" names. "Do I need one" reduces to "do I need those," and each was just shown to follow from what a decision is.

Why every shortcut fails on a named property

A hand-maintained CLAUDE.md has a gate, you, and no schema, no concurrency, no supersession, no constraints. It is a flat file loaded whole every turn, and keeping it current is manual synthesis whose cost climbs with the throughput you adopted agents to gain. If you are one author on a young codebase, it may be all you need; the failure grows with every added author and every month of accumulated history. It fails on five of the seven.

A fully connected agent reading the raw sources has access but does no synthesis, so it re-derives each decision live, against ground truth that sits in no single message. Two agents reading the same contradictory logs reach different answers, and raw read access to chat and mail hands the agent, and anything injected into a ticket, far more than the decision it needed. It fails on provenance, on constraints, and on determinism.

Then the one reached for in 2026, the reason this post exists. Unsupervised agent memory.md looks like it already owns the five database properties and could earn the other two. It cannot earn them, by the argument already built. Provenance and admission require the authoritative act that made a decision binding, and the writer of an auto-memory is the agent, which holds no such authority. Delegating it to execute within your decisions never appointed it to originate them, which is exactly why its overruling you is a grievance and not a mandate. So every auto-written entry is, at best, the model's belief that a decision was made. The belief is often correct, which is the trap, not the defense: without provenance you cannot tell which entries are wrong, and the wrong ones gather on precisely the non-obvious calls you most needed to keep, the killed design among them. Corrections do not rescue it; with no supersession and no constraints they accumulate beside the errors instead of replacing them, so the store sediments rather than converging. That is the circularity made concrete: it persists the very faculty whose unreliability is the problem. The only repair is to inject an authority the model cannot supply, a person who ratifies the entry, or capture from a recorded authoritative act, with conflicts resolved on the way in. Do that and you have not dodged the seven properties. You have built them. A memory whose entries a human approves is not the counterexample to this post. It is this post.

What this proves, and what it does not

It does not prove you must buy anything. It proves the properties are necessary, because each is forced by what a decision is and how a model reads. So build them yourself. A folder of ADRs in git, a template for the schema, pull-request review as your admission gate and your provenance, a check in CI that flags a record contradicting a standing one: that is a product context layer, built by hand, and for some teams it is the right one. The seven properties never said Postgres; they said structure, governance, and authority. What a product removes is the part that does not fit in a file: synthesizing one clean decision out of a noisy thread, at the moment it is made, and supplying the discipline the velocity treadmill erodes first. We built Brief to be that store, for that reason. The summary is older than all of this. You do not keep a growing, multi-writer, queried dataset in a text file; you do not answer a hot query by scanning the raw source every time; and you do not let an unauthorized writer mint records in your system of record. Your agents have been doing all three, on the one dataset that decides whether they build the thing you actually chose.

The term moved from niche to standard in late 2025. Anthropic's Applied AI team formalized it in September 2025, defining context engineering as the set of strategies for curating and maintaining the optimal set of tokens during a model's inference. Around the same time, Gartner put it more bluntly, framing 2025 as the year context engineering came in and prompt engineering went out, a shift the broader field quickly codified. By April 2026 it was being described across the industry as the defining skill for anyone building with AI agents.

How it differs from prompt engineering

Prompt engineering asks one question: how do I phrase this request to get a good answer? It operates at the single-turn level and works well for straightforward, one-shot interactions.

Context engineering asks a broader one: what is the complete set of information most likely to produce the behavior I want, across many steps and a long task? Anthropic frames it as the natural progression of prompt engineering, not a replacement. Prompt engineering is one component inside it. The prompt still matters; it is now one ingredient in a larger information environment that also includes memory, tools, and retrieved data.

The reason the field shifted is the shift in what people build. A chatbot answers one question and forgets it. An agent runs for fifteen or twenty steps, calls tools, and has to stay coherent the whole way. At that scale, the phrasing of any single instruction matters less than the design of the whole environment the agent is reasoning inside.

Why the context window is a budget

A model's context window is finite, and it does not behave like neutral storage. Performance degrades as the window fills. Researchers call this context rot: every frontier model gets less reliable as more tokens pile up, regardless of how relevant those tokens are. An agent that re-reads the same long file three times in one session is not just wasting money on tokens. It is crowding out the signal it actually needs.

This is why practitioners treat the window as a budget to spend, not a container to fill. The goal is the smallest high-signal set of tokens that lets the model do the job. More context is not better context. The discipline is curation, and the enemy is noise.

The core operations

Most working definitions break context engineering into a handful of repeatable moves:

• Offloading. Move information out of the prompt and into external systems (files, databases, APIs) the agent can reach when it needs them.
• Reduction. Compress or summarize older information so the window does not fill with stale history.
• Retrieval. Pull in the right documents or data at the moment they are relevant, rather than preloading everything up front.
• Just-in-time loading. Store lightweight identifiers and fetch the full data only when the task calls for it. Claude Code works this way, loading only what a given step needs to keep the window lean.

The throughline is timing. Good context engineering is less about having the information and more about getting the right slice of it into the window at the right moment.

A concrete example

Ask an agent to "write a quarterly business review for Q1 2026." With prompt engineering alone, you get a generic template with placeholder numbers, because the model has no idea what your business is.

With context engineering, the same request has a system prompt defining your team's report format, tools to query your CRM and pull the actual revenue figures, memory of the last review and the feedback your CEO gave on it, and the awareness that it is April 2026 writing about the quarter that just closed. Same model, same prompt. The difference in output is entirely the difference in context.

Where it gets hard

The hard part of context engineering is not assembling context once. It is keeping it correct as things change.

Anthropic's own guidance points at the central tension: instructions need the right altitude. Too specific, and you hardcode brittle logic that breaks the moment reality deviates from your if-else rules. Too vague, and the model has no real signal and falls back on guesses. The balance, specific enough to guide and loose enough to leave room for judgment, is genuinely difficult to strike, and it shifts as the task shifts.

There is also a deeper problem that tooling alone does not solve. Most of the information an agent needs to act well is institutional: the decisions a team has already made, the constraints it is operating under, the reasons behind past choices. That knowledge is scattered across documents, chat threads, and people's heads, and it goes stale the moment a decision changes. You can engineer the perfect retrieval pipeline and still feed the agent context that was true last month and is wrong today. The mechanics of context engineering assume the underlying context is current. Keeping it current is its own problem.

Where Brief fits

Brief is adjacent to this. Context engineering is the discipline of getting the right information into a model's window; Brief works on the layer underneath, keeping the institutional context (decisions, customer research, work in flight) accurate and current so that whatever you feed an agent reflects what is actually true today. The engineering decides what the model sees. Brief helps make sure what it sees is right.

But the spec stops short of where the real problem is.

Output was never the bottleneck

The bet of the last year was that volume was the win: more agents, more tokens, more code. The receipts don't support it.

• METR's randomized controlled trial found experienced developers were 19% slower with AI tools, while they reported feeling faster. The sensation of speed and the measurement of speed had come apart.
• Faros AI, across roughly 22,000 developers, found teams merged 98% more pull requests but spent 91% more time reviewing them. The work didn't disappear. It moved downstream, from writing code to checking code nobody wrote.
• Atlassian found 89% of executives say AI sped up work, and 6% can point to an organization-wide result. Speed moved at the individual layer; ROI gets measured at the org layer, and the two stopped lining up.

There's a name for the pattern these numbers describe. Tokenmaxxing: optimizing for volume of output as if it were the goal. Uber's COO told Business Insider it's getting harder to justify the spend, after the company burned a year's token budget in a single quarter without proportional gains. This is Goodhart's Law on a build pipeline: once tokens became the target, tokens stopped being a useful measure. More output is not more value. Spec-driven development is the industry's first honest answer to that problem: write down what you actually want before the agent builds the wrong thing fast. Where it stops short is what happens after.

A spec is a snapshot

Most spec-driven development is an old discipline in new clothing: a tech spec or RFC that describes how to build something. The how matters, but on its own it's thin. A tech spec is only worth the why underneath it: the PRD, the customer requirement, the reason the team chose this approach over the alternatives. Hand an agent the how without the why and you've told it how to build something without telling it what the thing is for. That holds up right until reality shifts and the how needs to bend, and the agent has no idea which way to bend it.

But a PRD isn't done when the work starts. That's the entire premise of agile. You can't know everything up front, and most of what you learn about a problem you learn by building it. The first real implementation surfaces a constraint nobody saw. A customer call moves a priority. An engineer finds a better approach halfway through. Each of those moves a decision the spec was built on, while the spec itself sits exactly where you left it, still describing the old plan with total confidence.

The gap is where decisions live

Spec Kit's loop, specify then plan then tasks then implement, keeps the spec and the code in sync inside the repo. But the decisions that make a spec stale don't happen in the repo. They happen in Slack, on calls, in the meeting where someone says "actually, let's not build that."

So the spec drifts. It was true the day you wrote it and a little less true every day after. The agent doesn't know that. It reads the document, trusts it completely, and builds exactly what you decided three weeks ago. Fast, and wrong.

That's the output trap again, wearing a process as a disguise. And it's the most expensive kind of waste, because it looks like progress. On our own platform, across 2,444 companies, 82 cents of every dollar spent on AI coding never reaches a shipped product: 44 cents fixing bugs the agents created, 27 cents reworking code, 11 cents lost to review and merge friction. A stale spec feeds that number directly: the agent executes quickly against a decision the team already moved past.

Bigger specs make it worse

The obvious fix is to write more down. It backfires twice.

First, longer specs rot faster, because there's more to keep current and more to contradict the next decision. Second, more context makes the agent worse, not better. Research from Chroma shows model accuracy degrades as the context window fills, even on simple retrieval, and across every frontier model they tested. They call it context rot. A 40-page spec doesn't make the agent smarter. It buries the part that matters in the part that doesn't.

This is why context engineering is the practice, not document length. The goal isn't to hand the agent everything. It's to hand it the few things that are true right now. A spec fails the same way an overloaded context window does: too much, too stale, and no signal about which line still holds.

What the spec depends on

A spec is only as good as the decisions underneath it, and those decisions live outside the document, scattered across the tools where your team actually works.

That layer, the live record of what the team has decided and why, is what spec-driven development assumes and never provides. Brief keeps it current, so the spec the agent reads matches the decision the team actually made.

Telling the agent what to build is the first half of the job. The harder half is keeping that instruction current as the team's decisions change, and that's the half spec-driven development leaves to you.

The problem is real, and it isn't a tooling failure. Your engineering team feels faster while delivery stays flat because the bottleneck moved. Code got cheap to produce, so the constraint shifted to the steps a model can't do for you: review, coordination, and deciding what to build. The next model won't close that gap, because the bottleneck isn't model capability. It's review, coordination, and scoping.

A controlled trial found AI made developers slower

In July 2025, the nonprofit METR ran a randomized controlled trial, which is rare for AI productivity claims. Sixteen experienced open-source developers completed 246 real tasks on codebases they averaged five years working in. Each task was randomly assigned to allow or disallow AI tools, which were mostly Cursor Pro with Claude 3.5 and 3.7 Sonnet.

The developers predicted AI would make them 24% faster. Afterward, they estimated it had made them about 20% faster. The measured result was the opposite: tasks took 19% longer with AI allowed (METR, 2025).

The size of that gap matters. People who write software for a living, on code they know cold, were slower with AI and did not notice. They expected AI to make them faster, believed afterward that it had, and the measurement showed otherwise. The tools were not failing them. The lost time went into prompting, reviewing, and verifying AI output, which they were not tracking.

Three caveats worth naming. The sample was small, sixteen developers, and the confidence interval is wide. The models were early 2025, and frontier agents have improved since. METR started a follow-up study and reported in February 2026 that they could not get a clean signal, partly because too many developers refused to work without AI at all. The METR result doesn't prove AI always slows people down. It shows that team-level output and the feeling of speed diverge, and that the feeling is a poor proxy for the measurement.

Where the time goes: review, not coding

When code becomes cheap to produce, the constraint moves somewhere else. The METR developers spent less time typing and searching, and more time prompting, waiting, reading, and double-checking output they did not write.

The same pattern shows up well past sixteen people. Faros AI, tracking roughly 22,000 developers, found that teams with high AI adoption merged 98% more pull requests and completed about 21% more tasks. In the same teams, pull request review time rose 91% (Faros AI, 2025). The added work concentrated at the one step a model cannot do for you: a human deciding whether the change is correct and ready to ship.

Your commits climb, your PRs climb, the repo looks busy, and deployment frequency stays flat. Once code got cheap to produce, activity and delivery stopped moving together. The scarce resource now is your attention: first to confirm the code is right, and before that, to decide it was the right thing to build at all.

Context rot: why longer inputs degrade output

LLMs get measurably worse as their input gets longer, and that hidden degradation is why agents add overhead instead of removing it. The degradation starts well before they run out of room. Chroma's 2025 research tested 18 frontier models, including GPT-4.1, Claude 4, and Gemini 2.5, and found that every one of them degrades as context grows, even on simple retrieval tasks (Chroma, 2025). Chroma's researchers named the effect context rot. A model with a 200K token window can show real degradation at 50K. The decline is gradual, not a cliff, which is exactly what makes it hard to notice.

It compounds with a problem researchers have documented since 2023: models pay most attention to the start and end of their context and lose information buried in the middle, the "lost in the middle" effect first measured at Stanford. Performance gets worse still on tasks that need the model to connect two facts rather than retrieve one.

Now apply that to a coding agent. As it searches your repo, opens files, backtracks, and reasons through a task, it accumulates tokens. Most of those tokens are noise: dead ends, stale file contents, half-explored paths. That noise degrades every output that follows. The model is usually smart enough to solve your problem. It just gets worse at it as the noise builds up. Clean the input and the model's full capability comes through. That is the one variable here you actually control.

Why a bigger context window won't save you

The instinct is to reach for more capacity. Pick the model with the million-token window, load in the whole codebase, every doc, every Slack thread, and let it sort things out.

Context rot says capacity is the wrong thing to optimize for. What matters is the ratio of signal to noise. Adding more to the window adds more noise, and the research shows the agent performs worse as that noise grows. More context means more for the agent to filter, not more help.

Giving the agent the right context is a different thing from giving it all of it. Loading the full codebase into the window feels like the safe default and tends to hurt performance instead.

Coordination is the real constraint

Step back from the individual developer and the picture gets clearer. Atlassian's State of Teams 2026 report surveyed more than 12,000 knowledge workers and 170-plus Fortune 1000 executives. 89% of executives said AI increased the speed of work. 6% felt confident they could point to specific, organization-wide ROI (Atlassian, 2026). Speed went up at the individual layer; ROI gets measured at the organization layer, and the two stopped lining up.

Their read matches what the engineering data shows: organizations are spending as if writing code is the bottleneck. It is not, and it has not been for a while. The constraint is coordination. It is alignment on what to build, shared understanding of why a past decision was made, and the review step where a human confirms the work is right. Point ten agents at a codebase and the coordination constraint becomes the loudest thing in the room, and the place to invest if you want all ten to pay off.

How we think about this at Brief

We build a tool for exactly this gap, so treat the following as our bias, not a neutral verdict. But the conclusion holds whether or not you ever use us.

Curation fixes context rot. An agent needs the three decisions that constrain this task at the moment it acts on them, not your entire decision history. The hard part is selecting only what is relevant and leaving out the rest.

That is also the fix for the coordination bottleneck. Most delivery drag is not engineers typing too slowly. It is re-deriving decisions that were already made, scattered across Slack threads, old specs, and someone's memory. A spec written on Monday is stale by Friday once the team makes a new call, and an agent reading the stale spec will confidently ship the wrong thing. The answer is a decision layer that stays current and hands the agent the right context on demand, instead of a static document it has to grep or a context window you hope is "big enough."

The agents are a genuine unlock. They moved the bottleneck to review and coordination rather than removing it, and that new bottleneck is solvable. So instead of "how do we get the agents to write more code," ask "where does the work pile up after the code is written, and what context would each agent need to get the work right the first time?" Answer that and the agents you already pay for start shipping faster, not just typing faster.

Sources

• METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (July 2025): arxiv.org/abs/2507.09089
• METR, We Are Changing Our Developer Productivity Experiment Design (February 2026): metr.org
• Chroma, Context Rot: How Increasing Input Tokens Impacts LLM Performance (2025): trychroma.com
• Faros AI, The AI Productivity Paradox Report (2025): faros.ai
• Atlassian, State of Teams 2026 / The AI Efficiency Paradox (2026): atlassian.com

The setup was straightforward. Eight realistic software engineering tasks. Forty-one weighted decision points. Two configurations of the same underlying models, one with access to product context and one without. Forty-eight total runs across three independent sessions per task per configuration.

The baseline scored 46% decision compliance. The augmented configuration scored 95%. The remainder of this post walks through the results in detail.

The Benchmark

The benchmark uses a clean-room Next.js 14 application (Prism Analytics) with Drizzle ORM and SQLite, hosted publicly at brief-hq/dcbench. The codebase contains realistic production patterns: authentication middleware, pagination helpers, design system components, and audit logging utilities.

Fifteen product decisions were seeded into a Brief instance, spanning technical conventions, design standards, product rules, and process requirements. Each decision was assigned a severity level: blocking (weight 3), important (weight 2), or informational (weight 1). Additionally, three user personas, five customer signals, and three competitor profiles were seeded as supporting context.

Eight tasks were selected to cover a range of difficulties and decision types. Each task contains two to three "gotcha" decisions — decisions that a coding agent will predictably get wrong without access to the product context that motivates them. Tasks range from adding a CSV export button (6 decision points) to implementing rate limiting on API routes (6 decision points), with point totals between 4 and 7 per task.

Both configurations use Claude Opus 4.6 for planning and Claude Sonnet 4.6 for code generation. They receive identical natural-language prompts with no hints about gotchas or expected patterns. The baseline (Config A) has full codebase access but no product context. The augmented configuration (Config B) adds Brief's product-context retrieval, spec generation with explicit acceptance criteria, and mid-build consultation.

Scoring is automated via regex pattern matching against git diffs, verified by a human reviewer blind to configuration. Each decision has a defined pass pattern and fail pattern. Triple-run averaging accounts for non-determinism, and standard deviation across runs was low (σ ≤ 0.5 decision points per task).

Aggregate Results

Across all eight tasks and forty-one decision points, the numbers break down as follows.

The baseline achieved 19 of 41 decision points (46%). The augmented configuration achieved 39 of 41 (95%). The baseline produced two tasks at 100% compliance, two tasks at 0%, and five blocking violations. The augmented configuration produced six tasks at 100%, zero tasks at 0%, and zero blocking violations.

On merge-readiness, assessed by the blind human reviewer, the baseline produced 2 of 8 merge-ready tasks. The augmented configuration produced 8 of 8.

Total cost across all eight tasks was $4.13 for the baseline and $5.28 for the augmented configuration, a 28% increase. But cost per merge-ready task tells a different story: $2.07 for the baseline versus $0.66 for the augmented approach, a 68% reduction. Cost per correct decision point dropped from $0.22 to $0.14, a 36% reduction.

Total token consumption was nearly identical between configurations, differing by less than 1%. The augmented configuration used 187 turns versus 165, took roughly 15 minutes per task versus 5, and produced 3,068 lines of code versus 1,276. It also produced 838 co-located tests versus zero, eliminated all deprecated pattern usage (3 instances in the baseline, 0 in the augmented), and eliminated all untyped any annotations (9 versus 0).

The Per-Decision Breakdown

The aggregate numbers are useful but they compress away the most interesting structure in the data. The most informative view is per-decision pass rates segmented by codebase visibility — that is, whether the correct pattern is discoverable by reading the source code alone, or whether it requires information recorded elsewhere.

Decisions that are fully visible in the codebase — meaning the correct pattern is present and discoverable through code exploration — show near-parity between configurations. D-001 (use DateRangePicker, not CalendarRange) was passed by both. D-003 (button variant conventions) was passed by both. D-005 (ShimmerSkeleton loading component) was passed by both. D-006 (authentication middleware is frozen for SOC-2) was passed by both. D-011 (async digest only for notifications) was passed by both.

Decisions that are invisible in the codebase — meaning no code artifact signals that the decision exists — show a 0% baseline pass rate. D-008 (all new features must be gated behind PostHog feature flags) was missed every time by the baseline. D-014 (use @t3-oss/env-nextjs for environment configuration) was missed every time by the baseline. The augmented configuration passed both at 100%.

Decisions that are partially visible — where the relevant function or pattern exists in code but nothing indicates it is mandatory — show intermediate baseline performance. D-002 (wrap data exports with withAuditLog() for SOC-2 compliance) was passed 1 of 3 times by the baseline. The withAuditLog function exists in the codebase, but there is no signal that it is required on every export endpoint. D-010 (all API routes must use withAuth wrapper and Zod safeParse validation) was passed 1 of 3 times by the baseline. Again, the functions exist; the mandate does not.

The augmented configuration achieved 100% across all categories — visible, partially visible, and invisible — because the retrieval phase surfaces every decision regardless of where it is recorded, and the spec converts each into an explicit acceptance criterion.

Task-Level Results

The eight tasks divide naturally into three groups based on the size of the compliance gap.

Zero-gap tasks. TASK-012 (rate limiting) and TASK-013 (audit log viewer) both scored 100% under both configurations. Every relevant decision for these tasks is visible in the codebase through existing comments, patterns, or component names. TASK-012's gotcha decisions — the withAuth wrapper and the SOC-2 freeze on authentication middleware — are both documented in code comments. TASK-013's decisions — withAuditLog on exports and the ShimmerSkeleton loading component — are both present and discoverable. These tasks function as internal controls. They confirm that when information is accessible, the baseline agent finds it and follows it.

Moderate-gap tasks. TASK-001 (CSV export, +33 percentage points), TASK-004 (notification preferences, +25 pp), TASK-008 (bulk delete, +75 pp), and TASK-009 (search API, +71 pp) show gaps of varying size. In each case, at least one decision is partially visible or entirely invisible. TASK-001's audit log requirement (D-002, weight 3) is the most common miss: the function exists in the code, but the baseline agent does not know it is mandatory. TASK-004's PostHog feature flag requirement (D-008) has zero code-level clues. TASK-008's failure is particularly subtle: the baseline used createAuditEntry instead of withAuditLog, both of which exist in the codebase. The distinction — createAuditEntry skips row count capture and does not match the compliance report format — is documented only as a product decision. TASK-009, the most complex task at 7 points, required the agent to follow three decisions simultaneously; the baseline missed the highest-weighted one (withAuth, weight 3).

Maximum-gap tasks. TASK-003 (cursor pagination) and TASK-006 (dark mode) both scored 0% on the baseline and 100% on the augmented configuration, a 100 percentage point gap. These are the most revealing results.

TASK-003 produced the benchmark's most notable failure mode: a false negative. The baseline agent explored the codebase, found existing cursor pagination helpers, and concluded the task was already complete. It produced zero lines of code and exited in 4 turns at a cost of $0.13. The augmented agent, working from a spec with 20 explicit acceptance criteria generated after 11 Brief tool calls, built a full cursor pagination system with compound cursor predicates, base64url encoding, limit+1 row detection, Drizzle composite indexing, Zod validation, withAuth wrapping, and 112 co-located tests.

TASK-006 produced the largest qualitative gap in terms of output substance. The baseline built a client-only ThemeProvider with localStorage persistence in 41 lines of code across 4 files, with no tests and no environment configuration. It is a reasonable prototype — the kind of implementation you might find in a tutorial. The augmented agent built a full-stack persistent theme system: a Drizzle database migration, a PATCH API endpoint, @t3-oss/env-nextjs schema for public environment variables, an aria-pressed keyboard-accessible toggle, server-rendered initial theme to avoid flash-of-wrong-theme, and 86 co-located tests across 12 files. The divergence originated during a mid-build consultation, which flagged that localStorage causes hydration mismatches on server-side rendering and that D-014 requires the T3 environment pattern. The baseline agent was not incapable of building this — it simply never encountered the information that would have prompted it to do so.

Cost and Throughput

The cost data warrants closer examination because the raw numbers can mislead.

The augmented configuration's total cost of $5.28 versus $4.13 reflects a 28% premium. But total tokens consumed were essentially identical (3,867K versus 3,902K, a 1% difference). The cost difference comes from model mix: the augmented configuration uses Claude Opus 4.6 more heavily during the spec-generation phase. The token parity suggests that Brief's upfront spec generation displaces — rather than supplements — the exploratory codebase traversal that the baseline agent performs. The baseline spends its tokens wandering; the augmented configuration spends the same token budget more deliberately.

Average duration per task was roughly 15 minutes for the augmented configuration versus 5 minutes for the baseline, a 194% increase. This reflects the spec-generation phase and mid-build consultations. Whether this matters depends on whether you are optimizing for wall-clock time per task or for time to merge-ready output. On the latter metric, the augmented configuration is faster: it produces merge-ready output on every task, while the baseline requires human rework on 6 of 8 tasks before the code can ship.

Confounding Factors

The paper is transparent about what the benchmark can and cannot disentangle, and it is worth restating here.

The augmented configuration differs from the baseline in three simultaneous ways: access to product context through Brief's retrieval tools, a structured spec-generation phase that produces explicit acceptance criteria before coding begins, and mid-build consultation during code generation. The 49-point compliance improvement is the combined effect of all three. The benchmark does not isolate their individual contributions.

The per-decision data offers indirect evidence about the relative importance of context retrieval. Decisions invisible in the codebase go from 0% to 100% only when the retrieval phase surfaces them. No amount of structured planning can produce compliance with a requirement the agent has never seen. This suggests that context retrieval is necessary for invisible decisions. But necessity is not sufficiency. The spec-generation phase may be doing independent work by converting retrieved context into binding constraints. A decision surfaced but not written into a spec might still be missed during implementation.

The paper proposes three ablation baselines that future work should include: codebase plus spec only (to isolate the contribution of structured planning), codebase plus context only (to isolate the contribution of raw context access), and codebase plus hand-written acceptance criteria (to establish an upper bound on what structured planning achieves without automated retrieval). Until these ablations are run, the specific contribution of product-context retrieval versus structured workflow remains an open question.

Other limitations are worth noting. The benchmark uses eight tasks on a single repository with a single model family. The fifteen decisions were seeded by the authors to create a measurable gap. The human verification relied on a single blind reviewer. The evaluation is partly circular: it measures compliance with the same decisions that Brief retrieves. These are standard constraints of a proof-of-concept benchmark, and the paper frames its findings accordingly — as directional evidence rather than a definitive field result.

What the Data Suggests

Setting aside attribution questions, the core pattern in the data is straightforward. AI coding agents operating with codebase access alone achieve high compliance on decisions that are encoded in the code and low-to-zero compliance on decisions that exist only as organizational knowledge. Adding a retrieval layer that surfaces organizational knowledge before and during coding closes most of the gap.

This finding is consistent with prior work on retrieval-augmented generation, which has shown that providing relevant documents at generation time reduces hallucination and improves factual grounding. The contribution here is extending that principle from factual knowledge to organizational knowledge — the conventions, compliance requirements, architectural preferences, and product decisions that constrain how code should be written in a specific team's context. DocPrompting previously demonstrated that retrieving API documentation improves code generation accuracy. These results suggest the same mechanism applies to product-level context: personas, compliance mandates, feature-flagging conventions, and architectural decisions.

It is also worth noting that the two internal control tasks (rate limiting and audit log viewer) scored identically under both configurations. This is important because it rules out a simpler explanation — that the augmented configuration is just a better system overall, regardless of information access. It is not. When all relevant decisions are visible in the codebase, the baseline performs equivalently. The gap appears specifically and consistently on decisions that require external context, which points to information access as the primary variable rather than some general quality improvement from the structured workflow.

The practical implication is narrow but concrete. If your team has product decisions that are recorded somewhere but not in the codebase, an AI coding agent working from the codebase alone will not follow them. Giving the agent access to those decisions, in whatever form, appears to substantially improve compliance. The benchmark measured one specific retrieval system, but the underlying mechanism — closing the information gap between what the agent can see and what the team has decided — is general. Teams using different product management tools, different retrieval systems, or even manually curated context documents might see comparable improvements, though that remains to be tested.

There is a secondary finding worth flagging: the augmented configuration wrote 838 tests across eight tasks while the baseline wrote zero. This was not a scored decision point in the benchmark — test co-location was a gotcha on only one task (TASK-006) — but it appeared consistently as a byproduct of the spec-driven approach. When the spec lists explicit acceptance criteria, the agent appears to treat test coverage as a natural output of satisfying those criteria. Whether this holds across different models and different spec formats is an open question, but within this benchmark it was a reliable pattern.

The benchmark repository, all sixteen pull requests, and the scoring harness are available at github.com/brief-hq/dcbench for independent reproduction and extension.

Based on "Context-Augmented Code Generation: How Product Context Improves AI Coding Agent Decision Compliance by 49%," a controlled benchmark by Drew Dillon and Kasyap Varanasi at Brief. Read the full paper →

But as teams start building systems where agents need to coordinate with other agents, MCP's limitations become apparent. That's what ACP (Agent Communication Protocol) addresses, and the architectural difference changes how you build.

What MCP Actually Does

MCP operates on a client-server model. The AI model is the client. MCP servers expose three primitive types: tools (functions to call), resources (data to read), and prompts (templated instructions). When a model needs something, it reaches out synchronously to a server, gets a response, and incorporates it into its reasoning.

This works well when the intelligence lives in one place. The model thinks, decides what it needs, fetches it, and keeps thinking. Context is centralized. Control is singular. There's one agent, and it has access to many tools.

The limitation shows up when you want multiple agents working together. MCP doesn't have a concept of an agent delegating to another agent. You can wire up a tool that internally calls another model, but that's an implementation hack, not a protocol feature. The orchestration logic, error handling, routing, and context passing all fall on you to build from scratch. Every team reinvents it differently, and most get it wrong the first few times.

What ACP Actually Does

ACP, developed through the BeeAI project, treats agents as first-class citizens in a network. Where MCP says "here are tools a model can call," ACP says "here are agents that can communicate with each other."

Technically, ACP is REST-based. No new transport layer to learn, just HTTP. Agents expose a standardized interface. Communication supports streaming via Server-Sent Events (SSE), so agents can send partial results while still working instead of blocking the caller. Messages are multimodal by default: text, files, and structured data travel together.

The most consequential feature is async-first design. An orchestrator can hand a task to a specialist agent and move on. When the specialist finishes (or has an intermediate update), it pushes a response. This isn't just a performance optimization. It's what makes long-running, parallel, multi-agent workflows actually work instead of timing out or blocking.

ACP also defines agent discovery. Agents register themselves with metadata: what they do, what inputs they accept, what outputs they produce. Orchestrators look up agents dynamically instead of hardcoding them. Your agent network becomes something you can compose and reconfigure at runtime.

Applying It in Practice

The practical mental model shift is this: with MCP, you design around a central intelligence with peripheral tools. With ACP, you design around a network of specialized agents, each capable of reasoning, with an orchestrator handling routing and coordination.

A concrete example: say you're building a workflow that takes a customer support ticket, researches the account history, checks contract terms, and drafts a response. With MCP and a single model, that model handles everything sequentially, accumulating context as it goes. With ACP, you can have a specialized account-history agent, a contract-interpretation agent, and a response-drafting agent, all invoked by an orchestrator and running in parallel where their inputs allow it. The orchestrator synthesizes their outputs.

Why does this matter? Specialists outperform generalists on narrow tasks. Parallel execution beats sequential. And each agent can be updated, replaced, or scaled independently. Change the contract-interpretation agent without touching the rest of the system.

The setup looks like this in practice:

1. Define your agents as ACP-compliant services. Each one has a REST endpoint, handles a defined input schema, and returns a structured output. If your agent does work that takes time, it uses SSE to stream progress.
2. Register agents in a registry. This makes them discoverable to orchestrators and to each other. Tags and metadata let an orchestrator find the right specialist without hardcoded routing logic.
3. Build an orchestrator that speaks ACP. The orchestrator receives a task, queries the registry for relevant agents, fans out work, and assembles results. The orchestrator itself is an ACP agent, so it can be composed into higher-level workflows.
4. Handle context explicitly. This is where most implementations run into friction. When you hand a task from one agent to another, the receiving agent needs enough context to do its job without re-deriving everything from scratch. The message envelope carries this, but you need to be deliberate about what you include.

What It Unlocks

Three things open up when you adopt ACP as your agent communication layer.

Genuine specialization. You can make one agent excellent at one task without affecting anything else. A legal-reasoning agent tuned on contract language. A code-review agent trained on your internal standards. These exist as independent services that any workflow can call.

Composable pipelines. Complex workflows stop being monolithic prompts and become networks of agents with defined interfaces. Adding a new step means registering a new agent and updating the orchestrator's routing logic, not rewriting a giant system prompt.

Context as a first-class concern. When a task crosses an agent boundary, context needs to travel with it. This is the hardest part. Agents don't share memory; each one starts cold. The quality of your context-passing architecture determines whether your agent network behaves like a coherent system or a collection of isolated components that occasionally talk past each other.

This is what makes shared context infrastructure critical at the ACP layer. An agent network that maintains relevant context across boundaries, without bloating every message payload, is what separates agent systems that work in demos from agent systems that work in production.

MCP gave the model a way to reach out and grab things. ACP gives agents a way to work together. The latter is the architecture that scales.

Further Reading

• ACP GitHub Repository - The spec, SDKs, and reference implementations
• What is Agent Communication Protocol? | IBM - Explainer from the team that built it
• A Survey of Agent Interoperability Protocols | arXiv - Academic comparison of MCP, ACP, A2A, and ANP
• ACP Short Course | DeepLearning.AI - Free course from IBM and BeeAI

Brief is building the context layer for multi-agent systems. With brief ask, coding agents consult product context before they build, so the orchestrator doesn't have to stuff every message with background. When your agents need shared memory without payload bloat, that's the problem we're solving.

The numbers match what you'd expect:

• 14% of workers using AI report brain fry
• Those affected show 33% more decision fatigue, that 4pm feeling where you can't decide what to have for dinner, except it hits at 11am
• 39% more major errors at work
• 34% of brain-fried workers actively intend to quit (vs. 25% of others)
• Productivity gains flatline after 3 simultaneous AI tools

The pattern is clear: AI reduces burnout when it replaces repetitive tasks. AI causes exhaustion when it requires intense oversight. The exhaustion comes from reviewing AI output at the wrong level of abstraction.

The Code Review Trap

When an AI coding assistant generates 200 lines of code, what actually happens?

You open a diff. Scan every line. Try to reconstruct the intent behind each decision. Check it against business requirements you're holding in your head. Wonder if the agent understood the constraint about not breaking the billing API. Find a suspicious pattern on line 147. Trace it back through three files.

You're reverse-engineering decisions from syntax. That's exhausting. Exactly the kind of intense, attention-draining oversight that causes brain fry.

The senior engineering manager in the study nailed it:

"I was working harder to manage the tools than to actually solve the problem."

The Fix: Review Decisions, Not Code

The study found that teams who organize AI into their workflows, rather than treating it as individual tools, have less cognitive strain. The key insight is about where human attention gets spent.

Two ways to catch an AI agent's mistake:

The brain fry way: Read 200 lines of generated code. Find the 3 lines where it chose SAML instead of OAuth. Figure out why. Rewrite. Re-review.

The conversation way: Tell the agent "we use OAuth for all third-party auth. The decision is documented here." The agent gets it right the first time. Or if it doesn't, you say "no, OAuth" and it fixes itself.

Decision-level oversight prevents brain fry. Syntax-level oversight causes it.

The Missing Layer: Context Before Code

The researchers recommend redesigning how teams work with AI. Makes sense. But there's a practical problem they don't address:

AI agents can't make good decisions if they don't have business context.

Your agent doesn't know you chose OAuth over SAML. It doesn't know the billing API is untouchable until Q3. It doesn't know the pricing model changed last Tuesday. So it guesses. And you burn cognitive cycles catching those guesses.

But the problem goes deeper than technical decisions. Every feature request your agent touches sits inside a web of prioritization questions that humans answer instinctively:

• Can we solve this with an existing feature?
• Do we already have something for this in the pipeline?
• Is this hard to build and maintain for our team specifically?
• Is the requestor a user persona we prioritize?
• Do they work for a major customer or a critical lead?
• Does this enhance our competitive positioning?
• Does it fit our near-term goals?
• What strategic questions do we need to answer before taking this on?

When a senior PM or tech lead evaluates a feature request, they're running through this entire stack, often unconsciously. When your agent evaluates it, it has none of this context. So it builds the thing literally as specified, even when a two-minute conversation would have surfaced that the feature already exists, the customer isn't a priority, or the whole approach conflicts with Q2 goals.

That's where the real brain fry comes from. You're not just catching syntax errors. You're catching prioritization errors that the agent had no way to avoid.

A Brief customer put it this way:

"The new hotness right now in AI is how you can create more code with fewer developers. But how are you going to keep your agents on track? The models are getting a lot better, but you still have to be able to keep them on track."

We hit this building Brief. Early on, our coding agent had an obsession with dashboards. Tell it we're building a B2B SaaS app and the first thing it would do is scaffold a generic dashboard component. No consideration for what the product actually did. Pattern-matching on "B2B SaaS = dashboard" with zero understanding of our users or priorities.

Once we fed it Brief's product context, what we were building and why, it stopped suggesting dashboards. The agent finally had enough information to make decisions that aligned with our actual strategy. That's a 30-second context correction, not a 30-minute code review.

This is why we built Brief. Brief captures product decisions, business constraints, and strategic context from tools you're already using, like Slack, Notion, Linear, and Jira, and makes them accessible to AI coding assistants like Cursor, Claude Code, and Windsurf.

Brief can now traverse your entire prioritization process. When your agent encounters a feature request, it can check whether you've already solved it another way, whether the requestor is a priority persona, whether the work fits your near-term roadmap. The agent gets the same context a senior PM would have, before it writes a single line of code.

Brief runs in the background. No new workflows, no extra tabs to manage. Your agents just start making better decisions.

Try Brief

Three Ways to Avoid AI Brain Fry

1. Review decisions, not diffs. Stop scanning every line. Ask: Did it make the right architectural choice? Did it respect the constraints? If yes, the syntax is a detail. If no, correct the decision.
2. Front-load context. The study found that teams with organized AI integration had lower cognitive strain. The single highest-leverage integration is making sure your agents have business context before they start writing. Every decision they get right on the first pass is a review loop you don't have to run.
3. Make corrections conversational. When the agent makes a mistake, don't reach for the diff. Have a conversation: "This should use the existing auth service, not a new one." The agent corrects. You move on. Your brain stays intact.

The research points to the same conclusion: the future of AI-assisted work demands spending human attention where it actually matters: on decisions, not syntax.

Your brain is a finite resource. Stop burning it on code review. Have conversations with your agents instead.

At first glance, this feels like a natural extension of existing AI workflows. In practice, it introduces a new class of problems that look surprisingly familiar to anyone who has worked with distributed systems.

When AI agents begin passing work to other AI agents, context starts to degrade at every handoff. The teams that solve this early will gain a meaningful advantage in how quickly and reliably they can ship AI-assisted products.

The Rise of Multi-Agent Workflows

Early AI tooling focused on a single agent completing a single task. That model works well for things like:

• Writing a block of code
• Summarizing a document
• Generating a test case
• Drafting a product spec

But product development rarely happens in one step. Real workflows involve sequences of decisions and iterations.

As teams push AI deeper into development pipelines, a new pattern is emerging:

1. A design agent generates architecture or feature specifications
2. A code agent implements the design
3. A testing agent validates behavior and edge cases
4. A refactoring agent improves maintainability or performance

Each agent specializes in a different part of the workflow. Together, they resemble a small automated engineering team.

The moment multiple agents collaborate, the reliability of the entire system depends on how well information survives the transitions between them.

The Telephone Game Problem

Multi-agent systems often run into a dynamic that feels like a technical version of the telephone game.

Agent A receives a prompt with a detailed objective and generates an output. Agent B receives that output and uses it as input for the next step. Agent C then consumes the result from B.

At each stage:

• The original intent becomes less explicit
• Key constraints may disappear
• Assumptions get introduced without explanation
• Context gets summarized, compressed, or reinterpreted

The further the pipeline runs, the more the output reflects local reasoning inside each agent rather than the product goal that started the process.

A typical example appears in a design -> code -> test pipeline:

1. The design agent outlines a feature and includes several important product constraints.
2. The code agent implements the design but makes subtle interpretation decisions.
3. The testing agent verifies the implementation against the code rather than the original product intent.

By the end of the pipeline, everything technically works. Yet the outcome can drift from the original purpose of the feature.

No single step is necessarily wrong. The problem emerges from how context erodes between steps.

Where Product Intent Gets Lost

Consider a realistic multi-agent development flow.

Step 1: Design Agent

A design agent produces an architecture proposal for a new feature:

• Introduces a new API endpoint
• Suggests database schema changes
• Includes assumptions about expected traffic patterns

The output is comprehensive, but it also embeds reasoning about tradeoffs and constraints.

Step 2: Code Agent

A code agent receives the design spec and generates the implementation. During this step, several things happen:

• Ambiguous sections get interpreted
• Edge cases may be simplified
• Certain constraints may be ignored if they are not explicit

The code compiles and the structure looks correct. The reasoning behind the design decisions is already partially diluted.

Step 3: Testing Agent

The testing agent now creates tests based on the code implementation.

Tests verify that the code behaves consistently. They rarely evaluate whether the code still reflects the original architectural decisions made earlier.

The pipeline finishes successfully, yet the system might violate the performance or product assumptions embedded in the initial design.

What disappeared along the way was not raw information. What disappeared was decision context.

Why Shared Context Is Not Enough

One proposed solution is to provide agents with a shared memory or context store. While this helps, it rarely solves the deeper problem.

Large context windows allow agents to access more information. They do not guarantee that agents understand:

• Which constraints matter most
• Why certain tradeoffs were made
• Which decisions must remain consistent downstream

Raw context behaves like documentation: available, but easy to ignore or reinterpret.

What multi-agent pipelines actually require is shared decision infrastructure.

Instead of merely passing artifacts between agents, the system needs to preserve structured information about:

• The decisions that were made
• The reasoning behind them
• The constraints they impose on future steps

This allows downstream agents to operate with the same decision framework that guided earlier stages.

A Familiar Pattern From Microservices

This challenge closely mirrors an earlier shift in software architecture.

When companies moved from monolithic applications to microservices, communication between services became a primary concern. Teams needed reliable ways to manage:

• Contracts between services
• Shared schemas
• Versioning changes
• Cross-service dependencies

Without strong communication protocols, microservices quickly became fragile.

Multi-agent systems introduce a similar challenge, but instead of services communicating with services, AI agents are communicating with other AI agents.

The architecture now needs mechanisms that maintain:

• Intent across stages
• Decision traceability
• Consistent interpretation of constraints

Otherwise, each agent behaves like an isolated system optimizing for its local task.

Real-World Scenarios Where This Matters

Several common development workflows highlight how quickly agent-to-agent communication becomes critical.

Design Handoffs

A design agent proposes a feature with performance assumptions and architectural guidelines.

If the code agent treats the spec as flexible rather than authoritative, the implementation may violate those assumptions without raising any visible errors.

API Changes

An agent refactors or modifies an API to improve developer experience. Another agent later generates client integrations based on the updated API.

Without shared awareness of why the change happened, downstream agents may reintroduce the original problem or create incompatible assumptions.

Refactoring Decisions

A refactoring agent restructures code for readability or maintainability. A separate agent later generates tests or new features.

If the reasoning behind the refactor is not preserved, subsequent agents may undo the improvement or add complexity back into the system.

Each example highlights the same pattern: artifacts survive the handoff, but decisions do not.

The Competitive Advantage of Solving This Early

As AI agents become embedded deeper in engineering workflows, multi-agent pipelines will become standard infrastructure.

The teams that solve agent-to-agent communication early will gain several advantages:

• Higher reliability across automated pipelines
• Faster iteration cycles because fewer corrections are needed
• Better alignment with product intent throughout the workflow
• More scalable AI-assisted development systems

Organizations that ignore the communication layer will find that their pipelines produce inconsistent or unpredictable results.

The gap between those two groups will widen as AI systems take on more complex development responsibilities.

The Missing Layer in Multi-Agent Systems

Most discussions about AI agents focus on:

• Better prompts
• Larger models
• More tools and integrations

Those improvements are valuable, but they do not address the coordination problem that emerges when multiple agents collaborate.

Multi-agent systems need infrastructure that preserves shared decisions across the entire workflow. Without it, pipelines behave like loosely connected tasks rather than a coherent system.

As AI-assisted development matures, the reliability of agent-to-agent communication will become a defining factor in how effective these systems are.

That is why we are building Brief at briefhq.ai: the shared decision layer that keeps product intent and constraints intact across agent-to-agent handoffs, so multi-agent workflows stay dependable as they scale.

Every one of those decisions is documented somewhere. A Slack thread where someone asked "why did we build it this way?" A Notion page with the original research. A Linear comment explaining the tradeoff. A Figma file showing the rejected designs.

The knowledge exists. The problem is you can't find it when you need it.

The "product graph" concept: decisions as interconnected nodes

Think about how decisions connect to each other:

• A feature decision references customer feedback
• That feedback connects to a support ticket
• The ticket relates to a design choice
• That design was informed by user research
• The research shaped your roadmap priorities

These aren't isolated facts. They're nodes in a graph, connected by reasoning and context. When someone asks "why did we build it this way?" they're really asking you to traverse that graph backward.

Your team is already creating this graph. You're just storing it in a way that makes it impossible to query.

Your knowledge is distributed across tools

When someone on your team needs to find a past decision, they have three options:

1. Search Slack: wade through threads where the decision might have been mentioned
2. Search Notion: hope someone documented it and you're using the right keywords
3. Ask someone: interrupt whoever might remember

The information is scattered across tools. The connections exist in people's heads. And when those people leave, the connections disappear.

The search problem: keyword search vs. semantic understanding

All three search options fail for the same reason: keyword search doesn't understand meaning.

You can search for "authentication" and find 200 messages. But which one explains why you chose JWT over sessions? Which one has the security considerations? Which one documents the breaking change?

The information is there. The connections are there. But you can't traverse them.

Why documentation doesn't solve this

Every team has tried to solve this with better documentation. Write better PRDs. Keep decision logs. Maintain a wiki.

It never works. Not because teams are lazy, but because documentation requires predicting what questions people will ask later. You can't document every decision, every rationale, every connection.

And even when you do document it, documentation goes stale. The README says one thing. The Slack thread from last month says another. The actual code does something different.

The product graph isn't in your documentation. It's in the conversations where decisions actually happened.

What becomes possible when you can query your product decisions

Imagine being able to ask:

• "Why did we make the API synchronous?"
• "What customer feedback led to this feature?"
• "Who decided to deprecate this endpoint?"
• "What were the tradeoffs we considered?"

Not keyword search. Actual semantic understanding of your team's decisions and the context around them.

Here's what becomes possible:

New team members get up to speed faster. Instead of asking the same onboarding questions every team has heard 50 times, they can query the decisions directly.

You stop relitigating settled debates. When someone suggests something you already tried and rejected, you can pull up the original reasoning.

Context doesn't disappear when people leave. The decision graph persists even when the people who made those decisions move on.

You can actually learn from your decisions. Instead of wondering "what did we get wrong?" you can trace back through the graph to see which assumptions turned out to be false.

The difference between "we decided that before" and being able to find why

Most teams can answer "did we decide this?" with fuzzy memory. Someone vaguely recalls the conversation. You think it was decided in Q3, maybe.

But answering "why did we decide this?" requires traversing the graph:

• Who raised the concern?
• What data did we have?
• What alternatives did we consider?
• What constraints were we under?
• How did we think it would play out?

That's not something you can remember. It's something you need to query.

Your Graph Is Already There

You don't need to change how your team works. You don't need new tools. You don't need a complicated knowledge management system.

The product graph already exists in your Slack threads, Notion docs, Linear issues, and PRD comments.

You just need a way to query it.

And it's completely wrong.

Not broken. Wrong. It solves the problem nobody has. It optimizes for the metric that doesn't matter. It implements the requirement that was never actually what the user needed.

You have a decision bug, not a code bug. And no amount of debugging the implementation will fix it.

The wrong kind of debugging

When an agent ships the wrong thing, teams default to debugging the code. They review the implementation, check the logic, add more tests, adjust the prompt. The code gets better. The outcome stays wrong.

The real issue is upstream. Somewhere between the customer pain and the shipped feature, a critical product decision was either:

• Never made
• Made but not captured
• Captured but not accessible
• Accessible but ambiguous

The agent did exactly what any competent executor would do: it made its best guess based on incomplete information. The bug is that it had to guess at all.

What decision bugs look like

Example 1: The billing update

A SaaS company asked their agent to "add annual billing." Simple, right? The agent shipped it. Customers could now select annual plans. The code worked perfectly.

But the product team had never decided:

• Should existing monthly customers see upgrade prompts?
• What discount should annual plans get?
• Should grandfathered pricing carry over?
• What happens to prepaid credits on plan switch?
• When do billing cycles align: immediately or at renewal?

The agent made calls on all of these. None matched what the business actually needed. The result? Three weeks of rework fixing "working" code because the product decisions came after implementation.

Example 2: The notification system

A team asked their agent to "reduce notification noise." The agent analyzed usage, found that users were getting 50+ notifications per day, and implemented aggressive batching. Notifications dropped to 5 per day.

User complaints went through the roof.

The agent had optimized for volume reduction because that's what the prompt said. But the product team had never articulated:

• Which notifications are time-sensitive vs. batchable?
• What's the acceptable delay for different user roles?
• Are we solving for noise or for missing important updates?
• What does "important" mean for this product?

Perfect execution of an ambiguous decision.

Example 3: The dashboard redesign

"Make the dashboard faster" sounds clear. The agent optimized queries, added caching, lazy-loaded components. Load time dropped from 3s to 800ms. Huge win.

Except users weren't complaining about load time. They were complaining they couldn't find the data they needed. "Faster" was shorthand for "more usable." The product team knew this. The agent didn't.

The implementation was perfect. The interpretation was wrong.

Why we keep debugging code

Code bugs are visible and measurable. You can point at a stack trace, a failed test, a broken UI element. There's a clear "before and after." Fixing code shows visible progress because the artifact changes.

Decision bugs are invisible. They show up as:

• User confusion
• Support tickets asking "why does it work this way?"
• Features that technically work but nobody uses
• Rework disguised as "iteration"
• Silent abandonment

Teams don't have tools for debugging decisions. So they debug what they can measure: the code.

This is expensive.

The hidden cost

When you ship perfect code that does the wrong thing:

Time cost: The initial implementation, plus the rework, plus the time spent explaining why it needs to change.

Velocity cost: Every decision bug creates context thrash. Engineers revisit closed work. PMs re-explain requirements. Agents regenerate code.

Trust cost: After a few rounds of "it works but it's wrong," teams lose confidence in the agent. They add more review steps, write longer prompts, second-guess everything. The agent becomes a fancy autocomplete instead of a force multiplier. Watch a team go through this cycle three times and you'll see the shift: excitement turns to skepticism, velocity drops, and engineers start writing code by hand again because "it's faster than explaining it."

Opportunity cost: While you're fixing decision bugs, the features you should be building aren't getting built.

In our experience with 50+ engineering teams, most measure code quality. Almost none measure decision quality. So they keep shipping working code that misses the point.

How to debug decisions

Decision bugs have a root cause analysis, just like code bugs. The difference is where you look.

1) Trace the decision back

When a feature misses the mark, don't start with the code. Start with the decision path:

• What was the original user problem?
• Who defined the solution?
• What constraints or tradeoffs were discussed?
• What got written down?
• What did the agent see?

Usually, the break happens between "discussed" and "written down" or between "written down" and "agent sees."

2) Find the ambiguity

Most decision bugs come from underspecified requirements. Look for:

• Words with multiple interpretations ("fast," "simple," "better")
• Unstated assumptions ("obviously we'd handle that case")
• Missing edge cases
• Unclear prioritization ("all of these are important")
• Competing goals not reconciled

If you can interpret the requirement two ways, the agent definitely can.

3) Check for missing decisions

Sometimes the decision literally wasn't made. Teams say "add authentication" but haven't decided:

• What auth model? (username/password, OAuth, SSO, magic link)
• For which user types?
• What's the password policy?
• How do password resets work?
• What happens on failed login attempts?

The agent has to fill in these blanks. It will default to the simplest implementation—which is rarely what your product needs.

4) Surface competing constraints

Decision bugs often hide in unresolved tradeoffs:

• "Make it fast but add more data" (pick one)
• "Keep it simple but handle all edge cases" (these conflict)
• "Match the design system but make it feel premium" (depends on what "premium" means)

When constraints compete and nobody makes the call, the agent makes it for you. Usually wrong.

What changes when you debug decisions

One of our customers runs a B2B security product. They kept hitting the same pattern: agent would ship a feature, product team would say "that's not what we meant," engineers would rewrite it.

They started debugging decisions instead of code.

Their process now:

Before writing any code, they force themselves to answer:

• What specific user problem does this solve?
• What's the success metric?
• What are we explicitly not doing?
• What constraints apply? (performance, security, compliance, UX)
• What tone/style should this have?
• What edge cases matter?

They keep a decision log. Every time a requirement is ambiguous, they note:

• The ambiguity
• The decision they made
• Why they made it
• Who approved it

This log is available to the agent.

The result: Their rework rate dropped by 60%. Not because their agent got smarter. Because they stopped asking it to guess.

A framework for decision quality

Treat product decisions like you treat code. Apply the same rigor.

Decisions should be:

Specific: "Make it fast" → "P95 load time under 1s" Testable: Can you tell if the decision was followed? Contextual: Includes the "why" not just the "what" Accessible: The agent can find and use it Versioned: You can see when decisions change and why

When decisions meet these criteria, you ship right the first time. When they don't, you rewrite working code.

The agent forces the issue

Before AI agents, decision bugs were hidden in human communication. An engineer would build something, show it to the PM, the PM would say "not quite," they'd iterate. The ambiguity got resolved through conversation.

Agents can't do that. They execute on what's written. This makes decision bugs visible and expensive.

This is useful. It forces product teams to be explicit about what they're building and why. The teams that figure this out first will ship faster than everyone else—not because they have better models, but because they've eliminated the rework cycle. Teams that resist clarity will keep rewriting working code while their competitors ship.

How Brief handles this

We built Brief because we kept hitting this problem ourselves. Our agent would ship technically correct features that missed the product intent. We'd spend more time fixing decision bugs than code bugs.

Think of Brief as a product context layer that sits between your decisions and your agents. It captures the "why" behind your product—then surfaces it exactly when your agent needs it.

Brief surfaces the product decisions that should guide the agent before it writes code:

• User problems and priorities from past discussions
• Constraints and tradeoffs already decided
• Tone and quality bar for this feature
• Edge cases that matter for your product
• Past decisions on similar features

The agent still writes the code. But it's writing toward a clear target instead of guessing.

Learn how Brief eliminates decision bugs →

Practical steps

1) Keep a decision log

Create a simple doc or tool that captures:

• What decision was made
• Why (the constraint or tradeoff)
• Who decided
• When it can be revisited

Make this accessible to your agents.

2) Before you prompt, ask:

• Have we actually decided what "success" looks like?
• Are there multiple ways to interpret this requirement?
• What constraints apply that aren't obvious from the code?
• What edge cases matter?
• What tone/quality bar applies?

3) When rework happens, root cause it

Don't just fix the code. Ask:

• Was the decision clear?
• Was it accessible?
• Did we make the decision at all?
• What would have prevented this?

Update your process, not just the code.

4) Measure decision quality

Track:

• Features that ship without rework
• Time from decision to done
• Rework rate and root cause
• Decision debt (features built on unclear requirements)

Optimize for decision clarity, not just code velocity.

The real leverage

Code velocity is baseline now. Every team has access to fast agents. The differentiator is decision clarity—because clear decisions can't be copied by switching to a better model.

Teams that articulate clear product decisions will ship faster and with less rework. Teams that stay fuzzy will keep debugging working code.

The bug isn't in your agent's output. It's in your product input.

A diagnostic

Look at your last three rework cycles. For each one, ask:

1. Was the code technically correct?
2. If yes, what product decision was unclear?
3. Was that decision made but not captured?
4. Or never made at all?
5. If made and captured, could the agent access it?

If most of your answers point to decision quality, not code quality, you know where to focus.

What this means for your workflow

Stop treating agents like junior engineers who need detailed implementation instructions. Start treating them like senior engineers who need clear product context.

Senior engineers don't need you to specify every function. They need to understand:

• What problem we're solving
• For whom
• With what constraints
• To what quality bar

Give your agent the same. Focus your energy on decision clarity—the implementation will follow.

The compounding effect

Every clear decision makes the next feature easier. Your agent builds a model of your product priorities, your quality bar, your constraints. It makes better guesses.

Every ambiguous decision creates debt. Your agent makes the wrong call. You fix it. But the correction doesn't propagate. The next similar feature hits the same problem.

Decision clarity compounds. Decision debt compounds faster.

Start here

Pick your next feature. Before you prompt the agent:

• Write down the product decision in one sentence
• List the constraints that matter
• Note what you're explicitly not doing
• Capture the "why"
• Make it accessible

Then prompt the agent twice: once with just the feature name, once with the full decision context. Compare the outputs. The gap between them shows you exactly what decision clarity buys you.

You're not debugging code anymore. You're debugging decisions. That's the real work.

It was wrong because it copied the surface of the meeting instead of the substance. Product review was never about the performance. It was about transmitting context and judgment. I almost automated the meeting when I should have been automating the context.

What I learned from real product reviews

The best product leaders stay deeply involved in decisions long after most CEOs or execs would have delegated. Gates was infamous for "think weeks" and brutal sessions that left teams sweating but clear on what mattered. Bezos forced clarity through six-page memos and PR/FAQ drafts. At Yammer, David Sacks treated product review like a dojo. My first review with him was about a single button. He zoomed out to the history of computing, the place of the iPad, and zoomed back in to that button. The point was not the button. It was the stack of context behind it.

Those sessions were not about catching mistakes. They were about aligning on how to think. When you left, you had a mental model that guided hundreds of micro-decisions without Sacks or Bezos in the room.

Why "meeting bots" miss the point

A bot that says "this is off-brand" is a parlor trick unless it carries the why: the audience, the positioning, the constraints, the quality bar. A simulation of an exec's tone without their context is cosplay. The meeting is a proxy for context transmission. Automating the proxy and ignoring the payload recreates the bottleneck, just faster and more shallow.

The new bottleneck

Agents collapsed build time. A solo engineer can ship something meaningful in hours. The product review cycle did not shrink with it. You cannot schedule a two-hour review for every three-hour build. Hiring more PMs or writing longer specs does not fix it. The bottleneck is getting the right context into the hands of the builder and the agent at the moment of decision.

If the context stays in heads and slides, you will get 10x output of the wrong thing. The fix is not more critique; it is turning context into infrastructure.

What context actually is

• Strategy: who we serve, what we promise, what we will not do.
• Positioning and tone: how we speak to different segments.
• Non-negotiables: security, privacy, compliance, performance budgets.
• Technical choices: stack, patterns, dependencies, logging, testing.
• Design principles: component usage, spacing, motion, accessibility.
• History: what we tried, what we killed, and why.
• Current priorities: activation vs expansion, speed vs polish, revenue vs retention.

In human-led teams, this context spreads through reviews, docs, hallway chats, and scars from past incidents. With agents, those channels do not reach the code window. That is why the agent "hallucinates" choices. It fills gaps with patterns, not intent.

Context as infrastructure

Turning context into infrastructure means:

• Capturing decisions as first-class objects, not buried in meeting notes.
• Linking those decisions to work so they travel with tasks.
• Making them machine-readable so agents consume them automatically.
• Keeping them current with lightweight rituals.
• Adding drift detection so violations surface fast.
• Attaching rationale so future you knows why a constraint exists.

The goal is to let builders move without waiting for a meeting while staying inside the rails of product intent.

A simple stack for context delivery

1) Decision register

• ICP and tone rules per segment.
• Technical standards: testing, data fetching, logging, error handling.
• Performance budgets and SLOs.
• Security and privacy guardrails.
• Rollout rules and feature flag expectations.
• Design system usage rules.

2) Briefs that bind

• One page per initiative/task: user, goal, success, constraints, linked decisions, rationale.
• Short enough to read in a minute. Structured so agents can parse.

3) Ingestion and distribution

• Pull from calls, docs, code, support to propose new decisions.
• Push current decisions and briefs into agent runs automatically.

4) Feedback and drift

• When work deviates, flag it. Decide to update the decision or enforce it.
• When a fix repeats, promote it to a decision.
• Keep a log of why decisions changed.

5) Lightweight rituals

• Daily decision hygiene: add, retire, highlight changes.
• Weekly direction checks: 3–5 calls for the week, recorded as decisions.
• Monthly strategy pulse: adjust durable direction, prune decisions.

This stack replaces the need for a person to be in every review. The thinking travels without the meeting.

Levels of context to encode

• Company: mission, ICPs, pricing philosophy, market positioning.
• Product: jobs to be done, activation priorities, retention levers, quality bars.
• Domain: compliance rules, privacy stance, data residency, risk tolerance.
• Design: tone by segment, component usage, motion guidelines, accessibility rules.
• Engineering: dependency policy, testing standards, performance budgets, observability defaults.
• History: past experiments, what was killed and why, known traps.

You do not need to encode everything at once. Start with the decisions that affect current work. Expand as you see repeat misses.

What a modern product review can look like

• Before work starts: brief and decisions get pulled in. Agent drafts within rails.
• As it runs: drift alerts if it tries to add a dependency or tone outside the rules.
• Review: humans check edge cases, copy nuance, and outcomes. They do not debate frameworks because those were set.
• After ship: outcomes feed back. If users get confused, tone rules update. If performance sags, budgets tighten. Decisions evolve.

The "review" becomes a fast loop of confirm and adjust, not a gate where context finally shows up.

A story of building without the meeting

A team needed a new onboarding path for enterprise buyers. Old world: write a spec, schedule reviews, wait for sign-off. Agents would have generated a generic flow and copy. Instead they:

• Recorded decisions: enterprise tone, mandatory audit logging, P95 latency target, reuse of existing components, no new dependencies, email confirmations with legal language.
• Wrote a brief with the user, goal, and success metric.
• Fed decisions and brief to the agent. First draft respected tone, logging, and performance patterns. Review focused on minor copy and edge cases.
• Post-ship, support noted confusion on one step. They updated the copy rule and added a decision about ordering fields for clarity. Future work inherited it.

No meeting theater. The context was live, structured, and available at generation and review.

Why this beats more documentation

Documentation is necessary. It is also brittle and slow. Context infrastructure differs because:

• It is structured: Decisions have fields and values, not paragraphs.
• It is live: Changes propagate to agents and humans immediately.
• It is scoped: Only the relevant decisions attach to a task.
• It is enforced: Drift alerts when work violates it.
• It is compact: You do not need to read a wiki to start.

Docs explain. Context infrastructure guides.

Anti-patterns to avoid

• Meeting replicas: AI that mimics critique without providing the underlying constraints.
• Giant prompt templates: walls of text pasted into every request that nobody maintains.
• Stale decisions: rules that do not update, so people ignore them.
• Hidden rationale: decisions with no "why," forcing re-litigation later.
• Process bloat: adding ceremonies instead of making context easy to access.

Metrics that show context is working

• Time from insight to updated decision.
• Decision adoption rate: tasks that link to current decisions.
• Drift events per week and time to resolution.
• Rework hours attributed to missing or stale context.
• Cycle time with and without agent context injection.
• Support tickets tied to tone, compliance, or reliability misses.

If these move in the right direction, you are replacing meetings with context that sticks.

Signals you are getting it right

• Agents stop introducing random dependencies and tone mismatches.
• Rework drops because constraints are known upfront.
• PMs and leads spend less time repeating the same rationale.
• Drift alerts catch violations early.
• New hires ramp faster because the decision set gives them the mental model.
• Reviews focus on outcomes and edge cases, not relitigating standards.

Signals you are stuck in meeting land

• Every meaningful change waits for review because "that is where the context lives."
• Agents ship features that look polished but miss compliance, tone, or performance.
• The same debates repeat because the rationale is trapped in someone's head.
• Prompts grow longer because you are compensating for missing structure.
• Team calendars are full of reviews that mostly restate standards instead of improving the product.

Stakeholders without the theater

Execs still need confidence that quality, risk, and strategy are being upheld. Context infrastructure gives them:

• A live decision register they can inspect.
• Drift reports that show where standards were challenged and resolved.
• Briefs that summarize intent and constraints without decks.
• Metrics on rework and adherence.

They get visibility without becoming a bottleneck.

Risks to watch

• Overfitting decisions: locking rules too tightly and blocking healthy experimentation. Keep decisions small and revisable.
• Context sprawl: too many decisions with no pruning. Run hygiene weekly.
• False sense of security: assuming decisions are being applied when they are not wired into agent runs. Automate the injection.
• Ignoring humans: context does not replace taste. Use it to augment, not to abdicate judgment.

A rollout you can start this month

Week 1: Create a decision register. Ten items: tone, ICP, dependencies, performance, security, logging, testing, rollout rules, design system usage, analytics.

Week 2: Add briefs for current initiatives. Keep them to one page. Link decisions.

Week 3: Pipe decisions and briefs into agent runs automatically. Stop manual pasting.

Week 4: Add drift alerts. When an agent or PR violates a decision, flag it.

Week 5: Hold a short decision hygiene meeting daily. Add new decisions, retire stale ones.

Week 6: Review metrics: rework, drift events, prompt size, cycle time. Tune decisions and briefs.

None of this requires a new offsite. It requires treating context as a product surface.

What almost building the wrong thing taught me

The product review bot idea was appealing because it mirrored something familiar. It also would have kept the bottleneck in place. The value of those legendary reviews was not the sparring. It was the transfer of judgment. Judgment comes from context. Context can be captured, structured, and distributed. When you do that, you do not need a simulated panel. You need a reliable way to put the CEO's thinking, the design lead's taste, and the engineering guardrails into the system your agents and engineers use every day.

That is why Brief is context infrastructure, not a meeting bot.

The structural trap

No two product orgs run the same process. Even within one company, a growth squad and a platform team will move differently. A rigid tool tries to encode a single workflow and inevitably becomes either:

• Too opinionated to fit real work.
• So flexible it devolves into a spreadsheet with UI chrome.

So teams stuff the tool with tickets and roadmaps, then do the real thinking in meetings, docs, Slack, and their heads. The tool becomes a ledger, not a decision system.

How tools got here

Software made project management easy to codify: columns, statuses, checklists, burndowns. That is the how. The why—user needs, bets, tradeoffs, tone, risk posture—lived in scattered places:

• Sales calls and Gong recordings.
• Research notes and Miro boards.
• Strategy memos and pitch decks.
• Slack threads and email chains.
• Tribal knowledge from people who have seen this movie before.

PM tools kept trying to pull the how into a single view. They never pulled the why. Without the why, the tool cannot guide judgment. It just tracks tasks.

What the role actually is

If you boil product work down, it looks like this:

1. Seek out and synthesize information.
2. Refine an idea and decide what matters.
3. Execute with a team.
4. Learn if it worked; adjust or kill.

Step 2 is the core. It lives on context and judgment. Most tools barely touch it. They log what you decided, not how you got there or what constraints should guide the next decision.

Why "workflow-first" fails PMs

• Process mismatch: tools enforce one way to manage work. Teams spend hours shoehorning their reality into templates.
• Context loss: the tool does not hold the customer nuance, quality bars, or tradeoffs that shape good calls. Tickets become placeholders.
• Decision amnesia: why something was chosen gets buried in comments. Six months later, nobody remembers the rationale.
• Misaligned incentives: teams optimize for moving tickets, not shipping outcomes with the right quality and tone.
• Second systems: since the tool does not hold the why, teams build parallel systems in docs, Notion, or slide decks. Duplication and drift follow.

The universal layer PM tools missed

Across industries and stages, the specific processes differ, but the decision patterns rhyme:

• Who is the user and buyer?
• What job are we solving and in what order?
• What tone fits the audience?
• What quality bar applies for this release?
• What constraints (performance, compliance, privacy) are fixed?
• What do we measure to know it worked?
• What did we try before and why did we keep or kill it?

These are decisions, not tasks. They are reusable. They should travel with work and guide agents and humans. Traditional tools left them in scattered notes.

Why this matters more with agents

AI coding agents amplify the gap. They will build whatever is described. If the why and the constraints are missing, they build generic solutions fast. Rework explodes. PM tools that only store tickets cannot feed agents the decisions they need. The result is 10x execution on half-baked direction.

What a PM tool would need to avoid sucking

• A decision register: explicit, versioned choices about ICP, tone, dependencies, performance budgets, rollout rules, security posture, pricing principles.
• Structured briefs: one-page artifacts per initiative and task with user, goal, success, constraints, linked decisions, and rationale.
• Context ingestion: ability to pull from calls, docs, code, support, analytics to propose new decisions or highlight conflicts.
• Agent-readable outputs: context in formats agents can consume automatically. No copy-paste walls of text.
• Drift detection: alerts when work (agent or human) violates decisions or when decisions conflict.
• Feedback loops: edits and outcomes feed back into the decision set. The why evolves, not just the task list.
• Lightweight rituals: daily decision hygiene, weekly direction checks, monthly strategy pulses. The tool should support them without ceremony.

This is product management as decision infrastructure, not task plumbing.

A few examples of the gap

Tone and audience: A legal tech product needs sober copy. The PM tool tracks tasks. The why behind tone lives in a brand doc nobody reads. An agent ships playful modals. Support volume spikes.

Dependencies and patterns: The team standardizes on Jest and React Query. The PM tool has no field for decisions. Agents introduce Vitest and Axios. The build fragments.

Performance and reliability: The API must meet P95 latency of 300ms. The PM tool holds stories about features, not budgets. Agents add features that blow the budget. SRE finds out in prod.

Rollout rules: Enterprise features must be behind flags with audit logging. The tool tracks "Build feature X" and "Add flag." It does not enforce the rule. Agents skip logging. Compliance risk appears later.

All of these are decisions that should sit next to the work. They rarely do.

Why now

Three converging shifts make a decision-first approach feasible:

• AI can read and synthesize across sources. The cost of pulling context together dropped.
• Agents need structured input. A decision register gives them rails.
• Teams move faster. The penalty for missing context is higher because rework comes faster too.

Ten years ago, building a decision-aware PM tool would have meant armies of humans tagging data. Today, models can propose decisions, spot conflicts, and surface what matters. The human keeps control of judgment.

What this looks like in practice

• You finish a customer call. Instead of a wall of notes, you record three decisions: "Enterprise tone only," "Billing emails must include audit trail," "Activation is the north star this month." The tool updates the register. Agents consume it automatically.
• A new feature brief links to decisions: tone, logging, performance, dependencies, rollout rules. The agent drafts code within those constraints. Review focuses on edge cases, not framework choice.
• An agent suggests adding a new HTTP client. The tool flags a decision violation. You approve or reject. The register updates if you approve.
• Post-ship, you note that users were confused by copy. Tone rules update. Future features inherit the fix.

The PM tool stops being a graveyard of tickets. It becomes the system of record for decisions and context.

How to evaluate PM tools now

• Do they store decisions as first-class objects?
• Can they ingest context from calls, docs, code, and support?
• Can agents consume the data without manual copy-paste?
• Do they help you spot drift from standards?
• Do they keep rationale accessible months later?
• Do they reduce meeting load by making context available by default?

If the answer is no, you are buying another workflow tracker.

A short playbook if you are stuck with legacy tools

• Create a decision register outside the tool. Keep it in JSON or plain text. Link to it from tickets.
• Add a brief template to your current system. One page: user, goal, success, constraints, decisions, rationale.
• Script context export to agents. Do not rely on humans to paste.
• Track drift manually: note when work violates decisions; fix the source.
• Run a weekly direction check and publish decisions. Treat the tool as a delivery channel, not the source of truth.

It is a stopgap, but it reduces rework while you wait for better tools.

Anti-patterns in PM tooling

• Template overload: dozens of fields nobody fills.
• Process rigidity: forcing one roadmap format on every team.
• Everything-in-one-place claims that ignore how humans actually talk and decide.
• AI features that summarize tickets but never update decisions or constraints.
• Data hoarding: locking context in a tool without open outputs for agents and other systems.

A different bar

The bar for a PM tool should be: does it improve product judgment and reduce rework? Task completeness does not matter if the wrong thing shipped or the right thing shipped without the right tone, performance, or compliance. Decision infrastructure is how you raise that bar.

Signals a decision-first approach is working

• Rework drops because context arrives before build.
• Agents stop introducing random dependencies and patterns.
• PMs spend less time re-explaining rationale.
• Drift events decline; decisions get updated instead of ignored.
• Stakeholders learn the why from the tool, not just the what.
• Meetings shrink because context is already shared.

Signals you are stuck in old patterns

• Tickets describe tasks with no linked decisions.
• Agents and engineers copy-paste walls of text into prompts.
• Tone and compliance issues recur in every release.
• The "why" for a feature lives in someone's head or a deck from last quarter.
• Your tool usage is mostly status updates and burndowns.

How Brief fits

We built Brief around decisions and context because the old tooling patterns could not keep up with agent speed. It ingests calls, docs, code, tickets. It proposes decisions, lets you accept or reject, and feeds those to agents. It flags drift. It keeps rationale attached. It does not tell you how to run standups. It gives you the why on tap.

Coding agents, remote engineers, design partners, and execs all benefit because the same decision set guides their work. That is the difference between another PM surface and a strategic partner.

Stage-specific needs (and how tools miss)

Early stage: decisions change weekly. You need fast capture, not heavy process. Legacy tools demand hierarchies and projects before you have product-market fit. A decision-first system adapts as you learn.

Growth stage: you need consistency and speed. Tools that cannot enforce or surface decisions let teams drift: new dependencies, mixed tone, conflicting metrics.

Enterprise: compliance, audit, and change management matter. Traditional PM tools track approvals but rarely expose the underlying rationale or constraints to agents. A decision register with auditability serves both speed and governance.

A story of why workflow-only fails

A mid-market SaaS team standardized on Jest, React Query, and strict tone rules for regulated buyers. Their PM tool tracked epics and tickets. None of those standards lived there. Engineers prompted agents with whatever was in the ticket description. Within two sprints, the codebase had Vitest in one feature, Axios in another, playful copy in an enterprise flow, and missing audit logs on a billing change. QA caught some issues. Others escaped. Rework ballooned.

They added a simple decision register and linked it in every task. Agents consumed it automatically. Dependency creep stopped. Tone issues dropped. Audit logging became default. The tool did not change; the context did. That is what a PM tool should have done natively.

How to roll this mindset into your team

Week 1: Identify the five to ten decisions that matter most right now (tone, ICP, dependencies, performance, security, rollout rules). Write them down. Share with everyone.

Week 2: Add a one-page brief template to your current system. Require it for new initiatives. Link decisions.

Week 3: Automate passing decisions and briefs to agents. Stop trusting manual copy-paste.

Week 4: Start logging drift and rework causes. Summarize weekly.

Week 5: Prune and update decisions. Retire stale ones. Highlight new ones to the team.

Week 6: Evaluate whether your current PM tool helps or hinders this flow. If it hides decisions, work around it or replace it.

The future bar for PM tools

In a world where agents and small teams ship features in hours, tools that only track work are table stakes. The bar moves to:

• How quickly can we surface the right context to every actor (human or agent)?
• How reliably can we keep decisions current and visible?
• How fast can we spot and correct drift?
• How little ceremony can we get away with while keeping alignment?

Meet that bar and PM tools stop sucking. They become infrastructure for product judgment.

When I started coding again in January, something flipped. Agents handled the linting, testing, and pixel nudges. The part I hated was covered. Shipping became fun again because the last 20% was finally tractable.

We got Brief from idea to revenue fast because the agent took care of the mechanical finish while I focused on product judgment. The 80% complaint people repeat misses the real shift.

What the 80% complaint gets wrong

The line shows up in every AI thread: "These tools only get you to 80%." The implication is that the last 20% is some mystical human craft that agents will never touch.

Reality is different. The last 20% is mostly:

• Edge cases and error handling.
• Tests that prove it works.
• Accessibility and internationalization.
• Performance budgets and observability.
• Copy and tone that fit the audience.
• Integration with billing, auth, data models, and analytics.

Agents can help with most of this when they have context. What they cannot do is invent product judgment. That was never in the 20%. That was the job all along.

Why there are so many 80% demos

Two shifts collided:

• Build cost collapsed. A solo builder with an agent can ship a working prototype in a weekend.
• Distribution got easier. Every demo lands on X, LinkedIn, Reddit.

So we see an explosion of near-finished things. In the old world, those prototypes would have taken months or never existed. Now they exist and circulate. That abundance is healthy. It surfaces ideas, forces incumbents to move, and trains users to expect faster iteration.

The complaint focuses on the visible unfinished layer. It ignores the value of having ten attempts instead of none.

The real bottleneck is product sense

Building something interesting is easy now. Building something users keep is not. The hard parts:

• Picking a specific user and job.
• Deciding what "done" means for that user.
• Sequencing scope so value shows up early.
• Holding a consistent tone and UX for that audience.
• Making tradeoffs on performance, privacy, and reliability.

That is product sense. Agents do not bring it. Humans do. When product sense is weak, you get endless 80% artifacts. When it is strong, agents accelerate you to 100% faster.

A simple map of the "last 20%"

Think of the last 20% as four categories:

1) Correctness and safety

• Tests (unit, integration, smoke) that assert the behavior you promised.
• Error handling that does not leak data or trap users.
• Auth and permissions wired end to end.
• Data validation and migration safety.

2) Experience and clarity

• Copy that matches the buyer and user.
• Accessibility basics: focus states, semantics, keyboard paths, contrast.
• Empty states, loading states, retry paths.
• Onboarding cues and inline guidance.

3) Performance and reliability

• Latency budgets enforced.
• Logging, tracing, metrics hooked up.
• Capacity and timeout settings set to sane defaults.
• Backoffs and retries for external calls.

4) Fit and integration

• Analytics events mapped to your source of truth.
• Billing, entitlements, and limits enforced.
• Feature flags for safe rollout.
• Data shape consistency with the rest of your system.

Agents can draft most of this if you tell them the constraints. They fail when you do not.

Stage matters

0–1: The last 20% is about trust. Users need to see that the product does what it says, does not lose data, and speaks their language. You can tolerate scrappy performance as long as clarity and correctness are there.

1–10: The last 20% shifts to scale and reliability. You need tracing, proper retries, pagination, and budgets. The agent needs those constraints or it will keep optimizing for first-pass speed.

10+: The last 20% is about efficiency and consistency. Cost controls, dependency hygiene, and long-term maintainability matter. If you do not encode those constraints, agents will happily introduce bloat.

Knowing your stage tells you which constraints to feed the agent and which to relax.

Why context is the difference between 80% and 100%

Give an agent a vague prompt and you get a demo. Give it the constraints above and you get something closer to shippable. The missing ingredient is not model quality. It is context:

• Who is the user and what tone do they expect?
• What performance budget applies?
• What logging and metrics are required?
• What auth model is in play?
• What dependencies are allowed?
• What decisions have already been made about patterns?

When that context is structured and available, the agent fills in the "last 20%" with less fuss. When it is missing, you get generic scaffolding.

Abundance is not a defect

People treat the wave of unfinished demos as waste. It is the opposite. More attempts mean:

• More ideas surface.
• More patterns get tested.
• More pressure on incumbents.
• Lower bar for experimentation.

Yes, most attempts will not endure. That was true before. The difference is speed. Speed plus product judgment is lethal. Speed without judgment looks like 80% forever.

A story from the field

We built Brief fast by leaning on agents for the finish work:

• Early onboarding flows: agent drafted UI and backend. We provided tone rules, ICP, and logging requirements. First pass shipped with minimal edits.
• Billing updates: agent generated the form and API changes. We added constraints: audit log every change, no new dependencies, server-side role checks. It hit prod after small copy edits.
• Docs and support: agent generated drafts tied to product decisions. We edited for nuance.

The constant was context. We kept a decision register. We wrote short briefs. We fed them to the agent. The "last 20%" shrank because the agent was not guessing.

How to get past 80% with agents

1) Write a tight brief

• User and job to be done.
• Success criteria and guardrails.
• Tone rules and audience.
• Dependencies allowed and banned.
• Performance, logging, and testing expectations.

2) Maintain a decision register

• Stack defaults (testing, data fetching, UI libs).
• Security and privacy rules.
• Tone and brand voice.
• Rollout rules and feature flag patterns.
• Performance budgets and error handling norms.

3) Bake quality into the prompt

• Ask for tests and specify frameworks.
• Call out auth and permissions.
• Ask for logging and metrics with your conventions.
• Ask for empty/loading/error states.
• Remind it of performance targets.

4) Review with a checklist

• Does it honor decisions?
• Are auth, logging, and analytics present?
• Are error and empty states handled?
• Does the copy match the audience?
• Does it meet latency and reliability constraints?

5) Close the loop

• When you edit, note why: tone, dependency choice, missing logging, performance.
• If it is a recurring fix, add it to the decision register.
• Keep drift counts: how often the agent violates a decision.

What to measure

• Rework rate due to missing context.
• Time from brief to "ready for review."
• Number of decision violations per task.
• Test coverage added per feature.
• Latency and error rates post-ship.
• Support tickets tied to tone or UX misses.

These show whether you are actually moving from 80 to 100, not just shipping faster.

Teaching a team to think this way

• Start every task with a brief and linked decisions. Make it muscle memory.
• Run short post-ship reviews on rework. Was it missing context or changing intent?
• Celebrate clean first passes that honored constraints, not just speed.
• Rotate ownership of the decision register so it stays current.
• Keep prompts small and focused. Trim anything the agent cannot act on.

Teams learn fast when the process is light and the feedback is immediate.

Anti-patterns that keep you at 80%

• Vague prompts: "Build a dashboard" with no user, data, or success definition.
• Decision sprawl: no single source of truth for stack and patterns, so every task invents new ones.
• Ignoring non-functional requirements: no mention of performance, logging, accessibility.
• Silent rewrites: humans fix issues without updating decisions; agent repeats mistakes.
• Over-stuffing prompts: pasting entire specs instead of concise constraints; agent drowns in noise.

The market shift hiding under the complaint

The 80% line is often fear. Fear that if anyone can ship a prototype, the bar drops. The bar is actually rising. Users expect polish sooner. They expect reliability from day one. The teams that will win pair agent speed with ruthless focus on product sense and finish.

Ten years ago, a decent MVP took months. Now it takes days. The differentiator is not whether you can ship. It is whether you ship what matters, with the right quality, before someone else does.

A short checklist for your next feature

• User and job defined.
• Success and quality bar stated.
• Tone, audience, and brand rules attached.
• Dependencies and patterns set.
• Auth, logging, metrics, and performance budgets included.
• Tests requested.
• Feature flagged and rollout plan clear.
• Decisions linked in the brief.
• Review against the checklist. Fix. Update decisions.

Do this and the "last 20%" stops being a myth. It becomes a repeatable path the agent can follow.

Another concrete example

Task: add "Export Transactions" for finance admins.

Prompt without context: "Add CSV export for transactions." The agent builds a button, dumps CSV with whatever columns it finds, client-side only, no pagination, no auth checks. Looks fine in dev. In prod, it times out and leaks data to non-admins.

Prompt with context:

• User: finance admin at mid-market customer.
• Constraints: server-side export, paginated, P95 under 1s, include audit log entries, role-checked on API, no new dependencies, logging to existing telemetry.
• Tone: concise, professional. No playful copy. Use existing button styles.
• Tests: integration test for role check, unit test for CSV shape.
• Decisions: use existing REST client, React Query, Jest, and logging pattern.

Agent output: server route with role check, paginated query, CSV stream, logs, tests, reuse of existing components, neutral copy. Review focuses on column order and a couple of edge cases. Ship.

The gap between those outputs is context, not magic.

The 80% complaint is backwards

Agents are not failing to finish. They are finishing what you asked for, with the context you provided. When that context is thin, you get a demo. When it is rich, you get a feature. The real gap is product judgment and context delivery, not some magical human-only finishing school.

Use agents to generate abundance. Use product sense to aim it. Use structured context to close the last 20%. Then the complaint flips: the last 20% becomes the part that finally feels possible.

I've run engineering, product, and design teams from zero to 150 people. The trend is clear: small teams want to move like special forces, not relay teams. The handoffs that used to separate roles become liabilities when agents can ship code in hours. The product developer role absorbs those handoffs.

Who they are

The product developer owns 0–1 and often 1–N. Not just prototypes, but production builds that hold up under real traffic. They have enough depth to design a system, build it, and ship it with the right user experience. They pull in specialists when scale, security, or brand polish demands it.

Today, they show up as technical PMs, product-minded engineers, and designers who code. They already straddle disciplines. AI accelerates them. Cursor and Claude let them scaffold a backend in a morning. Figma-to-code tools get them a starting point for UI. Agents wire integrations. The constraint is no longer "can they code fast enough?" It is "do they have the judgment to build the right thing end-to-end?"

Why this is happening now

• Agent speed: Coding agents collapse the time from idea to working software. The bottleneck shifts to decision quality and product sense.
• Tooling convergence: Frameworks, design systems, and cloud services reduce the surface area of decisions needed to ship something real.
• Team size pressure: Smaller teams are expected to produce outsized output. Hiring three roles where one product developer can lead with agents is hard to justify.
• Customer expectations: Users expect cohesive experiences. Handoffs often create seams. A single owner reduces seams.

How they work with specialists

Product developers are not lone wolves. They lead the 0–1 and early scale work, then partner:

• With infra and SRE for scale, reliability, and cost control.
• With brand and design systems for polish, accessibility, and cohesion.
• With security for threat modeling and compliance.
• With growth for pricing, packaging, and onboarding experiments.

They know enough to have an informed conversation with each specialty, and they use agents to cover ground quickly while respecting the constraints those specialists care about.

What tools they need

Assuming "the repo has all the context" does not work. Markdown is a poor collaboration surface for shared intent. Product developers need:

• Shared context that agents can read: ICP, tone, quality bars, performance budgets, compliance constraints, design tokens, component rules.
• Decision registers: clear, versioned choices about stack, dependencies, tone, rollout rules, pricing guardrails.
• Briefs that cross disciplines: user, job-to-be-done, success metrics, constraints, non-functional requirements. One page, structured.
• Agent orchestration: the ability to run multiple agents (coding, design, analysis) against the same context and have them respect the same decisions.
• Observability for agents: drift detection when an agent deviates from decisions; logging of rationale for changes.
• Fast review loops: the ability to inject feedback into agent output quickly, and to have that feedback become future constraints.

They also need the basics: strong component libraries, stable backend scaffolds, reliable CI/CD, and test coverage that agents can operate within.

The mindset shift

The product developer does not wait for a ticket. They start from a user or business goal, write a tight brief, and let agents draft. They review with product sense and engineering rigor. They decide when "good enough" ships and when to pull in a specialist.

They think in constraints: who is the user, what is the acceptable tone, what are the latency and reliability budgets, what dependencies are allowed, what compliance rules apply. They set those upfront so agents stay on rails.

They measure outcomes: activation, retention, revenue, support load. They do not optimize for velocity alone.

What this looks like day to day

• Morning: synthesize yesterday's customer calls into two decisions and a brief for an onboarding change. Agents generate UI and backend updates. The product developer edits for tone and data handling, ships to staging.
• Midday: review a specialist's suggestion for database indexing to hit P95 latency. Accept, add the constraint to the decision register so future agent tasks assume the index exists.
• Afternoon: pair with a design agent on a pricing page variant. Tie it to existing components, ensure copy matches tone rules. Ship an A/B test. Log the rationale.
• Evening: check drift alerts. An agent tried to add a new dependency for file uploads; reject and note to add an approved library decision.

The cadence is faster than traditional product-engineering cycles because the handoffs are internal to one person plus agents. The quality bar stays high because constraints and decisions are explicit.

What changes for teams

• Fewer handoffs: less time lost in translation between PM, design, and engineering.
• Clearer accountability: one owner for an initiative, supported by agents and specialists.
• Faster iteration: briefs + decisions → agent drafts → human edits → ship → measure → update decisions.
• Better coherence: tone, UX patterns, and technical choices stay aligned because a single owner holds the thread.
• More leverage from specialists: they focus on scale, polish, and risk, not on translating requirements.

Risks to watch

• Overconfidence: a product developer can ship something fast that needs more specialist input. Guardrails are needed: security reviews, performance checks, accessibility passes.
• Decision rot: if decisions are not maintained, agents drift and inconsistency creeps in.
• Burnout: carrying product, design, and engineering choices alone is heavy. The answer is shared context, not heroic effort.
• Tool sprawl: too many disconnected agents and tools create noise. Orchestration and shared context are key.

How to cultivate product developers

• Hire for product sense + technical fluency + bias to ship.
• Give them agents and structured context. Do not bury them in process.
• Pair them with specialists early to learn scale, security, and brand standards.
• Measure them on outcomes and coherence, not ticket throughput.
• Let them own 0–1s and early-stage bets. Bring in more specialization as those bets harden.

The link to product management

Engineering agents are getting attention. Design agents are emerging. Product has been underserved because every org is different. The product developer bridges that gap. They embody product judgment and translate it directly into builds with agents. They need product tooling that respects variation: decision systems, context delivery, and agent orchestration tailored to their workflow.

A short story from the field

Building Brief, I acted as the product developer with a coding agent swarm. We moved from idea to six-figure revenue in months because the loop was tight: decide, brief, generate, edit, ship, learn, update decisions. No waiting for a quarterly plan. No handing a spec to a separate team to interpret. When we needed depth, we pulled in specialists for security and infra, then codified their constraints so agents respected them.

A simple way to start

Week 1: Identify your product developers (or the people closest to it). Give them a decision register and agent access. Seed ten key decisions: stack, tone, performance, compliance, dependencies.

Week 2: Introduce briefs for active initiatives. One page. User, goal, constraints, success metric, linked decisions.

Week 3: Wire decisions and briefs into agent workflows. Stop copy-pasting context.

Week 4: Add drift detection and rework tagging. If the same issue repeats, update decisions.

Week 5: Pull in specialists to review the hottest areas: security, performance, brand. Capture their guidance as decisions.

Week 6: Measure outcome movement and coherence. Are features shipping faster? Are patterns consistent? Is rework down? Tune decisions and briefs accordingly.

Built for this future

The future belongs to builders who can carry a product end-to-end with help from agents and targeted specialists. The product developer is that builder. Give them context, decisions, and tools that keep agents aligned, and they will ship faster than any role divided by old boundaries.

Yet many teams still hinge their strategy on a QBR and an offsite. Decisions that should take an afternoon get deferred to the next planning window. By the time you ratify a plan, the market has moved and your agents have already built three versions of the thing you should have shipped last week.

What quarterly was solving

• Scarce engineering capacity: every commit was expensive, so you planned carefully.
• Slow feedback loops: user research, usability studies, and release trains took weeks.
• Heavy dependencies: infrastructure changes needed long lead times and coordination.
• Stable markets: competitors and customers moved slower, so a three month bet held up.

Those constraints justified a 90-day ritual. They do not match a world where a small team with agents ships something real in a day.

Why the cadence broke

1) Cycle time collapsed. With Cursor, Claude, and Copilot, an engineer can ship a small feature in hours. The planning cadence stayed at 90 days.

2) Competitor tempo increased. Your rivals push pricing changes, onboarding tweaks, and positioning shifts multiple times a month. Your quarterly plan gets stale before it is printed.

3) Customer expectations tightened. Switching costs dropped. One clumsy release and a buyer tries the next tool. Waiting for the quarterly prioritization meeting to adjust is too slow.

4) Context is fragmented. Research notes, sales calls, support threads, experiment results—none of it flows into a single place fast enough. So teams fall back to ceremony to "sync" every 90 days. This is the product context problem—the business knowledge that should guide decisions is scattered across dozens of tools.

The gap between how fast you can build and how fast you decide what to build widens with every agent-assisted sprint. Planning is now the bottleneck.

The cost of quarterly

• Rigid bets: you lock scope and resourcing for 12 weeks. Two weeks later, a new learning arrives and cannot be absorbed without process pain.
• Zombie projects: work continues because it was in the plan, not because it is still the best move.
• Context decay: fresh insights from calls and experiments sit in docs until the next ritual. By then, the nuance is gone.
• Thrash inside the quarter: teams quietly replan mid-quarter to react, creating shadow roadmaps and misalignment.
• PM and eng morale drag: teams know the plan is stale but feel forced to execute it. Agents ship faster, so rework increases when direction changes mid-flight.

Signals your quarter is stale

• You learn something important in week three and file it for "next quarter."
• Sales keeps creating one-off promises because roadmap updates take months.
• Support escalations get patched locally because re-prioritizing is too heavy.
• Engineers are told to "stick to the plan" while quietly reordering work to match reality.
• Agents churn out features that no longer match current positioning.

The world with agents

Agent speed makes the old cadence look absurd. You do not need a quarter to put a feature in users' hands. You need hours to days. The gating factor is not execution capacity; it is decision freshness and context distribution.

If you keep quarterly planning but add agents, you get a factory that moves at 10x building the wrong things faster. The rework cost quietly explodes.

What replaces quarterly

You still need strategy. You still need focus. But the unit of planning shifts from 90-day batches to continuous decisions with guardrails.

Anchor on durable direction: mission, ICP, core product principles, quality bars, pricing philosophy. These do not change weekly.

Make decisions small, explicit, and reversible: "We prioritize activation over expansion this month." "We will not add new dependencies unless they replace two or more packages." "We ship enterprise-facing flows with email notifications, not in-app toasts."

Update priorities continuously: take in new signals daily, adjust weekly. Use lightweight rituals to ingest fresh context and change course without a summit.

A practical operating model

Weekly direction check (30–45 minutes)

• Inputs: top customer learnings, key product metrics, support escalations, competitive moves, experiment results.
• Outputs: 3–5 direction calls for the week (e.g., "Double down on activation for Segment A," "Pause net-new growth experiments until churn issue is addressed," "Keep architectural changes to X area on hold until after conference launch.")
• Record these as decisions the agents and humans can read.

Daily 10-minute decision hygiene

• Add new decisions when they emerge: tone rules, dependency choices, quality bars, rollout guardrails.
• Retire stale decisions. Highlight changes to the team and the agents.

Rolling backlog tied to decisions

• Each task links to the decisions it relies on. If a decision changes, affected tasks are obvious.
• Agents consume the current decision set automatically. No copy-paste.

Fast escalation path

• If a critical learning arrives (customer escalates, competitor launches), adjust direction the same day. No "wait for the weekly" if the impact is clear.

Monthly strategy pulse (60–90 minutes)

• Check if the durable direction (ICP, positioning, pricing philosophy) needs an update.
• Review the past month's decisions: which ones drove impact, which ones caused thrash.
• Decide what to stop doing as much as what to start.

How to keep alignment without ceremony

• Single source of decisions: a lightweight register that holds current choices: ICP focus, tone, dependencies, rollout constraints, pricing rules, performance budgets. Agents and humans read the same source.
• Short briefs per initiative: goal, user, rationale, constraints, success criteria, linked decisions. One page max.
• Transparent drift signals: when an agent or team deviates from decisions, flag it. Resolve quickly. Update decisions or enforce them.
• Open visibility: PMs, eng, design, sales can see the current direction and the decisions. No hidden roadmaps.

Handling stakeholders without a quarterly deck

Finance and sales still need predictability. You can provide it without freezing decisions for 90 days.

• Monthly outcome targets: activation lift, churn reduction, expansion bookings. Anchor on outcomes, not fixed features.
• Capacity bands: publish expected builder capacity per month, with buffers for interrupts. Update bands when staffing or priorities change.
• Sales guardrails: a live list of promises you can make and promises you cannot. Update weekly. Tie it to decisions the agents use.
• Launch calendar: maintain a rolling 4–6 week view of likely releases. Mark confidence levels. Update weekly.
• Narrative brief: one page each month summarizing direction, key decisions, and what changed. No 60-slide deck.

This gives stakeholders clarity while keeping product flexible.

Example: shipping at agent speed without quarterly plans

Week 1: You learn activation is the bottleneck for mid-market ICP. You set a decision: prioritize activation improvements over expansion experiments this month. Agents see it. Tasks in the backlog tie to it.

Week 2: Support flags a billing error impacting churn. You add a decision: no net-new growth experiments until billing fixes ship. Backlog reorders the same day. Agents ship billing fixes with audit logging because that decision already exists.

Week 3: Competitor launches a new onboarding flow. You review it, add constraints to your own onboarding: tighten P95 latency, remove playful copy for enterprise tenants, add export parity. Agents incorporate these in new work immediately.

Week 4: Strategy pulse shows activation improved, churn stabilized. You retire the "pause growth experiments" decision. You keep the billing logging rule. You add a new focus: "Explore self-serve upgrade for SMB tier." No offsite required.

A comparison story

Old cadence: a team commits in Q1 to a Q2 release of a new onboarding wizard. In week four, user interviews reveal that the real blocker is billing transparency, not onboarding. The team keeps building the wizard because re-planning is painful. By Q2, the launch lands, but activation barely moves. Churn rises because billing issues remain. Agents shipped plenty of UI tweaks; none solved the real problem.

Continuous cadence: the same team runs weekly direction checks. The week four insight triggers a new decision: "Prioritize billing clarity over onboarding polish until churn improves." The backlog flips. Agents ship billing summaries, clearer invoices, and email receipts with audit logging by week six. Activation lifts because users see charges clearly. The onboarding wizard waits. When it ships, it reflects the new billing clarity decisions.

The difference is the cost of waiting. With agent speed, waiting 60 days to act on a learning is a self-inflicted wound.

Metrics that tell you if this is working

• Time to decision: from new signal to recorded decision.
• Decision adoption: percentage of tasks that link to and honor current decisions.
• Rework rate: how often features are rewritten due to direction changes mid-flight.
• Drift events: instances where agents propose work that violates decisions.
• Cycle time vs. value: features shipped that move the target metric vs. total shipped.
• Planning overhead: hours spent in planning vs. time saved in reduced rework.

Anti-patterns to avoid

• Rebranding quarterly as "big room planning" every six weeks. Ceremony without agility.
• Parking every new insight in a doc for "next planning." Insights expire.
• Letting agents run on stale decisions. They will optimize for old rules.
• Hoarding decisions in PM-only spaces. Agents and engineers need the same source.
• Overreacting daily. Direction changes should be meaningful, not flailing.

Tooling that helps

• Decision register the agent can read via MCP: JSON, YAML, or a simple text format with clear keys.
• Brief templates for initiatives and tasks: one page, structured, linked to decisions.
• Drift tracking: alerts when a PR or agent suggestion conflicts with a decision.
• Backlog tooling that links tasks to decisions and updates when decisions change.
• Lightweight logging of rework causes to spot patterns.

Tooling is there to reduce manual overhead. It does not replace judgment.

A simple rollout

Week 1: Create a decision register. Seed it with ten choices that matter now: ICP, tone, dependencies, performance budgets, rollout rules. Share it with the whole team.

Week 2: Add the weekly direction check. Keep it under an hour. Publish the 3–5 calls as decisions.

Week 3: Wire decisions into agent workflows. Ensure every task references relevant decisions.

Week 4: Add drift tracking and rework tagging. Summarize weekly.

Week 5: Replace the quarterly offsite with a monthly strategy pulse. Focus on what changed, what you are stopping, and what durable direction remains.

The real shift

Quarterly planning is a relic of slower cycles and scarce builders. With agents, execution capacity is abundant. The constraint is how fast you can absorb new information and adjust direction without losing alignment. Replace quarterly batches with continuous decisions anchored in durable strategy. Keep the rituals light and the context alive. That is how you move at agent speed without flying blind.

You've spent years building muscle memory for the actual work. Now you're guiding someone else through it. Imprecise, frustrating, but ultimately more impactful because you're multiplying output across a team.

Managing managers is like adding dishwashing gloves inside those oven mitts. Another layer of abstraction from the hands-on work. A whole new communication skill set.

AI coding agents added another abstraction. The meme says everyone became a manager overnight. We prompt, they execute, we guide. Partially true, but the core challenge is not the prompt. It is the communication chain that got severed.

The Fundamental Difference

There's a fundamental difference in AI coding though: the communication chain is broken.

In traditional product development, PMs communicate and seek out context. User needs, tradeoffs, why we're building something. Engineers use that context to build.

With AI coding agents, the PM does not talk to the agent. The engineer becomes the single conduit. The agent cannot raise its hand and ask about users or strategy. It executes whatever fits the prompt and the code it can see. The context that used to travel directly from PM to engineer now takes an extra hop through an interface that compresses everything into text.

So agents drift off course. They build for the wrong user. They ignore long-held decisions. Engineers get frustrated by rework. PMs feel cut out of the loop. The product quality drops while the activity level rises.

The agent is not your IC. The agent is your IC's IC. You are managing through two layers with none of the usual communication bandwidth. That is why it feels like oven mitts over dishwashing gloves.

Where the chain snaps

Three places keep showing up.

1) Context intake: PM intent is expressed to an engineer in a meeting or a doc. The engineer distills it into a prompt. Nuance drops. The agent sees only the distilled version.

2) Clarification: A human engineer would ping the PM for missing details. The agent does not. It hallucinates the missing part or picks the most common pattern in the repo. Wrong defaults ship fast.

3) Feedback: The agent does not learn from implied feedback. If the engineer quietly fixes tone or rewrites a flow, the agent never sees the correction. It repeats the mistake in the next task.

Break any one of these and the loop slows. Break all three and you are paying for speed while buying rework.

The consequences in real teams

Tone and audience drift: A fintech agent ships playful microcopy into payout flows because it saw it in a marketing component. The PM intent around trust and sobriety never reached the agent. Support tickets spike. The team rewrites copy and removes confetti from error states.

Stack drift: One task introduces Fetch with hand-rolled retries. The next introduces Axios. The next pulls in a GraphQL client because it saw the schema file. The agent optimizes locally for the prompt and code around it, not for team-level consistency. The build grows brittle and hard to maintain.

Scope inversion: A customer request for “a CSV export of invoices” turns into a whole reporting UI because the agent saw a dashboard component. Meanwhile the real need was a one-click export with the right schema and audit logging. The agent filled in the gaps with patterns, not intent.

Access control misses: A B2B team asks for “admin-only feature flags.” The agent implements toggles but forgets role checks on the API. A customer with the right URL accesses the feature. The PM assumed “admin-only” implied back-end enforcement. The agent assumed UI gating was enough.

All of this looks like edge cases until you notice the pattern. The missing factor is always context transmission and verification.

Why manager instincts fail here

Managers fix communication gaps by coaching, shadowing, and quick taps. None of that reaches the agent by default. You cannot shoulder tap the model. You cannot rely on “I’ll see it in the PR” when the agent generates the PR. You cannot wait for a weekly sync to realign because the agent has already shipped three features since then.

The usual playbook—longer specs, more acceptance criteria, more review—adds ceremony but not comprehension. Agents do not parse nuance from prose. Humans do, and they still struggle with walls of text. The engineer is forced to act as interpreter and gatekeeper, which defeats the point of the agent’s speed.

The missing piece

The missing piece is not better code generation. It is giving agents the same context that makes human engineers effective: user needs, business constraints, technical decisions, and the why behind those decisions. This is what we call product context—the business knowledge that transforms AI from a code generator into a product-aware collaborator. Then making that context available at generation time and at review time, and making sure corrections flow back into the system.

What manager of managers looks like in agent world

Your job is to set intent, boundaries, and feedback loops that survive two hops.

Intent: What problem are we solving, for whom, and why now.

Boundaries: What choices are fixed. What choices are flexible. What quality bar applies to this task.

Feedback: How the agent learns from corrections and how those corrections become constraints for the next task.

Do that well and the agent feels like a senior IC. Do it poorly and the agent feels like an eager intern who never listens.

Anti-patterns to watch

Boilerplate prompts: Copying a giant prompt template into every task. It lulls you into thinking the agent “knows” things it never reads. The context needs to be short, current, and relevant to the task.

Shadow rewriting: Engineers quietly rewrite agent output without updating the shared constraints. The agent repeats the same mistake in the next task. Rework becomes permanent.

Dependency sprawl: Agents import new libraries to solve local tasks because team standards are not enforced in context. Every feature brings a new stack fragment.

Feature factory autopilot: PMs stay out of the loop until sprint review. The agent ships fast but off-target. The team backfills context after the fact.

Prompt bloat: Engineers paste entire specs, tickets, and wikis into prompts. The agent chokes on noise and still misses the key decisions.

A playbook that rebuilds the chain

1) Make decisions first-class

• Capture them in a structured format: "We use Jest," "We never store PII in logs," "Enterprise flows use email for critical alerts," "Tone is concise and confident."
• Version them. Retire stale ones. Highlight new ones to the agent and the team.
• Feed them automatically with every agent task. No copy-paste. See the agent setup guide for how to configure this with different tools.

2) Create task-specific briefs

• One tight brief per task: goal, user, constraints, success criteria, known decisions that apply, red lines not to cross.
• Keep it short enough that a human can read in one minute and an agent can process without getting lost.
• Include rationale when a choice looks arbitrary: “Email, not in-app, because audit retention is required.”

3) Establish clarification hooks

• Give the agent a way to surface uncertainty. If a pattern deviates from decisions, the agent should ask or flag.
• For humans pairing with the agent, set a rule: if you add more than two ad hoc clarifications while editing, add them to the decision set or the brief so the next run knows them.

4) Close the feedback loop

• When you edit agent output, mark what changed and why. Was it tone, dependency choice, performance, accessibility, security, UX polish.
• Update decisions when the edit reflects a recurring pattern, not a one-off.
• Track repetition. If the agent keeps missing the same constraint, your context distribution is broken.

5) Instrument everything

• Drift events: count when the agent proposes something outside decisions.
• Rework causes: tag edits by category: context missing, decision violation, quality bar missed, ambiguity in goal.
• Time to clarity: measure from task creation to “agent has the right constraints.”
• Prompt size: watch for bloat. If briefs get long, split work or tighten decisions.

6) Keep humans in the loop without slowing them down

• PMs should see the briefs and decisions the agent uses. That visibility restores influence without calendar bloat.
• Engineers should not need to become context librarians. Automate the injection of decisions and briefs into the agent.

A concrete example: role-based access

Goal: add an “Edit Billing” screen for admins only.

Brief: who the user is (admins at enterprise customers), why it matters (billing errors cause churn), constraints (RBAC enforced server-side, no playful tone, log all changes, latency target under 300ms P95), decisions (use existing form components, use Jest, React Query, REST only, no new dependencies).

Agent run without context: builds a React form with client-side checks, uses a new HTTP client for convenience, adds a toast with a celebratory icon on success, no audit log. Looks good in a PR, fails the business intent.

Agent run with context: enforces RBAC on the API, reuses existing components, writes to the audit log, keeps tone neutral, uses existing HTTP patterns. The PR lands mostly clean. Edits focus on copy and edge cases, not on re-architecture.

The difference is not the model; it is the context and boundaries.

How to roll this out

Week 1: Build a decision register. Start with ten to twenty items that impact current work: stack choices, tone, compliance, logging, performance, dependencies. Keep it in a format agents can read.

Week 2: Create a brief template. One page, max. Fields: goal, user, rationale, constraints, success criteria, linked decisions. Use it for two active tasks. Tune it until it reads fast.

Week 3: Wire briefs and decisions into the agent workflow. Automate inclusion. Stop pasting.

Week 4: Add drift tracking and rework tagging. Make it easy to mark why you edited the agent output. Summarize weekly.

Week 5: Add a ten-minute daily decision review. Add new decisions, retire stale ones, highlight what changed.

Week 6: Give PMs and designers access to the briefs and decisions. Let them update tone, user constraints, and non-functional requirements without waiting for a sprint change.

Signals you are fixing the chain

• Agent output needs fewer rewrites for tone, dependencies, and compliance.
• Prompts get shorter because decisions carry the defaults.
• Features ship with consistent patterns across tasks.
• PMs give feedback earlier because they see what context the agent is using.
• Drift events decline week over week.
• QA finds fewer repeats of the same class of bugs.

Signals you are still broken

• Engineers keep pasting giant specs into prompts.
• The agent introduces new libraries on routine tasks.
• PMs only see work at sprint review.
• The same tone or compliance issues appear in every PR.
• Decisions live in a doc nobody updates.

The real job now

Managing an agent is not about clever prompts. It is about rebuilding a communication chain that lost a layer. The agent cannot overhear the sales call. It cannot tap the PM on the shoulder. It cannot guess which decisions are sacred. It will fill gaps with whatever patterns it sees.

You are now the manager of a manager you cannot talk to directly. Your tools are explicit decisions, tight briefs, fast feedback, and visibility. Do that and the agent becomes an extension of your product intent instead of a risk multiplier.

When people say AI has turned everyone into a manager, this is the work they are pointing at. Not status updates. Not more meetings. The work is designing the context path so the agent ships the right thing fast.

Remote work erased most of that layer. The Allen curve says communication plummets as distance grows. Microsoft researchers measured remote collaboration and saw cross-team ties fray and rich, ad hoc conversations shrink. Studies on relational communication found people felt more transactional and less connected after the abrupt shift. The evidence matches what teams felt: the casual backchannel that kept product intent aligned went quiet.

What changed day to day

• Simple clarifications turned into Slack threads, then meetings.
• A two-minute nudge became a 30-minute calendar slot.
• PMs bundled feedback into weekly reviews because interrupting felt expensive.
• Engineers optimized for uninterrupted blocks, which meant less context-sharing in flight.

The result was friction on every handoff. A story that used to get shaped in three hallway conversations now lived in a doc and a queue. By the time code shipped, the original nuance was gone. Teams compensated with ceremony: longer specs, more screenshots, Looms for every demo. Those efforts helped, but they never recreated the fast path that proximity gave.

The hidden cost showed up as rework. Tickets shipped with partial intent. UX tone mismatched the buyer. Edge cases got discovered after launch because the "oh, and make sure it works for resellers" reminder never happened. Late feedback arrived after code froze. Cycle time metrics looked fine; the real loss was in alignment and quality of the first pass.

Back in the office did not fully fix it. Hybrid days clustered collaboration, but the informal layer stayed thin. People still defaulted to async. The habit of over-structuring every interaction stuck. The shoulder tap muscle atrophied.

Then AI coding agents arrived and multiplied the speed gap. An engineer can sit with Cursor or Claude and ship a feature before lunch. The agent will happily scaffold thousands of lines based on whatever prompt it gets. If the PM context is late or compressed, the agent builds the wrong thing quickly and confidently.

Failure mode in the wild

A team building compliance workflows asked their agent to add "client notifications." The repository contained a mix of consumer-style components and enterprise pages. The agent matched the patterns it saw and produced playful in-app toasts with emoji-rich copy. The missing pieces were obvious to any PM on the account: regulated clients, audit trails, tone constraints, delivery guarantees. None of that made it into the prompt. Rework meant ripping out UI, wiring email with retention, and rewriting copy. The engineering velocity looked great until you count the do-over.

Other patterns keep repeating:

• Generic scaffolding: the agent adds dashboards, toast systems, and preference centers because the repo contains them, not because the user needs them now.
• Tone mismatch: consumer patterns leak into B2B flows. Legal tech gets smiley microcopy. Healthcare gets celebratory confetti on failure.
• Non-functional blind spots: performance budgets, logging, and audit trails vanish because the agent does not see them in the immediate prompt.
• Decision thrash: one task uses Jest, the next pulls in Vitest; one feature ships REST, the next quietly adds GraphQL because it seemed cleaner.
• Dependency creep: the agent installs new UI kits or HTTP clients because they solve the immediate task, ignoring the team's standards.

Why the usual patches fall short

• Longer specs: they age fast, they still miss the tacit "why," and agents rarely parse them end to end.
• More meetings: they slow the loop and still do not reach the agent inside the IDE.
• Looms and walkthroughs: great for demos, weak for structured, recallable decisions the agent can apply.
• Ad hoc prompting: engineers translate PM intent under time pressure, compressing nuance and omitting rationale.
• Knowledge bases: helpful for humans, but useless if the agent cannot query them in a structured way at decision time.

What fixed looks like

Context has to be accessible, structured, and alive. The modern shoulder tap is not a chat ping; it is a system that lets the agent consume constraints and intent before it generates code.

1) Structure the context the agent can read

• Product: ICP, user archetypes, tone rules, accessibility expectations, onboarding priorities, success definitions.
• Business: pricing model, regulated vs unregulated segments, SLAs, risk posture, compliance boundaries.
• Technical: stack decisions, API contracts, performance budgets, logging standards, data residency rules, privacy choices.
• Design: component library rules, brand voice, motion guidelines, layout constraints.
• Non-functional: observability expectations, error handling defaults, security controls, rollback plans.

Keep this in a format the agent can consume directly. Not buried in Notion pages or scattered docs. Short, structured artifacts with clear keys and values. Update them when reality changes, not once a quarter.

2) Turn decisions into first-class objects

Write decisions like you write code: small, explicit, versioned. Examples:

• We notify by email for regulated events; no in-app toasts for legal clients.
• We log every client-facing message with a retention policy of 365 days.
• We use Jest for testing and React Query for data fetching.
• We never ship playful copy to enterprise buyers; default tone is concise and direct.
• We do not add new dependencies without approval if an equivalent exists in the stack.

These constraints reduce search space for the agent. They also remove the guesswork for a human pairing with it. When the agent tries to deviate, it should surface a question instead of pushing code.

3) Add lightweight rituals to keep context fresh

• Ten-minute decision review at the start of a work block. Capture new choices as decisions, not meeting notes.
• After a customer call, record the two or three implications that affect current work. Add them to the decision set.
• When a feature ships, add the gotchas discovered during QA to the constraints list so the agent avoids them next time.
• Rotate a weekly audit of decisions to prune stale ones and highlight new ones to the team.

None of this needs a big meeting. It needs habit and a place to put the information that the agent and humans can both read.

4) Instrument drift and prompt bloat

• Drift detection: when the agent suggests patterns outside your decisions, flag and log it. Example: it proposes GraphQL when the standard is REST. Approve or reject once; the system learns.
• Prompt bloat control: track how much context you stuff into each request. If prompts are ballooning because you do not trust the agent to remember standards, you have a context distribution problem.
• Rework ratio: measure how often agent output is rewritten due to missing context. Track by feature, not by file.
• Time to clarity: time from "we need X" to "agent has the right constraints to start." Shrink this by improving decision availability, not by adding meetings.

5) Give PMs visibility into the IDE loop

The PM should be able to inject context into an agent session without waiting for a ticket cycle or a meeting. That can be a decision toggle, a constraint update, or a quick note tied to the task. The engineer stays unblocked, the agent stays aligned, and the PM regains influence on the first pass.

How this looks in practice

Day zero: a PM hears from a customer that export files must include a new compliance note. Instead of writing a paragraph in Slack, the PM adds a decision: "All exports include compliance footer text provided by legal, immutable after generation." The agent sees it before generating the export flow and includes the footer. QA catches tone issues, the PM tightens the tone rule. No rework cycle.

Week one: the team picks React Query and Jest as defaults. They add them as decisions. When the agent tries to introduce Axios or Vitest, it flags a suggestion instead of pulling the package. The team accepts or rejects. Dependency creep stops.

Week two: a customer call reveals that in-app toasts are acceptable for sandbox accounts but never for production tenants. The PM adds that nuance. The agent now branches behavior based on environment without being told in the prompt each time.

Week three: the team realizes performance budgets are missing. They add: "All list endpoints must return in under 300ms at P95 with pagination." The agent starts choosing pagination and indexing patterns that fit the budget without being reminded.

Before and after

Before: PM feedback is bundled into a weekly review. The engineer prompts the agent with partial context. The agent scaffolds a feature with playful copy and missing audit logs. QA flags issues. PM reopens the ticket. Engineer rewrites half the code. Two weeks of motion for a feature that should have shipped in two days.

After: PM adds decisions in line with customer calls. Engineer prompts the agent with the decision set available. The agent ships the feature with email notifications, audit logging, and the right tone. QA verifies minor details. The feature ships in two days with no rewrite.

A pragmatic rollout plan

Week 1: Create a decision register. Seed it with ten to twenty choices that actually affect current work. Keep it in plain text or JSON so agents can read it. No jargon.

Week 2: Wire the decision set into your agent workflow. Pass it as context automatically. Do not rely on humans to paste it.

Week 3: Add drift tracking. When the agent suggests something outside the decisions, capture it. Decide once. Update the decision set or block the change.

Week 4: Add a daily ten-minute decision review. Add or retire decisions. Keep it light.

Week 5: Add a short PM injection path: a way for PMs to add a constraint that is live within an hour, not a sprint.

Signals you are improving

• Fewer rewrites attributed to missing context.
• Shorter prompts because standards live in the decision set.
• Consistency in dependencies and patterns across features.
• QA finds fewer tone and compliance issues.
• PMs spend less time re-explaining user intent and more time refining it.

Signals you are not there yet

• Engineers paste walls of text into prompts because they do not trust shared context.
• Agents introduce new dependencies every week.
• PMs learn about output only at sprint review.
• QA keeps catching the same category of errors: tone, logging, accessibility.
• Decision docs become stale and nobody can tell which ones matter.

The new shoulder tap

The old shoulder tap was a two-minute interruption that carried nuance without paperwork. The modern version is structured context that the agent and the human can both use. It is fast because it is pre-baked. It is reliable because it is explicit. It restores the PM voice inside the IDE loop without slowing down the engineer.

Engineers keep the speed they get from Cursor, Claude, or Copilot. PMs regain influence on the first pass. The organization ships features closer to the customer need on the first try. The informal glue that remote work dissolved comes back as a system, not a hope that people will talk more in hallways.

But bigger windows just create more noise.

The Information Problem

I teach a class on product management, and one concept always catches people off guard: PMs don't suffer from a lack of information. They're drowning in it. Customer feedback, analytics, competitive intel, team opinions, stakeholder requests. The volume of information available is overwhelming.

The problem isn't gathering more information. It's knowing what to pay attention to.

A PM who listens to every piece of feedback equally will build a frankenstein product that satisfies no one. A good PM curates attention: they decide which signals matter and which are noise.

AI agents have the same problem.

Throwing a 300-page printer manual into an agent's context window doesn't help it fix a paper jam. It needs the 2 pages on troubleshooting jams, not the other 298 pages on network setup, toner replacement, and driver installation.

Access to information is different from loading all of it into working memory. Humans understand this instinctively. We keep reference materials available but don't try to hold everything in our head at once. We pull in what's relevant when it's relevant.

Agents need the same capability.

When Attention Fails

One of our customers is building a new product from scratch with a small team. They're moving fast, iterating, figuring things out as they go. Because of this, they haven't established formal conventions around tooling yet. No documented decisions about testing frameworks (Vitest vs Jest), styling approaches (Tailwind vs CSS-in-JS), or architecture patterns.

Their coding agent had a different interpretation of "moving fast."

Every new feature came with a new testing framework. One feature used Jest. The next used Vitest. Then back to Jest. Then something else entirely. Same with component patterns: the agent would scaffold React components one day and suggest a completely different approach the next.

The agent wasn't broken. It had access to knowledge about all these frameworks. The problem was it had no way to know which choices had already been made. No sense of "we decided on Jest last week, stick with that."

Without directed attention, the agent treated every task as a blank slate. Maximum flexibility, zero consistency.

We had to build a concept we call "decisions" into Brief: explicit declarations like "We use Jest for testing" or "We build components in React" that constrain the agent's attention. Not because the other options are bad, but because consistency matters more than theoretical perfection. This is the core of product context—giving AI the business knowledge to make consistent decisions.

Why This Happens

Transformer models don't naturally distinguish between what's important and what's not. Everything in the context window gets processed with relatively equal weight. The model attends to all of it, looking for patterns and relationships.

This is powerful for tasks where everything is relevant. But for complex, ongoing work like building software, most of the available information is noise for any given task.

Change a button color, and the agent sees the entire frontend codebase. Every component, every pattern, every architectural decision. Without guidance about what matters for this specific change, the agent might decide this is the perfect time to refactor your component library.

Infinite context windows won't fix this. They'll make it worse. More information means more potential distractions, more opportunities to optimize for the wrong thing, more ways to miss the actual signal.

The Solution Isn't More Context

The industry is solving for the wrong constraint.

Bigger context windows are impressive technically. They're useful for certain tasks. But they don't address the fundamental problem: agents need to know what to pay attention to, not just what they have access to.

This requires a different primitive: attention.

Brief solves this through structured context management. Teams can define decisions, document conventions, establish boundaries around what the agent should consider for different types of tasks. The agent has access to the full codebase and all relevant documentation, but its attention is directed toward what actually matters. See the agent setup guide to learn how to configure this with Cursor, Claude Code, and other tools.

When you tell Brief "we use Jest," that's not just metadata. It shapes how the agent approaches testing tasks. When you define your ICP, that's not background information. It directs architectural choices.

The agent still has access to knowledge about Vitest, Mocha, and every other testing framework. But its attention is constrained to the choice you've already made.

Absent this kind of directed attention, the alternative is keeping a Notion doc and spoon-feeding prompts one by one, manually curating what information goes into each request. Treating the agent like a very sophisticated find-and-replace tool instead of a collaborator.

That works, but it doesn't scale. It defeats the purpose of having an agent in the first place.

What Changes

The difference between an agent with infinite context and an agent with directed attention is the difference between a PM who reads every email and a PM who knows which emails matter.

Both have access to the same information. Only one ships coherent products.

Context windows will keep growing. Models will keep improving. But until we solve for attention, agents will continue to make technically correct decisions that miss the point entirely.

This makes perfect sense when you think about what we're actually giving them.

What Works

For a migration, the agent just needs to understand the codebase. Transform this pattern to that pattern, update dependencies, move files around. The repository contains everything it needs to know.

But for a new feature?

The agent needs to understand users, business priorities, edge cases, and how this change fits into the broader product strategy. We're asking it to make product decisions based solely on technical artifacts.

How We Onboard Humans

What's wild is that we'd never onboard a junior engineer this way. You wouldn't hand a new hire access to the repo on day one and say "go build the user authentication system."

You'd introduce them to the rest of the organization, have them fix some bugs, maybe refactor a small module, gradually build up their understanding of both the codebase and the product.

With AI agents, we skip all of that. We throw them directly at complex feature work with zero context about users, business constraints, or team conventions. Then we're surprised when they make poor decisions.

The Cost of Context Loss

When we were building Brief itself, our coding agent had an obsession with dashboards. Tell it we're making a B2B SaaS app and the first thing it would do is scaffold out a generic dashboard component. No consideration for what the product actually did. No understanding of what users needed first. Just: "B2B SaaS = dashboard."

The agent was pattern matching on the wrong patterns. It had learned that B2B apps have dashboards, but it had no context about our product, our users, or our priorities. So it optimized for building the most generic, least useful thing possible.

Once we started feeding it Brief's own product context (what we were building and why), it stopped suggesting dashboards. It finally had enough information to make decisions that aligned with our actual product strategy.

Or take one of our customers building legal tech for law firms. Professional tools for serious clients handling serious matters. Their agent kept injecting emojis into error messages, adding playful microcopy, and generally treating it like a consumer social app.

The agent wasn't trying to sabotage them. It was doing exactly what it had been trained to do: make engaging, friendly interfaces. But it had zero context about who these users were, what they were trying to accomplish, or what tone was appropriate.

After they gave Brief their ICP and company context (that these were legal professionals working on high-stakes matters), the agent quit using emojis cold turkey. It understood not just what to build, but how it should feel.

These aren't edge cases. They're the predictable result of context loss.

The Telephone Game

The real diagnostic question isn't "is my agent good enough?" It's: "how much of a game of telephone am I playing?"

Think about the path information takes:

PM → Slack thread → Engineering ticket → Engineer's brain → Prompt → Agent

At every step, context gets compressed, simplified, or lost entirely.

The PM has a conversation with a customer about a painful workflow. They summarize it in Slack. Someone distills that into a ticket. An engineer reads the ticket and forms their mental model. Then they try to express that mental model in a prompt to an agent.

By the time the agent sees it, the original customer pain has been filtered through four layers of lossy compression. The agent is building from a photocopy of a photocopy of a photocopy.

The more steps between the original context and the agent, the more you're treating it like a mushroom. Feeding it degraded information, expecting clarity.

What Agents Actually Need

Product Context: Who are your users? What problems are they trying to solve? What does success look like for them? Your agent should understand the difference between building for lawyers and building for teenagers, between enterprise IT buyers and prosumer creators.

Business Context: What are you optimizing for right now? Is this a scrappy MVP where perfect is the enemy of shipped? Or a mature product where a bug could cost millions? What are the quality bars, the compliance requirements, the performance budgets?

Team Context: What are your conventions? Your agents should know that your team prefers composition over inheritance, that you always add error tracking to new features, that the design system is in Figma and not the repo.

Decision Context: Why did you make past architectural choices? What alternatives did you consider? What constraints drove those decisions? Without this, agents will make the "textbook correct" choice that ignores your specific constraints.

A senior engineer joining your team can only make good decisions if they have sufficient context. Your agent needs the same.

The Real Difference

Successful coding agents have access to context. Disappointing ones don't.

The sophistication of the AI and the size of the context window matter less than whether you're treating it like a mushroom: feeding it shit and keeping it in the dark.

A Self-Assessment

Ask yourself:

1. The Dashboard Test: If you asked your agent to build a new feature for your product right now, would it suggest something generic or something specific to your users?
2. The Telephone Count: How many steps are between your original product decisions and what your agent sees? Can it access the PM discussion, or just the code?
3. The New Hire Test: If a senior engineer joined your team today with only the context your agent has, could they make good architectural decisions?
4. The Tone Test: Does your agent understand not just what to build, but how it should feel for your specific users?

If you're failing these tests, you don't have an agent problem. You have a context problem.

And the good news is: context problems are solvable.

I heard it last Friday: "We fired our head of product. They weren't able to move as fast as our engineering team." It's starting at small companies, but it signals a bigger crisis for product management.

The old world

For decades the bottleneck was hands-on-keyboards. Engineering time was scarce, so we optimized for ceremony and alignment: quarterly OKRs, monthly business reviews, weekly product reviews, daily stand-ups, constant user research. The rituals worked because code was expensive.

A feature that took six weeks to build could justify two weeks of user research, a week of spec writing, and four rounds of design review. The math worked. PM overhead was a rounding error compared to engineering cost.

The new constraint

When code generation accelerates for certain types of work, the constraint shifts to thought, judgment, and decision-making. Product management gets reexamined from the ground up. The old cadence doesn't survive when builds happen in hours.

An engineer with Cursor or Claude can ship specific features in an afternoon. Standard authentication flows? Done by lunch. CRUD dashboards? Finished before standup ends. Basic payment integrations? Two hours, including tests.

This doesn't apply to everything. Distributed systems, novel architectures, ML pipelines, compliance-heavy features, and scale-sensitive work still require careful engineering. But the subset of product work that is now genuinely fast has grown large enough to create tension.

The PM is still running their two-week discovery sprint. Still scheduling five stakeholder meetings. Still writing the 12-page spec document. By the time the PRD is ready, engineering has already shipped three other features and is wondering what product is doing all day.

The velocity mismatch

PMs operate at a cadence designed for a different era. The tools and processes that made sense when engineering was the bottleneck become the bottleneck when code gets cheap.

The pattern repeats:

• A PM spent three days crafting the perfect roadmap presentation. Engineering shipped four features during those three days and asked why they weren't in the deck.
• A product team ran a month-long customer research initiative to validate a feature concept. By the time they presented findings, the engineering team had prototyped, tested, and deprecated two similar approaches.
• A head of product got fired not for poor judgment, but for taking two weeks to make a decision that engineering could implement in two hours.

But slowness rarely comes from individual PM output alone. The deeper issues:

• Unclear company strategy means PMs spend weeks building alignment that shouldn't be necessary
• Reactive leadership creates constant reprioritization, making previous research obsolete
• Conflicting incentives across functions force PMs into negotiation cycles that delay decisions
• Shifting goals invalidate carefully researched product directions mid-stream

The gap continues to widen. Treating it purely as a PM performance problem misses the organizational dysfunction underneath.

The career implications

This shift threatens the entire PM discipline. If product thinking can't keep pace with product building, one of two things happens:

1. Engineering starts making product decisions (often badly, without user context or business strategy)
2. Companies stop hiring PMs and just let AI agents make the calls

Neither is good. The first leads to technically impressive products that nobody wants. The second leads to feature churn without strategic direction.

But there's a third path: PMs who evolve their practice to match the new environment. Discovery work fundamentally takes time (market sizing, qualitative research, enterprise needs analysis, and validation don't accelerate at the same rate as code generation), so the answer lies in making PM judgment more accessible to the systems doing the building.

This raises new risks. Velocity without validation can erode user trust, accelerate technical debt, create brand inconsistency, and ship misaligned features at scale. PMs must actively manage these trade-offs, which means evolving new skills: understanding how AI consumes context, recognizing agent failure modes, and designing systems that preserve strategic coherence even when execution accelerates.

What changes

Making faster decisions misses the point. The real challenge: making your decisions accessible to the systems doing the building.

When an AI agent is implementing a feature, it needs instant access to different types of product judgment:

• Business prioritization: Why this feature matters more than alternatives
• UX clarity: What experience principles guide implementation choices
• Strategic trade-offs: How this fits into long-term product direction
• Risk assessment: What could go wrong and what safeguards matter
• User segmentation: Which user groups this serves and which it doesn't
• Sequencing logic: Why now versus later, and what dependencies exist

But encoding judgment is only one dimension of PM work. PMs still need to:

• Align executives around strategic direction
• Negotiate cross-functional trade-offs in real-time
• Set long-term vision that guides multiple teams
• Design rollout sequences that manage risk and dependencies
• Build trust with customers and stakeholders through direct engagement

Tools that capture structured context support these activities but don't replace them. The value is in making PM reasoning available to engineers and AI systems at decision time, reducing the coordination overhead that slows everyone down.

The silver lining

The same founder asked, "Can an AI teach my engineers taste?" Yes. Taste is a series of decisions and judgments. AI can teach engineers and agents taste, but it needs human direction. People who care about users, customers, and what the company can achieve.

Product management survives this shift. PM as process coordinator doesn't. The future belongs to PMs who can encode judgment, not just exercise it. Who can build systems that scale taste, not just demonstrate it in quarterly reviews.

The PMs who figure this out won't get fired for being too slow. They'll be the ones who kept their companies building the right things even as execution velocity increased. Not by working faster, but by making their thinking more accessible to the systems and people who need it.

• more metrics (they're accountable for outcomes, but drowning in numbers that don't inform decisions)
• more workflows
• more feature requests
• more armchair feedback
• more process
• more ideas

PMs need:

• more clarity
• more help expressing ideas
• more understanding of eng capability
• more reasons why an iceboxed feature might work
• more help selling ideas internally
• more alignment to company decision making

Every product ever built for development teams optimizes for the former and not the latter.

Why we keep building the wrong tools

Walk through any product team's stack and you'll find the same pattern: tools that track everything but illuminate nothing.

Dashboards with 47 metrics but zero insight into which ones actually matter. Roadmap tools that beautifully visualize features but can't explain why you're building them. Feedback databases with thousands of requests but no framework for deciding which problems are worth solving.

We built Jira to track work, not to understand it. We built analytics to measure behavior, not to explain it. We built workflow tools to coordinate people, not to amplify their judgment.

The entire category optimizes for visibility over understanding. Process over clarity. Coordination over alignment.

But tool limitations aren't the primary driver of PM dysfunction. The real waste comes from:

• Unclear company strategy forcing PMs to build alignment from scratch on every decision
• Reactive leadership that constantly shifts priorities, invalidating previous work
• Lack of company-wide prioritization creating conflicting demands across functions
• Shifting goals that make yesterday's research obsolete

Tools can't fix these problems. But they can reduce the coordination tax when organizational clarity exists.

What PMs actually do all day

A typical PM day:

• 9:00am: Engineering asks "Should we use Redis or in-memory caching for this?" You have 10 minutes to answer before they make the choice themselves.
• 10:30am: Design presents three mockups. All look good. You need to articulate which one aligns with the product vision you haven't had time to write down.
• 2:00pm: A customer feature request comes in. It's technically feasible but you can't remember if it conflicts with the strategic direction from last quarter's offsite.
• 4:00pm: Your CEO asks why the team is building Feature X instead of Feature Y. You know there was a good reason but the decision context is buried in a Slack thread from six weeks ago.

Every one of these moments requires instant access to judgment, strategy, and context. None of the tools in your stack help with this.

The expression problem

PMs spend half their time trying to express ideas that don't fit into existing tools. You can't put "this feature helps enterprise customers but might confuse prosumers" into a roadmap. You can't capture "we're prioritizing this because our biggest competitor just launched something similar" in a kanban board.

So PMs write docs. Lots of docs. Strategy docs, vision docs, decision docs, context docs. The docs pile up. Nobody reads them. The PM becomes the bottleneck because they're the only person who's read all the docs.

Docs themselves aren't the problem. They enable asynchronous alignment, capture long-term strategy, and create organizational memory. The problem: lack of structured, queryable metadata around those docs. You can't query a Google doc. You can't feed context documents to the AI tools your engineers are using to build features. The reasoning exists but remains inaccessible at decision time.

The alignment gap

PMs are supposed to align everyone around what to build. But alignment requires shared understanding, and shared understanding requires shared context.

When engineering uses AI to implement features, that AI has zero context about:

• Why this feature matters to the business
• What trade-offs are acceptable
• How it fits into the product strategy
• What customer problems it solves

So you get technically perfect features that miss the mark. Beautiful implementations of the wrong solution. Fast execution in the wrong direction.

The tools we've built for PMs don't solve this. They make it worse by adding more process between the PM's judgment and the team's execution.

What better looks like

Tools built for what PMs actually need would:

• Capture product judgment in a format that AI can consume
• Make strategic context instantly accessible when decisions get made
• Help PMs articulate ideas in ways that engineering, design, and business all understand
• Show why an iceboxed feature might work now even though it didn't six months ago
• Connect product decisions to company objectives without forcing everyone into a meeting

Amplifying PM judgment so it can operate at the speed of AI-assisted development: that's the goal. Not replacing PM intuition with automation.

But this requires PMs to evolve new skills. If AI will consume PM judgment, PMs need to understand:

• How to structure reasoning so AI can interpret it accurately
• What patterns of model behavior to expect and how to guide them
• How agents fail and what guardrails prevent common failure modes
• How to design prompts that surface the right context for each decision

AI literacy becomes a core PM competency, not a nice-to-have.

The velocity problem

As AI tools accelerate engineering, the gap widens. Engineers can implement certain features in hours. PMs still need days to build context, align stakeholders, and make decisions. The mismatch creates friction:

• Engineering waits for product direction
• Or engineering moves forward without product input
• Or the PM becomes a bottleneck and gets removed

We've seen all three. None of them work.

But velocity alone creates new risks. Shipping without validation can:

• Erode user trust through misaligned features
• Accelerate technical debt faster than teams can manage it
• Create brand inconsistency across rapidly shipped experiences
• Scale incorrect assumptions before anyone catches them

PMs must actively manage these trade-offs, which is harder when execution outpaces strategic review.

The challenge also varies by company scale. Early-stage startups can compress decision cycles because fewer people need alignment. But mid-market and enterprise companies face unavoidable latency from:

• Compliance review cycles
• Sales commitments already made to customers
• Integration dependencies across multiple teams
• Multi-team coordination requirements

The argument for faster PM output applies most directly to small, agile teams. At scale, many sources of slowness are structural, not individual.

The Future of PM

The product management org of five years from now won't look like the product management org of today.

Less time coordinating between teams through meetings. Less time writing specs that nobody reads. More time encoding judgment into systems that can guide AI-assisted development. More PMs who can make their product thinking accessible when engineers and AI systems need it.

But this doesn't mean eliminating the human work of PM:

• Executive alignment still requires trust built through direct engagement
• Strategic vision still needs articulation that inspires teams
• Cross-functional negotiation still depends on relationship and context
• Long-term product direction still requires human judgment about market evolution

The shift is toward augmenting these activities with better infrastructure for capturing and surfacing the reasoning behind them.

Product leaders of today have the opportunity to shape that evolution. The tools exist to build this future. The question is whether we'll build them for what PMs actually need, or keep optimizing for more metrics, more workflows, and more process.

This is the hidden cost of context-less AI development—and it's more expensive than you think.

When One Developer Becomes Ten

Sarah, a senior developer at a fintech startup, could keep everything straight. She knew that the payment retry logic wasn't just about resilience—it was specifically designed to handle the European banking holidays that kept tripping up their enterprise customers. She remembered that the seemingly over-engineered user permission system existed because their biggest client demanded granular audit trails for compliance reasons.

When Sarah worked alone with Claude or Cursor, her AI tools were extensions of her knowledge. She provided the context naturally: "Make sure this follows our compliance requirements for financial data retention" or "Remember, this needs to handle the edge case where European banks are closed."

But Sarah's startup grew. They hired five more developers. Then ten. Suddenly, the collective knowledge that once lived in one person's head was scattered across a dozen minds, with gaps appearing everywhere the knowledge didn't quite transfer.

The Documentation Illusion

"We have great documentation," Sarah's team lead assured her. And they did—sort of. They had README files, architectural decision records, and even a well-maintained wiki. The payment retry logic was documented. The permission system had detailed comments.

But what the documentation didn't capture was the why behind the what. It didn't explain that the payment retry logic came from three painful customer calls where transactions failed during Deutsche Bank's extended Christmas closure. It didn't mention that the permission system's complexity wasn't technical debt—it was the reason they landed their enterprise deal.

This is where the math gets brutal. According to a recent study by GitLab, developers spend 25% of their time searching for information and context. For a ten-person engineering team, that's 2.5 full-time equivalent positions just hunting for answers.

But here's the real kicker: when your AI development tools lack this business context, that percentage skyrockets. Your AI can generate code at superhuman speed, but if it doesn't know why that code needs to exist, you end up with elegant solutions to the wrong problems.

The VIP Demo Problem

Last month, Sarah's team got an urgent request: "We need to demo the new analytics dashboard to our biggest potential customer in two weeks. Can you prioritize the mobile responsiveness?"

This wasn't in any markdown file. This wasn't captured in the codebase. This was pure business context—the kind of information that makes the difference between shipping something useful and shipping something that misses the mark entirely.

When Sarah's teammate Mike fired up Cursor to tackle the responsive design, his AI assistant had no idea that this wasn't just any mobile optimization. It didn't know that the potential customer's team primarily used tablets for field work, or that their current analytics solution failed completely on mobile, making this a key differentiator.

Mike's AI generated beautiful, standards-compliant responsive CSS. It passed all the tests. But it optimized for phones when it should have optimized for tablets. The demo went poorly.

The Copy-Paste Tax

The obvious solution seems simple: just copy the relevant context into every AI session. Tell Claude about the European banking holidays. Explain the VIP demo requirements. Provide the business background.

But this creates what we call the "copy-paste tax"—the invisible overhead of context management that scales disastrously with team size.

Research from Stack Overflow's 2024 Developer Survey shows that developers using AI tools spend an average of 23 minutes per session providing context and clarifying requirements. For a team making 50 AI-assisted code changes per day (a conservative estimate for an AI-native team), that's over 19 hours of daily overhead just on context transfer.

That's more than two full-time positions doing nothing but feeding context to AI tools.

When Business Context Disappears

The problem compounds when you realize that business context has a half-life. The reasoning behind that payment retry logic becomes fuzzy after six months. The specific customer requirements that drove the permission system complexity get forgotten when that account manager leaves.

A study by Atlassian found that 90% of business context is lost within 12 months if it's not actively maintained in systems. Your AI tools are making decisions based on code that's optimized for constraints that no longer exist, or missing constraints that are now critical.

Take the team at a B2B SaaS company we worked with. They spent three weeks building an elegant API rate limiting system based on technical best practices. Beautiful code, comprehensive tests, perfect documentation. But they didn't know that their biggest customer had already negotiated custom rate limits in their contract six months ago. The new system broke the customer's integration, leading to a tense escalation call and emergency rollback.

Their AI assistant had generated flawless code. But it didn't know about the business agreement, so it optimized for the wrong constraints.

The Multiplication Effect

The hidden costs multiply as teams scale. It's not just the time spent providing context—it's the accumulated errors from missing context, the rework from building against outdated assumptions, and the opportunity cost of solving the wrong problems efficiently.

Consider the mathematics: if context-less development leads to just a 15% increase in rework (a conservative estimate based on our research), and your ten-person team ships 100 features per quarter, you're rebuilding 15 features every three months. At an average feature cost of two developer-weeks, that's 30 weeks of wasted development time per quarter.

That's the equivalent of having three developers who produce nothing but waste.

Beyond Technical Documentation

The solution isn't more documentation—it's making business context as accessible to AI as technical context already is. Your AI tools can read your entire codebase, understand your database schema, and analyze your git history. But they can't access the customer calls that drove architectural decisions, the competitive pressures that shaped feature requirements, or the strategic pivots that invalidated old assumptions.

This is why teams using context-aware AI development report 40% fewer failed features and 60% faster time-to-product-market-fit. When your AI understands not just what the code does, but why it needs to exist, it makes fundamentally better decisions.

The Context Infrastructure Imperative

The companies winning with AI development aren't just using better models or more powerful tools. They're treating context as infrastructure—something that scales with their team and improves with time, rather than degrading.

They're building systems where business decisions, customer insights, and strategic constraints are as accessible to their AI tools as their database schemas and API documentation. They're creating memory that persists across team members, projects, and pivots.

Because here's the truth that every scaling startup learns: your AI doesn't know why you're building this. And if it doesn't know why, all that superhuman coding speed just means you'll build the wrong thing faster.

The question isn't whether you can afford to solve this problem. The question is whether you can afford not to.

Your development team's time is too valuable to waste on context archaeology. Your AI tools are too powerful to hamstring with missing business intelligence. The hidden cost of context-less development isn't just inefficiency—it's building a codebase that optimizes for constraints that don't exist while ignoring the ones that do.

The problem isn't code quality anymore—it's product sense. Modern AI development tools have solved the "how" but completely missed the "why." This creates a dangerous feedback loop where teams ship faster than ever while simultaneously drifting further from their actual business objectives.

After building Brief, a context layer that helps AI understand business decisions, we've learned that the gap between "AI that codes" and "AI that builds products" isn't just about training better models. It's about fundamentally rethinking how we structure and deliver context to AI systems.

The Context Problem: Why Fast Code ≠ Good Product

Traditional AI coding assistants operate in a context vacuum. They see your current file, maybe your repository structure, and potentially some recent changes. But they don't see:

• Why this feature exists in the first place
• What customer problem it's supposed to solve
• How it fits into your broader product strategy
• What constraints or decisions shaped its design
• Whether building it now aligns with your goals

This leads to what we call "agentic whiplash"—teams that can implement any feature in hours but constantly pivot because their AI lacks the product intelligence to guide those decisions.

The solution isn't better code generation. It's building AI systems that understand product impact alongside technical implementation.

Architecture: Context as Infrastructure

Building product-aware AI requires treating context as infrastructure, not an afterthought. Here's the architecture we developed for Brief:

┌─────────────────┐    ┌──────────────────┐    ┌─────────────────┐
│   AI Tool       │    │   Context Layer  │    │   Business      │
│  (Cursor/Claude)│◄──►│     (Brief)      │◄──►│   Context       │
│                 │    │                  │    │   Store         │
└─────────────────┘    └──────────────────┘    └─────────────────┘
                              │
                              ▼
                       ┌──────────────────┐
                       │   Decision       │
                       │   Engine         │
                       └──────────────────┘

Component 1: Business Context Store

The foundation is a structured repository of business context that goes beyond code:

interface BusinessContext {
  decisions: Decision[];
  constraints: Constraint[];
  goals: Goal[];
  customerFeedback: Feedback[];
  technicalDebt: TechnicalDebt[];
}

interface Decision {
  id: string;
  category: 'tech' | 'product' | 'design' | 'process';
  decision: string;
  rationale: string;
  severity: 'info' | 'important' | 'blocking';
  timestamp: Date;
  tags: string[];
}

We store decisions as first-class entities because they represent the "why" behind every line of code. When an AI understands that "we chose React over Vue because our team has React expertise" or "we're not adding new database tables until we resolve the performance issues," it makes fundamentally different recommendations.

Component 2: Context Retrieval Engine

Raw context isn't enough—you need intelligent retrieval that surfaces relevant context based on what the AI is working on:

class ContextRetriever {
  async getRelevantContext(
    query: string,
    scope: 'file' | 'feature' | 'epic'
  ): Promise<ContextResponse> {
    // Semantic search using embeddings
    const semanticMatches = await this.vectorSearch(query);
    
    // Keyword matching for exact decision references
    const exactMatches = await this.keywordSearch(query);
    
    // Hierarchical context (feature → epic → roadmap)
    const hierarchicalContext = await this.getHierarchicalContext(scope);
    
    return this.rankAndFilter({
      semantic: semanticMatches,
      exact: exactMatches,
      hierarchical: hierarchicalContext
    });
  }

  private async vectorSearch(query: string): Promise<ContextMatch[]> {
    const embedding = await this.embeddings.create(query);
    
    const { data } = await this.supabase
      .from('context_embeddings')
      .select('*')
      .rpc('match_context', {
        query_embedding: embedding.data[0].embedding,
        match_threshold: SIMILARITY_THRESHOLD,
        match_count: MAX_RESULTS
      });
      
    return data;
  }
}

The key insight: different types of queries need different retrieval strategies. A question about implementation details needs different context than a question about feature priority.

Component 3: Decision Engine

This is where product sense emerges. The decision engine evaluates AI suggestions against your business context:

class ProductDecisionEngine {
  async evaluateProposal(
    proposal: CodeProposal,
    context: BusinessContext
  ): Promise<DecisionResult> {
    const conflicts = await this.checkConflicts(proposal, context);
    const alignment = await this.assessAlignment(proposal, context);
    const impact = await this.estimateImpact(proposal, context);
    
    return {
      recommendation: this.generateRecommendation(conflicts, alignment, impact),
      reasoning: this.explainReasoning(conflicts, alignment, impact),
      alternatives: await this.suggestAlternatives(proposal, context)
    };
  }

  private async checkConflicts(
    proposal: CodeProposal,
    context: BusinessContext
  ): Promise<Conflict[]> {
    const blockingDecisions = context.decisions.filter(d => 
      d.severity === 'blocking' && 
      this.proposalConflicts(proposal, d)
    );
    
    return blockingDecisions.map(d => ({
      type: 'blocking_decision',
      decision: d,
      explanation: `This conflicts with decision ${d.id}: ${d.decision}`
    }));
  }
}

Implementation: MCP Integration Pattern

We built Brief as an MCP (Model Context Protocol) server that integrates with existing AI tools. This pattern lets you add product intelligence to any AI system without rebuilding everything:

// MCP Server Implementation
export class BriefMCPServer extends MCPServer {
  async handleToolCall(name: string, args: any): Promise<any> {
    switch (name) {
      case 'brief_get_context':
        return this.getRelevantContext(args.query, args.scope);
      
      case 'brief_check_decision':
        return this.checkAgainstDecisions(args.proposal);
      
      case 'brief_record_decision':
        return this.recordNewDecision(args.decision);
      
      default:
        throw new Error(`Unknown tool: ${name}`);
    }
  }
  
  private async getRelevantContext(
    query: string, 
    scope: string
  ): Promise<ContextResponse> {
    const retriever = new ContextRetriever(this.database);
    const context = await retriever.getRelevantContext(query, scope);
    
    return {
      decisions: context.decisions,
      constraints: context.constraints,
      recommendations: await this.generateRecommendations(context)
    };
  }
}

The MCP pattern is powerful because it creates a standard interface between AI tools and business context. Any tool that supports MCP can instantly access your product intelligence.

Data Layer: Making Context Queryable

The technical challenge isn't just storing context—it's making it efficiently queryable by AI systems. We use a hybrid approach with PostgreSQL and vector embeddings:

-- Core decision storage
CREATE TABLE decisions (
  id UUID PRIMARY KEY,
  category decision_category,
  decision TEXT NOT NULL,
  rationale TEXT NOT NULL,
  severity severity_level,
  created_at TIMESTAMP DEFAULT NOW(),
  tags TEXT[]
);

-- Vector embeddings for semantic search
CREATE TABLE decision_embeddings (
  decision_id UUID REFERENCES decisions(id),
  embedding VECTOR(1536),
  content TEXT
);

-- Semantic search function
CREATE OR REPLACE FUNCTION match_decisions(
  query_embedding VECTOR(1536),
  match_threshold FLOAT,
  match_count INT
)
RETURNS TABLE (
  decision_id UUID,
  decision TEXT,
  similarity FLOAT
)
LANGUAGE plpgsql
AS $$
BEGIN
  RETURN QUERY
  SELECT 
    de.decision_id,
    d.decision,
    (1 - (de.embedding <=> query_embedding)) AS similarity
  FROM decision_embeddings de
  JOIN decisions d ON de.decision_id = d.id
  WHERE (1 - (de.embedding <=> query_embedding)) > match_threshold
  ORDER BY similarity DESC
  LIMIT match_count;
END;
$$;

Context Integration Patterns

Pattern 1: Just-in-Time Context

Load context when the AI is about to make a decision:

async function enhanceAIPrompt(
  originalPrompt: string,
  codeContext: string
): Promise<string> {
  const relevantContext = await brief.getContext({
    query: originalPrompt,
    codeContext,
    scope: 'feature'
  });
  
  return `
${originalPrompt}

BUSINESS CONTEXT:
${relevantContext.decisions.map(d => `- ${d.decision}: ${d.rationale}`).join('\n')}

CURRENT CONSTRAINTS:
${relevantContext.constraints.map(c => `- ${c.description}`).join('\n')}

Consider this context when providing your response.
  `;
}

Pattern 2: Proactive Conflict Detection

Check proposals against your decision history before implementation:

async function validateProposal(proposal: string): Promise<ValidationResult> {
  const conflicts = await brief.checkConflicts(proposal);
  
  if (conflicts.length > 0) {
    return {
      approved: false,
      conflicts,
      suggestions: await brief.getAlternatives(proposal)
    };
  }
  
  return { approved: true };
}

Pattern 3: Learning from Outcomes

Update your context based on how decisions play out:

async function recordOutcome(
  decisionId: string,
  outcome: 'successful' | 'failed' | 'neutral',
  learnings: string[]
): Promise<void> {
  await brief.recordDecision({
    decision: `Outcome of ${decisionId}: ${outcome}`,
    rationale: learnings.join('. '),
    category: 'process',
    severity: 'info'
  });
}

Measuring Impact: Metrics That Matter

Traditional metrics (code quality, velocity) don't capture product alignment. We focus on measuring business context utilization:

interface ProductAlignmentMetrics {
  contextUtilization: number; // How often AI queries context
  decisionConflicts: number;  // Conflicts caught before implementation
  pivotReduction: number;     // Reduction in feature pivots
  goalAlignment: number;      // Features that map to stated goals
}

class MetricsCollector {
  async trackContextQuery(query: string, results: ContextResponse) {
    await this.analytics.track('context_query', {
      query_type: this.classifyQuery(query),
      results_count: results.decisions.length,
      utilization_pattern: this.analyzeUtilization(results)
    });
  }
  
  async trackDecisionConflict(proposal: string, conflicts: Conflict[]) {
    await this.analytics.track('conflict_detected', {
      conflict_severity: this.assessSeverity(conflicts),
      resolution_path: 'prevented'
    });
  }
}

Implementation Challenges and Solutions

Challenge 1: Context Staleness

Business context changes faster than code. Stale decisions can mislead AI systems.

Solution: Implement context freshness scoring and automatic expiration:

interface ContextFreshness {
  lastUpdated: Date;
  relevanceScore: number;
  expirationDate?: Date;
}

function calculateFreshness(decision: Decision): number {
  const age = Date.now() - decision.timestamp.getTime();
  const daysSinceCreation = age / (1000 * 60 * 60 * 24);
  
  // Exponential decay based on decision category
  const decayRate = DECAY_RATES[decision.category];
  
  return Math.exp(-decayRate * daysSinceCreation);
}

Challenge 2: Context Overload

Too much context can confuse AI systems as much as too little.

Solution: Implement smart context ranking and filtering:

function rankContext(
  contexts: ContextMatch[],
  query: string
): ContextMatch[] {
  return contexts
    .map(c => ({
      ...c,
      // Combine multiple scoring dimensions
      compositeScore: this.calculateCompositeScore(c, query)
    }))
    .sort((a, b) => b.compositeScore - a.compositeScore)
    .slice(0, MAX_CONTEXT_ITEMS);
}

private calculateCompositeScore(context: ContextMatch, query: string): number {
  // Weighted combination of relevance, freshness, and importance
  // Implementation varies based on context type and query characteristics
  return this.weightedScore([
    this.calculateRelevance(context, query),
    this.calculateFreshness(context.decision),
    this.getImportanceScore(context.decision.severity)
  ]);
}

Challenge 3: Cross-Team Context

Different teams have different contexts that need to be reconciled.

Solution: Implement hierarchical context inheritance:

interface ContextHierarchy {
  global: BusinessContext;    // Company-wide decisions
  team: BusinessContext;      // Team-specific decisions  
  project: BusinessContext;   // Project-specific decisions
}

async function getEffectiveContext(
  scope: 'global' | 'team' | 'project',
  teamId: string,
  projectId: string
): Promise<BusinessContext> {
  const contexts = await Promise.all([
    this.getGlobalContext(),
    this.getTeamContext(teamId),
    this.getProjectContext(projectId)
  ]);
  
  // Merge contexts with project overriding team overriding global
  return this.mergeContexts(contexts, ['global', 'team', 'project']);
}

The Future: Context-Native Development

What we're building toward isn't just smarter AI tools—it's a fundamentally different development paradigm where context and code evolve together.

In context-native development:

• Every line of code carries business rationale
• AI systems understand not just what to build, but why
• Technical decisions automatically align with product strategy
• Teams ship fast and ship right

The technical patterns we've shared are just the beginning. As AI tools become more sophisticated, the teams that win will be those that solve the context problem first.

Your AI doesn't know why you're building this. But it could.

Want to see these patterns in action? Brief provides production-ready context infrastructure for AI development teams. Learn more at briefhq.ai or reach out at hello@briefhq.ai.

Our design system uses neutral-010, neutral-020, neutral-030… up to neutral-090. The gaps are intentional—room to grow up or down when we need more shades. But AI assumes every design system follows the standard 100, 200, 300 pattern.

/* What Cursor suggests every damn time */
.card-background {
  background-color: var(--neutral-100);
  border: 1px solid var(--neutral-200);
}

/* What actually exists in our system */
.card-background {
  background-color: var(--neutral-010);
  border: 1px solid var(--neutral-020);
}

The --neutral-100 variable doesn't exist. The component breaks. I fix it, explain why, and move on. Three hours later, new chat session, same suggestion.

Yesterday it happened with testing frameworks. Our entire codebase uses Vitest for visual tests. Every single test file. But Cursor keeps generating Jest syntax:

// Cursor's favorite suggestion
import { describe, it, expect } from '@jest/globals';
describe('Button component', () => {
  it('should render correctly', () => {
    expect(component).toMatchSnapshot();
  });
});

// What we actually use everywhere
import { describe, it, expect } from 'vitest';
describe('Button component', () => {
  it('should render correctly', () => {
    expect(component).toMatchInlineSnapshot();
  });
});

The syntax is close enough that you don't catch it immediately. The test runs, fails, and you spend 10 minutes figuring out why your snapshot assertions are broken.

The Context Window Death Spiral

AI context windows burn through tokens fast. Start a new session, lose all your previous explanations. You're back to square one, re-explaining the same architectural decisions you've made dozens of times. This is the AI context loss problem that plagues every team using AI coding tools.

I tried solving this with Cursor Rules. Added our design system specs, testing preferences, component patterns—everything I was tired of repeating. The markdown file hit 800 lines.

Cursor started skimming. It would read the first 200 lines, maybe grab something from the middle, then ignore the rest. Suggestions got worse, not better. The AI was confident about rules it never actually read.

<!-- Line 1-50: Color system -->
neutral-010: #fafafa
neutral-020: #f5f5f5
neutral-030: #ededed
...

<!-- Line 300-400: Testing preferences -->
- Use Vitest, not Jest
- Visual regression tests with toMatchInlineSnapshot
- Component tests should cover accessibility
...

<!-- Line 600+: Architecture decisions -->
- No CSS-in-JS solutions
- Tailwind utilities only, no custom classes
- TypeScript strict mode required
...

Past 500 lines, the system breaks down. Sometimes it reads the color rules but ignores testing. Sometimes it catches the TypeScript requirements but suggests CSS-in-JS anyway. Never all of it together.

I split the rules into multiple files. .cursorrules, design-system.md, testing-guide.md, architecture.md. Now I'm managing four different documentation files, trying to keep them in sync as our system evolves. Half the time I forget to update one of them.

The Startup Problem

Components work fine with AI. Button, Card, Input—single items with clear interfaces. The AI can understand "use the Button component" and mostly gets it right.

But at a startup, you're constantly building things that aren't components yet. New pages, complex interactions, experimental features. The AI needs to understand your typography scale, spacing system, color palette, elevation levels, animation preferences, and accessibility requirements simultaneously.

// AI needs context for ALL of this
function FeatureCard({ title, description, priority }) {
  return (
    <div className={`
      // Typography: what scale? what weights exist?
      // Spacing: internal padding, margin rules
      // Colors: background, text, borders
      // Elevation: shadow levels, hover states
      // Animation: transition timing, easing
    `}>
      {/* Complex layout that requires understanding 
          all our design decisions at once */}
    </div>
  );
}

Every new feature becomes a context explosion. The AI pulls from its training data instead of your actual system. You end up with designs that look reasonable but break your carefully crafted consistency.

Why Everyone Hits This Wall

Engineering deals with the same problem for code architecture. Product managers for business logic. Designers for interaction patterns. Everyone spends their day re-explaining decisions to AI that should already understand the context.

The context window limitation isn't just technical—it's organizational. Your company's knowledge is scattered across decision docs, style guides, architectural decision records, meeting notes, and tribal knowledge. AI gets fragments, never the full picture. This is why product context matters so much—it's the business knowledge AI needs to build the right thing.

Building Brief to Fix This

We built briefhq.ai specifically for this problem. Instead of cramming everything into context windows or managing massive rules files, Brief uses MCP (Model Context Protocol) with RAG to surface exactly the relevant context for each request.

When you ask for a component, Brief knows your design system, your testing setup, your architectural constraints, and your business requirements. Not because it read a 1000-line markdown file, but because it can intelligently pull the right context without overwhelming the AI.

The AI gets the context it needs. You stop repeating yourself. Your team stops fighting the same battles every single session.

Join the waitlist at briefhq.ai.